Testowanie obciążenia platformy Azure za pomocą wtyczek niestandardowych

Artykuł
01/27/2024

Pomysły dotyczące rozwiązań

W tym artykule opisano pomysł rozwiązania. Architekt chmury może użyć tych wskazówek, aby ułatwić wizualizowanie głównych składników dla typowej implementacji tej architektury. Skorzystaj z tego artykułu jako punktu wyjścia, aby zaprojektować dobrze zaprojektowane rozwiązanie zgodne z konkretnymi wymaganiami obciążenia.

To rozwiązanie zawiera wskazówki dotyczące korzystania z testowania obciążenia platformy Azure, usługi, która umożliwia uruchamianie skryptów Apache JMeter i wtyczek niestandardowych w celu symulowania zachowań użytkowników i urządzeń. To rozwiązanie wyjaśnia również, jak zaprojektować kluczowe wskaźniki wydajności (KPI) i opracować pulpit nawigacyjny do monitorowania i analizowania wyników testu obciążeniowego w przykładowej aplikacji za pomocą usług Azure Functions i Azure Event Hubs. W tym artykule założono, że masz pewną znajomość narzędzia JMeter, jego wtyczek i wtyczek niestandardowych, a także usług Azure Functions i Event Hubs.

Architektura

Do przeprowadzania testów obciążeniowych potrzebny jest plan testu, który jest zestawem instrukcji, które informują JMeter, co należy zrobić podczas testu. Plan testu może obejmować wiele scenariuszy testowych, z których każdy ma różne ustawienia i konfiguracje. Na przykład może istnieć jeden scenariusz, który symuluje pojedynczego użytkownika, który uzyskuje dostęp do aplikacji internetowej, i inny scenariusz, który symuluje jednoczesne uzyskiwanie dostępu do tej samej aplikacji przez wielu użytkowników.

Plan testu może również obejmować wiele przypadków testowych, z których każdy ma różne ustawienia i konfiguracje. W naszym przypadku zakładamy, że istnieje urządzenie, które zgłasza temperaturę i wilgotność w określonym przedziale czasu. Urządzenie wysyła dane do centrum zdarzeń na platformie Azure. Centrum zdarzeń wyzwala funkcję platformy Azure odpowiedzialną za przetwarzanie danych, a następnie wysyłanie danych do innych usług podrzędnych, takich jak Usługa Azure SQL Database. Funkcja platformy Azure to usługa, którą chcemy przetestować. Plan testowania jest przeznaczony do symulowania zachowania urządzenia i wysyłania danych do centrum zdarzeń.

Pobierz plik programu Visio z tą architekturą.

Przepływ danych

W tym przykładzie przepływ danych jest następujący:

Symulowane urządzenie wysyła dane do centrum zdarzeń za pośrednictwem agenta testowania obciążenia platformy Azure. Dowolne zachowanie urządzenia można symulować przy użyciu wtyczek niestandardowych JMeter. Agent usługi Azure Load Test odpowiada za wysyłanie danych do centrum zdarzeń po uruchomieniu niestandardowej wtyczki dla dowolnego typu symulowanych urządzeń.
Centrum zdarzeń wyzwala funkcję platformy Azure odpowiedzialną za przetwarzanie danych, a następnie wysyłanie danych do innych usług podrzędnych, takich jak Azure SQL Database i Azure Digital Twins.
Usługa Azure Monitor służy do monitorowania funkcji platformy Azure i usługi Event Hubs.
Usługa Azure Load Testing zbiera dane z usługi Azure Monitor, a następnie wyświetla je na pulpicie nawigacyjnym.

Składniki

W tym przykładzie używane są następujące składniki:

