Często zadawane pytania dotyczące wydajności aplikacji dla Web Apps na platformie Azure
Uwaga
Niektóre z poniższych wytycznych mogą działać tylko w systemie Windows lub Linux App Services. Na przykład usługi App Services systemu Linux są domyślnie uruchamiane w trybie 64-bitowym.
Ten artykuł zawiera odpowiedzi na często zadawane pytania dotyczące problemów z wydajnością aplikacji Web Apps funkcji Azure App Service.
Jeśli problem z platformą Azure nie został rozwiązany w tym artykule, odwiedź fora platformy Azure w witrynach MSDN i Stack Overflow. Możesz opublikować swój problem na tych forach lub opublikować na @AzureSupport w serwisie Twitter. Możesz również przesłać żądanie pomoc techniczna platformy Azure. Aby przesłać wniosek o pomoc techniczną, na stronie pomoc techniczna platformy Azure wybierz pozycję Uzyskaj pomoc techniczną.
Dlaczego mój plan App Service wyświetla użycie procesora CPU/pamięci nawet wtedy, gdy wszystkie Web Apps są zatrzymane?
Azure App Service wymaga ciągłych procesów systemowych, które obsługują kilka operacji i funkcji platformy, takich jak aktualizacje zabezpieczeń, dostępność konsoli SCM, monitorowanie aplikacji, uwierzytelnianie i wiele innych istotnych funkcji aplikacji internetowej.
Procesy systemowe będą uruchamiane w planach App Service, nawet jeśli nie są uruchomione żadne Web Apps lub plan App Service nie zawiera Web Apps.
Procesy platformy będą zużywać minimalną ilość zasobów (takich jak procesor CPU, pamięć i miejsce na dysku), a to samo powinno być rozliczane podczas planowania pojemności, monitorowania i automatycznego skalowania konfiguracji wyzwalacza planu App Service.
Dlaczego moja aplikacja działa wolno?
Wiele czynników może przyczynić się do spowolnienia wydajności aplikacji. Aby uzyskać szczegółowe kroki rozwiązywania problemów, zobacz Rozwiązywanie problemów z niską wydajnością aplikacji internetowej.
Jak mogę rozwiązać problem ze scenariuszem wysokiego użycia procesora CPU?
W niektórych scenariuszach wysokiego użycia procesora CPU aplikacja może naprawdę wymagać większej ilości zasobów obliczeniowych. W takim przypadku rozważ skalowanie do wyższej warstwy usługi, aby aplikacja pobierała wszystkie potrzebne zasoby. Innym razem wysokie użycie procesora CPU może być spowodowane złą pętlą lub praktyką kodowania. Uzyskanie wglądu w to, co powoduje zwiększone użycie procesora CPU, to proces dwuczęściowy. Najpierw utwórz zrzut procesu, a następnie przeanalizuj zrzut procesu. Aby uzyskać więcej informacji, zobacz Przechwytywanie i analizowanie pliku zrzutu pod kątem wysokiego użycia procesora CPU dla Web Apps.
Jak mogę rozwiązać problem ze scenariuszem dużego użycia pamięci?
W niektórych scenariuszach dużego użycia pamięci aplikacja może naprawdę wymagać większej ilości zasobów obliczeniowych. W takim przypadku rozważ skalowanie do wyższej warstwy usługi, aby aplikacja pobierała wszystkie potrzebne zasoby. Innym razem usterka w kodzie może spowodować wyciek pamięci. Praktyka kodowania może również zwiększyć zużycie pamięci. Uzyskiwanie wglądu w to, co wyzwala wysokie zużycie pamięci, jest procesem dwuczęściowym. Najpierw utwórz zrzut procesu, a następnie przeanalizuj zrzut procesu. Narzędzie do diagnozowania awarii z galerii rozszerzeń witryny platformy Azure może efektywnie wykonać oba te kroki. Aby uzyskać więcej informacji, zobacz Przechwytywanie i analizowanie pliku zrzutu pod kątem sporadycznej wysokiej pamięci dla Web Apps.
Jak mogę zautomatyzować App Service aplikacje internetowe przy użyciu programu PowerShell?
Polecenia cmdlet programu PowerShell umożliwiają zarządzanie aplikacjami internetowymi i obsługę ich App Service. We wpisie w blogu Automatyzowanie aplikacji internetowych hostowanych w Azure App Service przy użyciu programu PowerShell opisano sposób używania poleceń cmdlet programu PowerShell opartych na usłudze Azure Resource Manager do automatyzowania typowych zadań. Wpis w blogu zawiera również przykładowy kod dla różnych zadań zarządzania aplikacjami internetowymi. Opisy i składnia wszystkich App Service poleceń cmdlet aplikacji internetowych można znaleźć w temacie Az.Websites.
Jak mogę wyświetlić dzienniki zdarzeń mojej aplikacji internetowej?
Aby wyświetlić dzienniki zdarzeń aplikacji internetowej:
- Zaloguj się do witryny internetowej Kudu (
https://*yourwebsitename*.scm.azurewebsites.net). - W menu wybierz pozycję Debuguj konsolę>CMD.
- Wybierz folder LogFiles .
- Aby wyświetlić dzienniki zdarzeń, wybierz ikonę ołówka obok eventlog.xml.
- Aby pobrać dzienniki, uruchom polecenie cmdlet
Save-AzureWebSiteLog -Name webappnameprogramu PowerShell .
Jak mogę przechwycić zrzut pamięci w trybie użytkownika mojej aplikacji internetowej?
Aby przechwycić zrzut pamięci w trybie użytkownika aplikacji internetowej:
- Zaloguj się do witryny internetowej Kudu (
https://*yourwebsitename*.scm.azurewebsites.net). - Wybierz menu Eksplorator procesów .
- Kliknij prawym przyciskiem myszy proces w3wp.exe lub proces zadania WebJob.
- Wybierz pozycję Pobierzpełne zrzuty>pamięci.
Jak mogę wyświetlić informacje na poziomie procesu dla mojej aplikacji internetowej?
Dostępne są dwie opcje wyświetlania informacji na poziomie procesu dla aplikacji internetowej:
- W Azure Portal:
- Otwórz Eksplorator procesów dla aplikacji internetowej.
- Aby wyświetlić szczegóły, wybierz procesw3wp.exe .
- W konsoli Kudu:
- Zaloguj się do witryny internetowej Kudu (
https://*yourwebsitename*.scm.azurewebsites.net). - Wybierz menu Eksplorator procesów .
- W przypadku procesuw3wp.exe wybierz pozycję Właściwości.
- Zaloguj się do witryny internetowej Kudu (
Gdy przeglądam aplikację, widzę komunikat "Błąd 403 — ta aplikacja internetowa została zatrzymana". Jak mogę rozwiązać ten problem?
Ten błąd może powodować trzy warunki:
- Aplikacja internetowa osiągnęła limit rozliczeń, a witryna została wyłączona.
- Aplikacja internetowa została zatrzymana w portalu.
- Aplikacja internetowa osiągnęła limit przydziału zasobów, który może mieć zastosowanie do planu usługi skalowania bezpłatnego lub udostępnionego.
Aby zobaczyć, co jest przyczyną błędu i rozwiązać problem, wykonaj kroki opisane w Web Apps: "Błąd 403 — ta aplikacja internetowa została zatrzymana".
Gdzie mogę dowiedzieć się więcej na temat limitów przydziałów i limitów dla różnych planów App Service?
Aby uzyskać informacje na temat limitów przydziałów i limitów, zobacz App Service limity.
Jak mogę skrócić czas odpowiedzi dla pierwszego żądania po czasie bezczynności?
Domyślnie aplikacje internetowe są zwalniane, jeśli są bezczynne przez określony czas. Dzięki temu system może oszczędzać zasoby. Minusem jest to, że odpowiedź na pierwsze żądanie po wyładowaniu aplikacji internetowej jest dłuższa, aby umożliwić aplikacji internetowej ładowanie i rozpoczynanie obsługi odpowiedzi. W planach usługi Podstawowa i Standardowa możesz włączyć ustawienie Zawsze włączone , aby aplikacja była zawsze ładowana. Eliminuje to dłuższe czasy ładowania po bezczynności aplikacji. Aby zmienić ustawienie Zawsze włączone :
- W Azure Portal przejdź do aplikacji internetowej.
- Wybierz pozycję Konfiguracja
- Wybierz pozycję Ustawienia ogólne.
- W obszarze Zawsze włączone wybierz pozycję Włączone.
Jak mogę włączyć śledzenie żądań zakończonych niepowodzeniem?
Aby włączyć śledzenie żądań zakończonych niepowodzeniem, wykonaj następujące kroki:
W Azure Portal przejdź do aplikacji internetowej.
Wybierz pozycję Wszystkie ustawienia>Dzienniki diagnostyczne.
W polu Śledzenie żądań zakończonych niepowodzeniem wybierz pozycję Włączone.
Wybierz Zapisz.
W bloku aplikacji internetowej wybierz pozycję Narzędzia.
Wybierz pozycję Visual Studio Online.
Jeśli ustawienie nie jest włączone, wybierz pozycję Włączone.
Wybierz pozycję Idź.
Wybierz pozycjęWeb.config.
W pliku system.webServer dodaj następującą konfigurację (aby przechwycić określony adres URL):
<system.webServer> <tracing> <traceFailedRequests> <remove path="*api*" /> <add path="*api*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" /> </traceAreas> <failureDefinitions statusCodes="200-999" /> </add> </traceFailedRequests> </tracing>Aby rozwiązać problemy z niską wydajnością, dodaj tę konfigurację (jeśli żądanie przechwytywania trwa dłużej niż 30 sekund):
<system.webServer> <tracing> <traceFailedRequests> <remove path="*" /> <add path="*"> <traceAreas> <add provider="ASP" verbosity="Verbose" /> <add provider="ASPNET" areas="Infrastructure,Module,Page,AppServices" verbosity="Verbose" /> <add provider="ISAPI Extension" verbosity="Verbose" /> <add provider="WWW Server" areas="Authentication,Security,Filter,StaticFile,CGI,Compression, Cache,RequestNotifications,Module,FastCGI" verbosity="Verbose" /> </traceAreas> <failureDefinitions timeTaken="00:00:30" statusCodes="200-999" /> </add> </traceFailedRequests> </tracing>Aby pobrać ślady żądań zakończonych niepowodzeniem, w portalu przejdź do witryny internetowej.
Wybierz pozycję Narzędzia>Kudu>Go.
W menu wybierz pozycję Debuguj konsolę>CMD.
Wybierz folder LogFiles , a następnie wybierz folder o nazwie rozpoczynającej się od W3SVC.
Aby wyświetlić plik XML, wybierz ikonę ołówka.
Widzę komunikat "Proces roboczy zażądał odtworzenia z powodu limitu "Procent pamięci". Jak mogę rozwiązać ten problem?
Maksymalna dostępna ilość pamięci dla procesu 32-bitowego (nawet w 64-bitowym systemie operacyjnym) wynosi 2 GB. Domyślnie proces roboczy jest ustawiony na 32-bitowe App Service (w celu zapewnienia zgodności ze starszymi aplikacjami internetowymi).
Rozważ przełączenie się na procesy 64-bitowe, aby móc korzystać z dodatkowej pamięci dostępnej w roli procesu roboczego sieci Web. Ta akcja wyzwala ponowne uruchomienie aplikacji internetowej, więc odpowiednio zaplanuj.
Należy również pamiętać, że środowisko 64-bitowe wymaga planu usługi Podstawowa lub Standardowa. Plany bezpłatne i udostępnione są zawsze uruchamiane w środowisku 32-bitowym.
Aby uzyskać więcej informacji, zobacz Konfigurowanie aplikacji internetowych w App Service.
Dlaczego moje żądanie przekracza limit czasu po 230 sekundach?
Azure Load Balancer ma domyślne ustawienie limitu czasu bezczynności wynoszące cztery minuty. To ustawienie jest zazwyczaj rozsądnym limitem czasu odpowiedzi dla żądania internetowego. dlatego App Service zwraca klientowi limit czasu, jeśli aplikacja nie zwróci odpowiedzi w ciągu około 240 sekund (230 sekund w aplikacji systemu Windows, 240 sekund w aplikacji systemu Linux). Jeśli aplikacja internetowa wymaga przetwarzania w tle, zalecamy korzystanie z zadań WebJob platformy Azure. Aplikacja internetowa platformy Azure może wywoływać zadania WebJob i być powiadamiana po zakończeniu przetwarzania w tle. Możesz wybrać jedną z wielu metod korzystania z zadań WebJob, w tym kolejek i wyzwalaczy.
Zadania WebJob są przeznaczone do przetwarzania w tle. W ramach zadania WebJob można wykonać tyle przetwarzania w tle, ile chcesz. Aby uzyskać więcej informacji na temat zadań WebJob, zobacz Uruchamianie zadań w tle przy użyciu zadań WebJob.
ASP.NET Core aplikacje hostowane w App Service czasami przestają odpowiadać. Jak mogę rozwiązać ten problem?
Znany problem z wcześniejszą wersją programu Kestrel może spowodować, że aplikacja ASP.NET Core 1.0 hostowana w App Service sporadycznie przestaje odpowiadać. Może zostać również wyświetlony następujący komunikat: "Określona aplikacja CGI napotkała błąd, a serwer zakończył proces".
Ten problem został rozwiązany w wersji Kestrel w wersji 1.0.2. Ta wersja jest uwzględniona w aktualizacji ASP.NET Core 1.0.3. Aby rozwiązać ten problem, upewnij się, że zależności aplikacji zostały zaktualizowane tak, aby korzystały z wersji Kestrel 1.0.2. Alternatywnie można użyć jednego z dwóch obejść opisanych we wpisie w blogu ASP.NET Core 1.0 problemy z powolnym wydajnością w App Service aplikacji internetowych.
Nie mogę znaleźć plików dziennika w strukturze plików mojej aplikacji internetowej. Jak je znaleźć?
Jeśli używasz funkcji lokalnej pamięci podręcznej App Service, ma to wpływ na strukturę folderów LogFiles i Data dla wystąpienia App Service. Gdy jest używana lokalna pamięć podręczna, podfoldery są tworzone w folderach LogFiles i Data magazynu. Podfoldery używają wzorca nazewnictwa "unikatowy identyfikator" i sygnatury czasowej. Każdy podfolder odpowiada wystąpieniu maszyny wirtualnej, w którym aplikacja internetowa jest uruchomiona lub została uruchomiona.
Aby określić, czy używasz lokalnej pamięci podręcznej, sprawdź kartę ustawienia aplikacji App Service. Jeśli jest używana lokalna pamięć podręczna, ustawienie WEBSITE_LOCAL_CACHE_OPTION aplikacji jest ustawione na Always.
Jeśli nie używasz lokalnej pamięci podręcznej i występuje ten problem, prześlij wniosek o pomoc techniczną.
Widzę komunikat "Podjęto próbę uzyskania dostępu do gniazda w sposób zabroniony przez jego uprawnienia dostępu". Jak mogę rozwiązać ten błąd?
Ten błąd zwykle występuje, jeśli wychodzące połączenia TCP w wystąpieniu maszyny wirtualnej zostaną wyczerpane. W App Service są wymuszane limity maksymalnej liczby połączeń wychodzących, które mogą być nawiązywane dla każdego wystąpienia maszyny wirtualnej. Aby uzyskać więcej informacji, zobacz Limity liczbowe między maszynami wirtualnymi.
Ten błąd może również wystąpić, jeśli spróbujesz uzyskać dostęp do adresu lokalnego z aplikacji. Aby uzyskać więcej informacji, zobacz Lokalne żądania adresów.
Aby uzyskać więcej informacji na temat połączeń wychodzących w aplikacji internetowej, zobacz wpis w blogu dotyczący połączeń wychodzących z witrynami internetowymi platformy Azure.
Jak mogę zdalnego debugowania aplikacji internetowej App Service za pomocą programu Visual Studio?
Aby uzyskać szczegółowy przewodnik pokazujący sposób debugowania aplikacji internetowej przy użyciu programu Visual Studio, zobacz Zdalne debugowanie aplikacji internetowej App Service.
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii platformy Azure.