Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 8

Liczba wyników na stronie
first rewind previous Strona / 1 next fast forward last
Wyniki wyszukiwania
Wyszukiwano:
w słowach kluczowych:  testy wydajnościowe
help Sortuj według:

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
PL
W artykule przedstawiono porównanie wydajności trzech sposobów realizacji interfejsów programistycznych stosowa-nych w aplikacjach webowych – REST, GraphQL oraz gRPC. Na potrzeby badań opracowano trzy aplikacje, które zostały wykonane w każdej ze wskazanych technologii i o takich samych funkcjonalnościach. Aplikacje wykorzystano do testów wydajnościowych, przeprowadzonych z użyciem narzędzia k6. Aplikacje zastosowano do zmierzenia czasu wykonania, wydajności i objętości przetwarzanych danych podczas operacji wyświetlania oraz dodawania rekordów. Uzyskane wyniki pozwoliły na sformułowanie wniosku, że najlepszym interfejsem pod względem wydajności (mierzonych jako liczba wykonywanych transakcji na sekundę) oraz czasu odpowiedzi serwera jest REST. Natomiast pod względem najmniejszej objętości danych, najlepszym wyborem jest gRPC.
EN
The article presents a comparison of the performance of three ways of implementing programming interfaces used in web applications - REST, GraphQL and gRPC. For the purposes of the research, three applications were developed, which were made in each of the indicated technologies and with the same functionalities. The applications were used for performance tests carried out with the use of the k6 tool. The applications are used to measure the execution time, performance and volume of processed data during display and adding operations. The obtained results allowed for the conclusion that the best interface in terms of performance (measured as the number of transactions per second) and server response time is REST. However, in terms of the smallest data volume, gRPC is the best choice.
PL
Niniejsza publikacja przedstawia wielokryterialne porównanie dwóch aplikacji mobilnych zbudowanych przy zastoso-waniu Android oraz Flutter SDK. Pierwsza z nich zaimplementowana została w języku Kotlin, natomiast druga w Dart. Proces porównawczy bada takie czynniki jak czas wykonania oraz użycie procesora podczas operacji dyskowych oraz na danych. Dodatkowo podczas analizy zwrócono uwagę na długość oraz objętość kodu, wsparcie społeczności oraz dostępność bibliotek. Analiza wykazała, że aplikacja napisana przy użyciu Android jest nie tylko często szybsza oraz wydajniejsza ale również posiada większe wsparcie społeczności oraz liczbę dostępnych bibliotek. Ponadto analiza objętości kodu źródłowego wykazała, że Flutter posiada kod bardziej zwięzły lecz trudniejszy do nawigowania od Android.
EN
This publication presents a multi-criteria comparison of two mobile applications built with the use of Android and Flut-ter SDK. The former has been implemented with Kotlin and the latter with Dart. The benchmarking process examines factors such as execution time and CPU usage during data and disk operations. During the analysis, attention was paid to the length and volume the source code, community support and the availability of libraries. The comparative analysis shows that a mobile application written using Android SDK is often not only faster and more efficient, but also has greater community support and the number of libraries available. In addition, an analysis of the source code volume showed that Flutter has more concise but more difficult to navigate code than Android.
EN
In this article, two leading solutions for managing packages in projects which are using JavaScript technology (yarn and npm) were subjected to a comparative analysis. As part of the implementation, two configuration files were created, one of which represents an empty application created on the basis of an application template based on the Angular framework in version 8. The second file reflects an extensive web application based on the same framework, but with the addiction of over 100 dependencies. The research was focused on the time efficiency of both solutions.
PL
W niniejszym artykule analizie porównawczej poddano dwa wiodące rozwiązania służące do zarządzania pakietami w projektach wykorzystujących technologię JavaScript (yarn oraz npm). W ramach realizacji powstały dwa pliki konfiguracyjne, z których jeden reprezentuje pustą aplikację stworzoną na podstawie szablonu aplikacji opartej na szkielecie programistycznym Angular w wersji 8. Drugi plik odzwierciedla rozbudowaną aplikację internetową opartą o ten sam szkielet programistyczny, lecz z dodatkiem ponad 100 zależności. Badania ukierunkowane zostały na wydajność czasową obu rozwiązań.
PL
W tym artykule omówiono kwestię porównania technologii Java i Kotlin w oparciu o szkielet aplikacji internetowych. Kryteria brane pod uwagę dla celów testowych to: czas wykonania, wykorzystanie pamięci, obciążenie procesora, liczba odpowiedzi z bazy danych w zadanym czasie. Przeprowadzana jest seria testów i ich dogłębna analiza porównawcza. Przeprowadzono testy i analizę kodu. Wydajność pod względem szkieletów aplikacji internetowych, szybkości odpowiedzi bazy danych i szybkości działania testów - we wszystkich Kotlin okazał się mniej wydajny. Nie ma znaczącej różnicy dla obciążenia procesora. Pomiędzy poszczególnymi pomiarami, różnica nie przekracza 2%. Implementacja w języku Kotlin nigdy nie osiągnęła najlepszego wyniku w żadnej grupie pomiarów.
EN
This paper discusses the issue of comparing Java and Kotlin technologies based on the web application framework. The criteria taken into account for testing purposes are: execution time, memory usage, CPU load, database response in set time. A series of tests and their in-depth comparative analysis are carried out. For this case, tests and code analysis were carried out to draw comparative conclusions. The performance in terms of web frameworks, database response speed and tests implementation in different languages - in all these Kotlin proved to be less efficient. There is no significant difference between CPU load between individual easurements, the difference does not exceed 2%. Implementation in the Kotlin language has never achieved the best result in any group of measurements.
PL
Tematyką badaną w artykule jest sprawdzenie wydajności frameworka Symfony do tworzenia aplikacji webowych. Przedstawiono przegląd literatury mówiącej o Symfony oraz jego najpopularniejsze moduły. Na podstawie stworzonych trzech identycznych aplikacji testowych napisanych we frameworkach Symfony 2.8, 3.4 oraz 4.2 porównano je ze sobą pod względem wydajnościowym. Aplikacja testowa została napisana w formacie bloga. Został wykorzystany styl architektury oprogramowania, znany jako API. Dzięki temu możliwe jest przeprowadzenie zaplanowanych testów. Badanie wydajności narzędzia Symfony dla poszczególnych wersji sporządzono na podstawie między innymi czasu ładowania danych z bazy oraz ich wyszukiwania w kolekcji danych, dodatkowymi testami było pobieranie danych z pliku csv oraz zapisywanie ich do pliku csv.
EN
The subject reached in the article is to check the performance of the Symfony framework for creating web applications. An overview of the literature about Symfony and the most popular modules. Based on the created three identical test applications written in the Symfony 2.8, 3.4 and 4.2 frameworks, they were compared with each other in terms of performance. The test application was written in the blog format. The software architecture style known as the API has been used. Related to this, it is possible to conduct scheduled tests. Symfony's performance testing for individual versions was based on, the time of loading data from the database and their search in the data collection, additional tests were to download data from a csv file and save them to a csv file.
EN
Proper selection of network devices have a crucial impact on the entire process of designing and building a modern communication system. At the moment, performance testing of network devices are often implemented by specialized laboratories or by the network devices vendors. To implement this test, the test traffic need be generated with bandwidth of 100 and more Gb/s. The authors of the article proposed their own test topologies that allows to saturate all switch ports based on the entangled traffic between ports or routing instances. In the introduction, the authors present how this type of tests are currently implemented. In the second Chapter, the components of the test bench are presented. The third Chapter presents the topology used to implement the test in the second layer of ISO/OSI model, and shows the influence of the test traffic on the selected devices elements. In the Chapter four proposes topologies that saturate two tested switches with the traffic based on entangling traffic with use of VRF and OSPF protocols. Such approach, based on open standards allows for self-realization of the tests by the final customer who can check the performance of the protocols or application in the environment of maximum traffic load. Note, that the presented method is used only to generate load on the ports of the device. This could be a good basis to start the appropriate tests of specified services or protocols.
PL
Odpowiedni dobór urządzeń sieciowych ma kluczowy wpływ na cały proces projektowania i budowy współczesnego systemu komunikacyjnego. W chwili obecnej testy wydajnościowe urządzeń sieciowych realizowane są najczęściej przez wyspecjalizowane laboratoria lub przez samych producentów urządzeń sieciowych. Do ich przeprowadzenia wymagane jest wygenerowanie ruchu testowego charakteryzującego się niejednokrotnie przepustowościami na poziomie 100 i więcej Gb/s. Autorzy w artykule zaproponowali własne topologie testowe które pozwalają wysycić wszystkie porty testowanego urządzenia. Bazują one na zapętlaniu ruchu pomiędzy portami lub instancjami rutingu. We wstępie autorzy prezentują jak aktualnie realizowane są tego typu testy urządzeń. W rozdziale drugim zaprezentowane zostały elementy składowe stanowiska badawczego. W rozdziale trzecim zaprezentowana została topologia wykorzystywana do realizacji testów w warstwie drugiej modelu ISO/OSI, oraz pokazano wpływ ruchu testowego na wybrane elementy sprzętowe urządzenia. W rozdziale czwartym zaproponowano topologie wysycania ruchem dwóch urządzeń testowych bazującą na zapętleniu ruchu z wykorzystaniem VRF i protokołu OSPF. Takie podejście, bazujące na otwartych standardach pozwala na samodzielną realizację testów urządzeń przez klienta końcowego, który może sprawdzić działanie interesujących go protokołów w środowisku granicznie wysyconego ruchem urządzenia sieciowego. Należy jednak pamiętać, że przedstawiona metoda służy jedynie do generowania obciążenia na portach urządzenia. Może to być dobra podstawa do zrealizowania właściwych testów określonych usług lub protokołów.
EN
Objectives. The present study sought to identify firefighters’ rated physical demands for the most frequently occurring work tasks and to determine if the ratings differed between full-time and part-time firefighters to help create a basis for the development of physical employment tests for firefighters. Methods. An extensive questionnaire was completed by 125 and 68 firefighters in 2000 and 2010, respectively. The data were analysed with the Mann–Whitney U test and binominal test and ranked on the basis of the responses in each category. Results. Significant differences were seen between the full- and part-time firefighters. The work tasks rated as the most physically strenuous in terms of aerobic fitness, muscle strength, work posture and body control by most respondents were smoke diving upstairs (carrying a hose), victim rescue in different ways, carrying a stretcher over terrain and pulling a hose. Conclusions. Physically strenuous work tasks should be included in the end-point performance variables used to select physical performance tests for firefighters. The part-time firefighters with no experience in several of the work tasks suggests that work-related exercises are important if both groups of firefighters are expected to do similar work.
EN
In this paper we take a look at what the Intel Xeon Processor 7500 family, code named Nehalem-EX, brings to high performance computing. We compare two families of Intel Xeon based systems (Intel Xeon 7500 and Intel Xeon 5600) and present a performance evolution of 16 node clusters based on these CPUs. We compare CPU generations utilizing dual socket platforms and a cluster across a number of HPC benchmarks and focused on different performance field and aspect. We will evaluate also technologies and features like Intels Hyper Threading Technology (HT) and Intel Turbo Boost Technology (Turbo Mode) and the performance implication of these technologies for HPC.
PL
W artykule przedstawiamy możliwości procesorów z rodziny Intel Xeon 7500 w obliczeniach wysokiej wydajności. Porównaniu poddano dwa 16-węzłowe klastry oparte na rodzinach procesorów Intel Xeon (7500 i 5600). Eksperyment przeprowadzono na klastrach zbudowanych w oparciu o platformę sprzętową wyposażoną w dwa gniazda procesorowe, wykorzystując popularne benchmarki z dziedziny HPC, koncentrując się na różnych aspektach wydajności. Przedstawiono również wpływ technologii Intel Hyper Threading oraz Intel Turbo Boost Technology na wydajność obliczeń.
first rewind previous Strona / 1 next fast forward last
JavaScript jest wyłączony w Twojej przeglądarce internetowej. Włącz go, a następnie odśwież stronę, aby móc w pełni z niej korzystać.