Testowanie obciążenia platformy Azure: Testowanie obciążenia platformy Azure umożliwia uruchamianie skryptów apache JMeter i wtyczek niestandardowych w celu symulowania zachowań użytkowników i urządzeń. Udostępnia internetowy interfejs do zarządzania i uruchamiania testów obciążeniowych oraz zestawu interfejsów API, które mogą służyć do automatyzacji procesu. Testowanie obciążenia platformy Azure to w pełni zarządzana usługa, co oznacza, że nie musisz martwić się o zarządzanie serwerami ani infrastrukturą. Możesz przekazać skrypty JMeter i niestandardowe wtyczki, a testowanie obciążenia platformy Azure obsługuje resztę.
Azure Event Hubs: Azure Event Hubs to oparta na chmurze usługa przetwarzania zdarzeń, która może służyć do zbierania, przetwarzania i analizowania zdarzeń oraz przesyłania strumieniowego danych z różnych źródeł w czasie rzeczywistym. Usługa Event Hubs obsługuje wiele protokołów, w tym AMQP (Advanced Message Queuing Protocol), HTTPS, Kafka Protocol, MQTT (Message Queuing Telemetry Transport) i AMQP za pośrednictwem protokołu WebSocket. Wybór odpowiedniego protokołu zależy od kilku czynników, w tym typu danych, z którymi pracujesz, określonych wymagań aplikacji oraz możliwości i ograniczeń protokołów.
Azure Functions: Usługa Azure Functions to bezserwerowa usługa obliczeniowa, która umożliwia uruchamianie kodu bez konieczności zarządzania serwerami lub infrastrukturą. Obsługuje wiele języków programowania, w tym C#, F#, Java, JavaScript, PowerShell, Python i TypeScript. Usługa Azure Functions może służyć do przetwarzania zdarzeń i przesyłania strumieniowego danych z usługi Event Hubs, a także innych źródeł, takich jak Azure Storage i Azure Cosmos DB.
Graficzny interfejs użytkownika JMeter: graficzny interfejs użytkownika JMeter to narzędzie do testowania obciążenia typu open source, które jest używane głównie do testowania wydajności aplikacji internetowych. Pierwotnie został opracowany do testowania aplikacji internetowych. Można go jednak również używać do testowania innych typów aplikacji, takich jak usługi internetowe SOAP i REST, serwery FTP i bazy danych.
Azure Monitor: usługa Azure Monitor zapewnia funkcje monitorowania i zgłaszania alertów dla zasobów platformy Azure. Umożliwia ona również monitorowanie wydajności i kondycji aplikacji oraz podstawowej infrastruktury. Usługa Azure Monitor może służyć do monitorowania usług Event Hubs i Azure Functions, a także innych usług platformy Azure, takich jak Azure Storage i Azure Cosmos DB.

Szczegóły scenariusza

Testowanie obciążenia platformy Azure umożliwia użycie istniejącego skryptu Apache JMeter i użycie go do uruchomienia testu obciążeniowego w skali chmury na dowolnym zasobie platformy Azure.

Narzędzie JMeter umożliwia testerom tworzenie i wykonywanie testów obciążeniowych, testów obciążeniowych i testów funkcjonalnych. Symuluje ona wielu użytkowników jednocześnie uzyskuje dostęp do aplikacji internetowej, umożliwiając testerom identyfikowanie potencjalnych wąskich gardeł wydajności lub innych problemów, które mogą wystąpić w przypadku dużych obciążeń. JMeter może służyć do mierzenia różnych metryk wydajności, takich jak czas odpowiedzi, przepływność i szybkość błędów.

Funkcja JMeter używa interfejsu graficznego interfejsu użytkownika, aby umożliwić użytkownikom tworzenie planów testów, które mogą obejmować wiele scenariuszy testowych, z których każdy ma różne ustawienia i konfiguracje. Testerzy mogą również dostosowywać JMeter przy użyciu wtyczek lub pisząc kod niestandardowy, co pozwala im rozszerzyć jego funkcjonalność poza to, co wychodzi z pudełka. Wtyczki mogą pomóc nam pracować z usługami korzystającymi z protokołów innych niż HTTP, takich jak AMQP i Websocket.

Chociaż narzędzie JMeter oferuje szeroką gamę funkcji i funkcji do testowania obciążenia, mogą istnieć konkretne przypadki użycia lub wymagania, które nie są objęte wbudowanymi funkcjami. Tworząc niestandardowe wtyczki, testerzy mogą dodawać nowe funkcje lub dostosowywać istniejące funkcje, aby lepiej dopasować je do swoich potrzeb

