Preferencje help
Widoczny [Schowaj] Abstrakt
Liczba wyników

Znaleziono wyników: 6

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

help Ogranicz wyniki do:
first rewind previous Strona / 1 next fast forward last
PL
Celem artykułu było zbadanie wydajności i skalowalności aplikacji webowej napisanej w podejściu reaktywnym i imperatywnym z użyciem Spring Framework, aby zrozumieć różnice między tymi podejściami i wybrać technologię, która najlepiej odpowiada wymaganiom i zapewnia optymalną wydajność. Porównano dwie aplikacje testowepod względem czasów przetwarzania zapytań oraz wykorzystania CPU/RAM. Analizowano wpływ mikroserwisu Api Gateway na wy-dajność aplikacji. Badania wykazały, że aplikacja reaktywna szybciej przetwarza operacje I/O, zużywa mniej RAM, ale więcej CPU. Podejście imperatywne było szybsze dla operacji transakcyjnych wykonywanych sekwencyjnie. Wariant reaktywny reagował mniejszymi opóźnieniami na obecność Api Gateway niż imperatywne podejście.
EN
The purpose of this paper was to test the performance and scalability of a web application written in reactive and imperative approaches using the Spring Framework, in order to understand the differences between these approaches and choose the technology that best meets the requirements and provides optimal performance. Two test applications were compared in terms of query processing times and CPU/RAM usage. The effect of Api Gateway microservices on application performance was analyzed. The tests showed that the reactive application processed I/O operations faster, used less RAM but more CPU. The imperative approach was faster for transactional operations performed sequentially. The reactive variant reacted with less latency to the presence of Api Gateway than the imperative approach.
PL
Efektywne zarządzanie skonteneryzowanymi aplikacjami jest kluczowe dla zapewnienia ich wydajności i niezawodności. Celem niniejszej pracy było wskazanie jakie ustawienia konfiguracyjne orkiestratora Kubernetes mają największy wpływ na wydajność aplikacji mikrousługowej w warunkach wzmożonego obciążenia. Dla każdego zustalonych wariantów konfiguracji zmierzono przepustowość oraz czas odpowiedzi testowej aplikacji opartej o paradygmat mikrousług. Wyniki badań wskazują, że nadmierne skalowanie horyzontalne pogarsza wydajność aplikacji orazże ustawienia zużycia pamięci operacyjnej mogą odgrywać większą rolę w optymalizacji wydajności systemu niż zużycie procesora.
EN
Effective management of containerized applications is crucial to ensuring their performance and reliability. The aim of this work was to indicate which configuration settings of the Kubernetes orchestrator have the greatest impact on microservice application performance under conditions of increased load. For each of the established configuration variants, the throughput and response time of the test application based on the microservices paradigm were measured. Research findings indicate that excessive horizontal scaling degrades application performance and that memory usage settings may play a greater role in optimizing system performance than CPU usage.
PL
W artykule porównano wydajność dwóch aplikacji testowych, które stworzono używając szkieletów aplikacji Spring Boot i Laravel. Celem pracy jest uzyskanie odpowiedzi na pytanie badawcze: który szkielet oferuje lepszą wydajność czasową. Do analizy stworzono 12 scenariuszy testowych, a następnie na ich podstawie przeprowadzono testy używając narzędzia Apache JMeter. Dodatkowo porównane zostały metryki aplikacji oraz wsparcie społeczności dla obu szkieletów. Badania potwierdziły, że aplikacja zbudowana na szkielecie Spring Boot ma lepszą wydajność.
EN
The article compares the performance of two test applications created using the Spring Boot and Laravel application frameworks. The aim of the study is to find an answer to the research question: which framework offers better time performance. Twelve test scenarios were created for the analysis, and they were used to conduct performance tests using the Apache JMeter tool. Additionally, application metrics and community support for both frameworks were compared. The research confirmed that the application built on the Spring Boot framework has better performance.
PL
Artykuł przedstawia wynik badań nad menedżerami pakietów Flatpak oraz Snap wykorzystywanych do dystrybucji oprogramowania o otwartym kodzie w systemach Linux. Obydwa menedżery pakietów cechują się uniwersalnością oraz implementacją systemu piaskownicy (ang. sandboxing). W ramach badań przygotowana została aplikacja testowa, którą zbudowano w formatach Flatpak i Snap, a także opublikowano w oficjalnych repozytoriach z oprogramowaniem, gdzie dla Flatpak jest to Flathub, a dla Snap – Snap Store. Przygotowaną aplikację najpierw wykorzystano do zbadaniai porównania implementacji zasad piaskownicy. Następnie przeprowadzono testy użycia pamięci RAM oraz czasów uruchamiania przez aplikację zainstalowaną w obydwóch formatach. Wynikiem badań jest analiza uzyskanych pomiarów oraz wyciągnięcie wniosków.
EN
This article presents the result of a research of the Flatpak and Snap package managers used to distribute open-source software on Linux systems. Both package managers are characterised by their versatility and implementation of sandboxing. As part of the research, a test application was prepared, which was built in the Flatpak and Snap formats and published in the official software repositories, where for Flatpak it is Flathub and for Snap it is the Snap Store. The prepared application was first used to test and compare the implementation of sandboxing rules. This was followed by tests of RAM usage and start-up time by the application installed in both formats. The result of the research is an analysis of the measurement results and the drawing of conclusions.
5
Content available Analiza porównawcza technologii REST i GraphQL
EN
The article presents a comparative analysis of the two most commonly used API web design standards - REST and GraphQL. The time and size of HTTP responses returned by applications were tested. Two applications with the same functionalities, performing CRUD operations, on data stored in the non-relational MongoDB database were used for the research. Both applications were based on NodeJS technology. The JMeter tool was used to collect and analyze the data. On the basis of the obtained results, it was found that there were no significant differences in reading the data with a small number of queries and when removing resources. With the increase in the number of queries, a clear advantage of the REST standard was observed. The advantage of GraphQL, both in response time and size, was demonstrated when retrieving specific data.
PL
W artykule przeprowadzono analizę porównawczą dwóch najczęściej stosowanych standardów projektowania internetowego API – REST oraz GraphQL. Badano czas oraz rozmiar odpowiedzi HTTP zwracanych przez aplikacje. Do badań wykorzystano dwie aplikacje o takich samych funkcjonalnościach, realizujących operacje CRUD, na danych przechowywanych w nierelacyjnej bazie MongoDB. Obie aplikacje stworzono w oparciu o technologię NodeJS. Do zebrania i analizy danych zastosowano narzędzie JMeter. Na podstawie otrzymanych wyników stwierdzono brak znacznych różnic w odczycie danych przy małej liczbie zapytań oraz podczas usuwania zasobów. Wraz ze wzrostem liczby zapytań zaobserwowano wyraźną przewagę standardu REST. Przewagę GraphQL, zarówno w czasie jak i rozmiarze odpowiedzi, wykazano w przypadku pobierania specyficznych danych.
PL
W językach z automatycznym zarządzaniem pamięcią ważną rolę pełni odśmiecacz pamięci - mechanizm odpowiedzialny za usuwanie nieużywanych obiektów z pamięci. Algorytmy odzyskiwania pamięci są rozwijane od wielu lat i dążą do zmaksymalizowania wydajności aplikacji. W niniejszym artykule przedstawiono i porównano wydajność pięciu algorytmów automatycznego zwalniania pamięci występujących w Javie w wersji 12 na trzech aplikacjach o różnym czasie życia obiektów. Analizie została poddana szybkość aplikacji, narzut pracy odzyskiwaczy pamięci oraz przepustowość aplikacji przy dużym obciążeniu.
EN
In programming languages with automatic memory management garbage collection plays an important role of cleaning unused memory. Garbage collection algorithms have been developed for many years and aim to maximize the application’s performance. This paper presents and compares a performance of five garbage collection algorithms present in current version of Java 12 in three applications with different object lifetime span. The analysis covered the system responsiveness, garbage collector workload and application throughput at high application load.
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ć.