Na przykład można utworzyć wtyczkę niestandardową w celu symulowania określonego typu zachowania użytkownika lub generowania bardziej realistycznych danych testowych. Ponadto można opracowywać niestandardowe wtyczki w celu zintegrowania narzędzia JMeter z innymi narzędziami lub systemami, takimi jak narzędzia rejestrowania i raportowania lub potoki ciągłej integracji i wdrażania. Niestandardowe wtyczki mogą pomóc usprawnić proces testowania i ułatwić dołączanie testów obciążeniowych do ogólnego przepływu pracy tworzenia oprogramowania. Ogólnie rzecz biorąc, umożliwiają testerom dostosowanie JMeter do określonych potrzeb i zwiększenie dokładności i skuteczności wysiłków związanych z testowaniem obciążenia.

W tym przykładzie przyjęto założenie, że istnieje urządzenie, które zgłasza temperaturę i wilgotność w określonym przedziale czasu. Możemy symulować to proste zachowanie przy użyciu niestandardowej wtyczki JMeter. W bieżącej implementacji wtyczki niestandardowej udostępnionej tutaj generujemy losowe dane przy użyciu dostarczonego szablonu. Jednak wtyczka może zawierać wszelkie możliwe złożone zachowanie dla wszystkich urządzeń. W tym przykładzie urządzenie wysyła dane do centrum zdarzeń na platformie Azure. Centrum zdarzeń wyzwala funkcję platformy Azure, która jest odpowiedzialna za przetwarzanie danych, a następnie wysyłanie danych do innych usług podrzędnych, takich jak Usługa Azure SQL Database. Funkcja platformy Azure to usługa, którą chcemy przetestować. Plan testowania jest przeznaczony do symulowania zachowania urządzenia i wysyłania danych do centrum zdarzeń.

Potencjalne przypadki użycia

Korzystanie z usługi Azure Load Testing z niestandardowymi wtyczkami może być przydatne w różnych scenariuszach, takich jak:

Testowanie wydajności aplikacji korzystającej z protokołów innych niż HTTP, takich jak AMQP i Websocket.
Testowanie wydajności aplikacji korzystającej z protokołu niestandardowego.
Testowanie wydajności aplikacji korzystającej z zestawu SDK firmy innej niż Microsoft.
Symulowanie określonego typu zachowania użytkownika lub urządzenia lub generowanie bardziej realistycznych danych testowych.

Wtyczki niestandardowe

Niestandardowe wtyczki w kontekście narzędzia JMeter to składniki oprogramowania, które można dodać do narzędzia JMeter, aby rozszerzyć jego funkcjonalność poza to, co wychodzi z pudełka. Użytkownicy lub deweloperzy spoza firmy Microsoft mogą tworzyć niestandardowe wtyczki, aby dodawać nowe funkcje, funkcje lub integracje do narzędzia JMeter. Niestandardowe wtyczki można opracowywać przy użyciu języka programowania Java i zestawu JMeter Plugin Development Kit (PDK). PdK udostępnia zestaw narzędzi i interfejsów API, które ułatwiają tworzenie nowych wtyczek, w tym elementów graficznego interfejsu użytkownika, odbiorników i przykładów.

Niestandardowe wtyczki mogą dodawać szeroką gamę funkcji do funkcji JMeter. Mogą również zintegrować narzędzie JMeter z innymi systemami, takimi jak narzędzia do rejestrowania i raportowania, lub włączyć korzystanie z innych źródeł danych na potrzeby danych testowych. Ogólnie rzecz biorąc, niestandardowe wtyczki umożliwiają użytkownikom rozszerzenie JMeter w celu spełnienia określonych potrzeb i zwiększenia dokładności i skuteczności wysiłków związanych z testowaniem obciążenia.

Aby zaimplementować niestandardowy przykładnik dla usługi Event Hubs w narzędziu JMeter, postępuj zgodnie z instrukcjami podanymi w temacie Azure Load Testing Plugins (Wtyczki testowania obciążenia platformy Azure). Po zaimplementowaniu niestandardowego przykładu można go użyć w planie testu JMeter w usłudze Azure Load Test tak samo jak w przypadku każdego innego przykładnika.

Plan testu można zaimplementować przy użyciu grupy wątków, która kontroluje liczbę wątków (użytkowników wirtualnych i urządzeń) w celu wykonania określonego scenariusza. Każda grupa wątków może mieć różne ustawienia dotyczące liczby wątków, okresu zwiększania, liczby pętli i czasu trwania. Grupy wątków można uruchamiać sekwencyjnie lub równolegle, w zależności od konfiguracji planu testów i wymagań aplikacji. Możesz dodać przykładnik do grupy wątków, ustawić jego parametry i skonfigurować go zgodnie z potrzebami. Niestandardowe próbkatory mogą być zaawansowanymi narzędziami w narzędziu JMeter, co umożliwia symulowanie złożonych scenariuszy i żądań, które wbudowane próbkatory nie obsługują.

Tworzenie skryptu Apache JMeter z wtyczką niestandardową

W tej sekcji utworzysz przykładowy skrypt testu JMeter w celu przetestowania aplikacji za pomocą usługi Event Hubs.

Aby utworzyć przykładowy skrypt testowy JMeter:

Utwórz plik LoadTest.jmx na komputerze lokalnym:
```
touch LoadTest.jmx
```

Otwórz plik LoadTest.jmx w edytorze tekstów i wklej poniższy fragment kodu w pliku. Ten skrypt symuluje test obciążeniowy 36 maszyn wirtualnych, które jednocześnie wysyłają zdarzenia do centrum zdarzeń i trwa 10 minut:

<?xml version="1.0" encoding="UTF-8"?>
<jmeterTestPlan version="1.2" properties="5.0" jmeter="5.5">
    <hashTree>
    <TestPlan guiclass="TestPlanGui" testclass="TestPlan" testname="Test Plan" enabled="true">
        <stringProp name="TestPlan.comments"></stringProp>
        <boolProp name="TestPlan.functional_mode">false</boolProp>
        <boolProp name="TestPlan.tearDown_on_shutdown">true</boolProp>
        <boolProp name="TestPlan.serialize_threadgroups">false</boolProp>
        <elementProp name="TestPlan.user_defined_variables" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" testname="User Defined Variables" enabled="true">
        <collectionProp name="Arguments.arguments"/>
        </elementProp>
        <stringProp name="TestPlan.user_define_classpath"></stringProp>
    </TestPlan>
    <hashTree>
        <ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="Thread Group" enabled="true">
        <stringProp name="ThreadGroup.on_sample_error">continue</stringProp>
        <elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
            <boolProp name="LoopController.continue_forever">false</boolProp>
            <intProp name="LoopController.loops">-1</intProp>
        </elementProp>
        <stringProp name="ThreadGroup.num_threads">36</stringProp>
        <stringProp name="ThreadGroup.ramp_time">20</stringProp>
        <boolProp name="ThreadGroup.scheduler">true</boolProp>
        <stringProp name="ThreadGroup.duration">600</stringProp>
        <stringProp name="ThreadGroup.delay"></stringProp>
        <boolProp name="ThreadGroup.same_user_on_next_iteration">false</boolProp>
        </ThreadGroup>
        <hashTree>
        <com.microsoft.eventhubplugin.EventHubPlugin guiclass="com.microsoft.eventhubplugin.EventHubPluginGui" testclass="com.microsoft.eventhubplugin.EventHubPlugin" testname="Azure Event Hubs Sampler" enabled="true">
            <stringProp name="eventHubConnectionVarName">EventHubConnectionString</stringProp>
            <stringProp name="eventHubName">telemetry-data-changed-eh</stringProp>
            <stringProp name="liquidTemplateFileName">StreamingDataTemplate.liquid</stringProp>
        </com.microsoft.eventhubplugin.EventHubPlugin>
        <hashTree/>
        </hashTree>
    </hashTree>
    </hashTree>
</jmeterTestPlan>

Implementacja i com.microsoft.eventhubplugin.EventHubPluginGui com.microsoft.eventhubplugin.EventHubPlugin są dostępne w temacie Przykłady platformy Azure.

W pliku ustaw wartość eventHubConnectionVarName węzła na nazwę zmiennej, która określa host usługi Event Hubs parametry połączenia. Jeśli na przykład chcesz, aby EventHubConnectionStringzmienna środowiskowa przechowującą parametry połączenia usługi Event Hubs na wartość , ustaw tę zmienną na EventHubConnectionString , a następnie ustaw wartość zmiennej środowiskowej.

Ważne

Upewnij się, że wartość EventHubConnectionString elementu została ustawiona jako część procesu tworzenia testu obciążeniowego platformy Azure przed uruchomieniem skryptu testu obciążeniowego.
W pliku ustaw wartość węzła eventHubName na nazwę centrum zdarzeń, na przykład telemetry-data-changed-eh.
Ustaw wartość węzła liquidTemplateFileName na plik zawierający komunikat wysyłany do centrum zdarzeń. Na przykład utwórz plik o nazwie StreamingDataTemplate.liquid jako:
```
{
    {% assign numberOfMachines = 36 %}
    {% assign machineId = dataGenerator.randomNaturalNumber | modulo: numberOfMachines %}
    "MachineId": "{{machineId | prepend: '0000000000000000000000000000000000000000' | slice: -27, 27 }}"
    "Temperature": {{dataGenerator.randomInt | modulo: 100 }},
    "Humidity": {{dataGenerator.randomInt | modulo: 100 }}
}
```
W tym przykładzie ładunek komunikatu centrum zdarzeń jest obiektem JSON z trzema właściwościami, w tym MachineId, Temperaturei Humidity gdzie MachineId jest losowo generowanym identyfikatorem o długości 27 i Temperature Humidity są losowymi liczbami całkowitymi mniejszymi niż 100. Ten plik jest składnią szablonu liquid. Szablon Liquid to popularny język tworzenia szablonów używany w różnych strukturach tworzenia aplikacji internetowych. Szablony Liquid umożliwiają deweloperom tworzenie zawartości dynamicznej, którą można łatwo aktualizować i modyfikować. Umożliwiają one wstawianie zmiennych, warunków, pętli i innych elementów dynamicznych do komunikatów centrum zdarzeń. Składnia jest prosta i dostępnych jest wiele zasobów online, które ułatwiają rozpoczęcie pracy. Ogólnie rzecz biorąc, szablony Liquid oferują zaawansowany i elastyczny sposób tworzenia dynamicznych, dostosowywalnych komunikatów.
Zapisz i zamknij plik.

Ważne

Nie dołączaj żadnych danych osobowych do nazwy przykładowego skryptu JMeter. Nazwy przykładów są wyświetlane na pulpicie nawigacyjnym wyników testu obciążeniowego platformy Azure. Przykładowy szablon liquid wraz z plikiem skryptu JMeter jest dostępny do pobrania na stronie Przykłady platformy Azure

Uruchamianie testu obciążeniowego przy użyciu nowej wtyczki

Gdy testowanie obciążenia platformy Azure uruchamia test obciążeniowy, najpierw wdraża skrypt JMeter wraz ze wszystkimi innymi plikami w wystąpieniach aparatu testowego, a następnie uruchamia test obciążeniowy zgodnie z instrukcjami w temacie Dostosowywanie testu obciążeniowego przy użyciu wtyczek Apache JMeter i testowania obciążenia platformy Azure. Przed uruchomieniem testu przejdź do karty parametrów, zdefiniuj EventHubConnectionStringelement , a następnie podaj parametry połączenia do centrum zdarzeń.

Konfiguracja testowania wydajnościowego dla środowiska

W każdym testowaniu wydajnościowym ważne jest, aby środowisko produkcyjne było podobne do środowiska produkcyjnego. W tym przykładzie następujące środowisko jest używane do testowania wydajnościowego w celu lepszego zrozumienia pojemności systemu i wydajności systemu.

Na przykładową architekturę można użyć następujących usług do testowania wydajnościowego:

Usługa	Konfigurowanie
EventHub	Premium z jedną jednostką przetwarzania (PU).
Funkcja platformy Azure	Linux z planem Premium (EP1) — 210 ACU, 3,5 GB pamięci i 1 procesor wirtualny równoważne Standard_D1_v2
Region (Region)	Wschodnie stany USA

Wybór odpowiedniej warstwy usług dla dowolnych usług platformy Azure, w tym usługi Event Hubs i Azure Functions, jest złożonym procesem i zależy od wielu czynników. Aby uzyskać więcej informacji, zobacz Cennik usługi Azure Event Hubs i cennik usługi Azure Functions.

Projektowanie kluczowych wskaźników wydajności na potrzeby testowania wydajnościowego

Zanim będzie można zaprojektować kluczowe wskaźniki wydajności (KPI) na potrzeby testowania wydajnościowego, potrzebne są dwie elementy: wymagania biznesowe i architektura systemu. Wymagania biznesowe informują o tym, jakie wskaźniki KPI chcesz zmierzyć, takie jak czas odpowiedzi, przepływność lub współczynnik błędów. Architektura systemu informuje o tym, jak przetestować wydajność poszczególnych składników, takich jak serwery internetowe, bazy danych lub interfejsy API. Pomaga również wybrać najlepszą strategię testowania wydajnościowego, taką jak testowanie obciążenia, testy obciążeniowe lub testy wytrzymałościowe.

W tym przykładzie wymagania biznesowe to:

System powinien mieć możliwość obsługi 1000 żądań na sekundę.
Niezawodność systemu powinna być wyższa niż 0,99.
System powinien mieć możliwość obsługi 1000 równoczesnych urządzeń raportujących swoje dane osobowe.
Określenie maksymalnej pojemności systemu pod względem liczby urządzeń, które mogą być obsługiwane. Na przykład czy system z 3x bieżącej pojemności obsługuje 1000 równoczesnych urządzeń?

Zgodnie z tymi wymaganiami wskaźniki KPI na potrzeby testowania wydajnościowego mogą być następujące:

KLUCZOWY WSKAŹNIK WYDAJNOŚCI (KPI)	opis
RPS	Żądanie na sekundę dla centrum zdarzeń
ŁADUNEK	Liczba obciążeń lub żądań wysyłanych do centrum zdarzeń podczas testowania wydajnościowego
IR	Liczba wykonań funkcji lub współczynnik pozyskiwania
RT	Średni czas wykonywania funkcji platformy Azure
AMU	Średnie użycie pamięci dla usługi Azure Functions
SR	Współczynnik powodzenia wszystkich wykonań funkcji
ARS	Średni czas odpowiedzi usługi podrzędnej (na przykład program SQL Server lub mikrousługę)
DF	Liczba błędów zależności, w tym wewnętrzne błędy funkcji platformy Azure
MRPS	Maksymalna liczba żądań rpS bez listy prac w centrum zdarzeń (pojemność systemu)

Jak mierzyć kluczowe wskaźniki wydajności

Aby zmierzyć kluczowe wskaźniki wydajności, musisz mieć strategię testowania wydajnościowego. Strategia definiuje podejście do testowania wydajnościowego dla każdego składnika. W tym przykładzie jest używana następująca strategia testowania wydajnościowego:

Event Hubs: Podejście do testowania wydajności dla centrum zdarzeń polega na wysyłaniu wielu komunikatów do centrum zdarzeń, a następnie mierzenia punktów ściągnięć i ładowania. RpS to liczba komunikatów wysyłanych do centrum zdarzeń na sekundę. Funkcja LOAD to łączna liczba komunikatów wysyłanych do centrum zdarzeń podczas testowania wydajnościowego. Usługa Testowania obciążenia platformy Azure może mierzyć rpS i LOAD.
Azure Functions: Podejście do testowania wydajności dla usługi Azure Functions polega na mierzeniu następujących metryk:
- Środowisko IR to liczba wykonań funkcji lub współczynnik pozyskiwania.
- Rt to średni czas wykonywania funkcji platformy Azure.
- AMU to średnie użycie pamięci dla usługi Azure Functions.
- Sr to współczynnik powodzenia wszystkich wykonań funkcji.
- Usługa ARS to średni czas odpowiedzi usługi podrzędnej.
- Df to liczba błędów zależności, w tym wewnętrzne błędy funkcji platformy Azure.
- Usługa Azure Monitor może mierzyć AMU, ARS i DF, ale nie ir, RT lub SR.

Aby mierzyć wskaźniki KPI przy użyciu usługi Azure Monitor, musimy włączyć usługę Application Insights dla usługi Azure Functions. Aby uzyskać więcej informacji, zobacz Włączanie integracji usługi Application Insights.

Po włączeniu usługi Azure Monitor możesz użyć następujących zapytań do mierzenia wskaźników KPI:

IR: FunctionAppLogs | where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize count() by FunctionName, Level, bin(TimeGenerated, 1h) | order by FunctionName desc
RT: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed "| parse Message with "Executed " Name " (" Result ", Id=" Id ", Duration=" Duration:long "ms)"| project TimeGenerated, Message, FunctionName, Result, FunctionInvocationId, Duration
SR: FunctionAppLogs| where Category startswith "name-space-of-your-function" and Message startswith "Executed" | summarize Success=countif(Level == "Information" ), Total=count() by FunctionName| extend Result=Success*100.0/Total| project FunctionName, Result| order by FunctionName desc

Przykład pulpitu nawigacyjnego usługi Azure Monitor

Oto przykład pulpitu nawigacyjnego usługi Azure Monitor, który pokazuje kluczowe wskaźniki wydajności dla usługi Azure Functions na podstawie zapytań:

Podsumowanie

W tym artykule przedstawiono sposób projektowania kluczowych wskaźników wydajności i tworzenia pulpitu nawigacyjnego na potrzeby testu obciążeniowego platformy Azure. Pokazano również, jak używać wtyczek niestandardowych w narzędziu JMeter do przeprowadzania testów obciążenia w usłudze Azure Functions zintegrowanych z usługą Event Hubs. Możesz użyć tego samego podejścia, aby przeprowadzić testowanie obciążenia w innych usługach platformy Azure. Możesz również skonfigurować potok ciągłej integracji i ciągłego dostarczania (CI/CD) dla skryptów testowania obciążenia przy użyciu usługi Azure DevOps.

Aby uzyskać więcej informacji, zobacz Testowanie obciążenia platformy Azure.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

Mahdi Setayesh | Główny inżynier oprogramowania

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Udostępnij za pośrednictwem

Testowanie obciążenia platformy Azure za pomocą wtyczek niestandardowych

Architektura

Przepływ danych

Składniki

Szczegóły scenariusza

Potencjalne przypadki użycia

Wtyczki niestandardowe

Tworzenie skryptu Apache JMeter z wtyczką niestandardową

Uruchamianie testu obciążeniowego przy użyciu nowej wtyczki

Konfiguracja testowania wydajnościowego dla środowiska

Projektowanie kluczowych wskaźników wydajności na potrzeby testowania wydajnościowego

Jak mierzyć kluczowe wskaźniki wydajności

Przykład pulpitu nawigacyjnego usługi Azure Monitor

Podsumowanie

Współautorzy

Następne kroki

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Testowanie obciążenia platformy Azure za pomocą wtyczek niestandardowych

Architektura

Przepływ danych

Składniki

Szczegóły scenariusza

Potencjalne przypadki użycia

Wtyczki niestandardowe

Tworzenie skryptu Apache JMeter z wtyczką niestandardową

Uruchamianie testu obciążeniowego przy użyciu nowej wtyczki

Konfiguracja testowania wydajnościowego dla środowiska

Projektowanie kluczowych wskaźników wydajności na potrzeby testowania wydajnościowego

Jak mierzyć kluczowe wskaźniki wydajności

Przykład pulpitu nawigacyjnego usługi Azure Monitor

Podsumowanie

Współautorzy

Następne kroki

Powiązane zasoby

Opinia

Dodatkowe zasoby