Aplikacja IIS7 ASP.NET - 2 identyczne aplikacje w 2 identycznych pulach aplikacji, 1 odpowiada, a 1 nie


12

Mam aplikację sieci web ASP.NET (v4.0), która jest zainstalowana w katalogu wirtualnym (jako aplikacja) i jest hostowana we własnej puli aplikacji. Jest to powtarzane dla każdego wystąpienia aplikacji (tj. Na klienta).

Pule aplikacji są w trybie zintegrowanym (nie klasycznym), a LoadUserProfile ma wartość true. W przeciwnym razie ustawienia domyślne.

Każda instancja ma obecnie własną kopię kodu / config i własny folder danych (podstawowy plik do odczytu / zapisu).

1 wystąpienie tej aplikacji działa dobrze (operacja używana do porównania zajmuje ~ 4 sekundy). Co druga instancja działa powoli (od 10-25 sekund dla tej samej operacji).

Jeśli przeniosę wolniejszą instancję do „najszybszej” puli aplikacji, ta instancja ożyje. Jeśli przeniosę szybszą instancję do wolniejszej puli aplikacji, instancja spowolni do indeksowania.

Pule aplikacji zostały utworzone początkowo w ten sam sposób - ręcznie. Później użyłem procedury kopiowania PowerShell, aby zapewnić dokładną kopię szybszej puli aplikacji i nadal to samo zachowanie. Porównanie plików apppool.config pokazuje, że są one identyczne z wyjątkiem przypisań do katalogu wirtualnego.

O ile wiem, nie ma żadnych współużytkowanych zasobów, które są blokowane, i przetestowałem to, zamykając wydajną pulę aplikacji i ponownie uruchamiając ... powolność jest nadal wolna, a następnie po ponownym uruchomieniu tej puli aplikacji (więc jest ładowana ostatnia) jest jeszcze szybsza ...


A foldery aplikacji są identyczne pod względem bajtów?
usr

Tak, tylko potrójnie zaznaczone, ale jedyną różnicą jest plik web.config, w którym określa on nazwę katalogu wirtualnego, w którym jest on hostowany (i sprawdziłem też dwukrotnie, to była jedyna różnica). Każdy inny plik jest identyczny bajtowo. .

Co robi aplikacja, która zajmuje więcej czasu w jednym pakiecie aplikacji? Czy możesz dołączyć VS i wstrzymać debuger, aby go profilować?
usr

Nie mam zainstalowanego VS na serwerze, ponieważ jest to system produkcyjny, ale wygląda na to, że to mój następny przystanek. Jestem częściowo w trakcie dodawania masowo pełnego rejestrowania do dostępu do danych i komponentów dostępu do plików, ponieważ śledzenie, które pokazaliśmy, nie wykazało jeszcze nic konkretnego. Zdobędę trochę statystyk i dodam to jak najszybciej - byłem optymistą, że ktoś mógł spotkać się z podobnym, więc mogłem ominąć tę ścieżkę

1
Ponieważ ładujesz profil użytkownika, wydaje się, że jest to kluczowa różnica między tymi pulami aplikacji. Sprawdź lokalizacje tymczasowe tych użytkowników, uprawnienia do zapisu tam plików, a jeśli łączysz się z bazą danych za pomocą tego samego użytkownika, sprawdź również uprawnienia do bazy danych. Wystarczy, aby zapytanie przekroczyło limit czasu dla tego użytkownika, więc przetestuj z tą samą bazą danych, jeśli to możliwe. Powodzenia!

Odpowiedzi:


1

Aby dalej izolować problem, sugeruję uruchomienie Wireshark (lub innego wybranego analizatora pakietów) w systemie hosta na dwie sesje. Zakładam, że każda pula aplikacji ma przypisany unikalny adres IP lub unikalny port.

Najpierw uzyskaj podstawową wydajność, filtrując według adresu IP: portu twojej szybkiej puli aplikacji. Zobacz, jak wygląda ruch do iz aplikacji w „normalnych” warunkach.

Podczas drugiego uruchomienia musisz przechwycić ruch z powolnej / niereagującej puli aplikacji. Jeśli wszystkie routery sieciowe i takie są prawidłowe do samego pudełka, powinieneś zobaczyć powtarzające się żądania w jednym kierunku, najprawdopodobniej do aplikacji z innego miejsca, ALE jeśli twoja aplikacja wysyła wiele żądań do innego serwera, ruch może być ciężkie wyjście zamiast wejścia.

Ten test pokaże, czy problem dotyczy aplikacji, czy problemy związane z protokołem TCP / IP powodują, że żądania aplikacji są przekroczone z powodu niskiej / braku komunikacji.

Skoreluj znaczniki czasowe swoich testów z dziennikami zdarzeń serwera i (jeśli dotyczy) dziennikami śledzenia, i powinieneś być w stanie zająć się problemem.


0

Śledzenie nieudanych żądań (FRT) będzie najlepszym narzędziem do śledzenia tego. Pokaże rurociąg i czas potrzebny na wykonanie każdego kroku. To powinno wskazać, czy jest to coś w części asp.net, czy też jest to coś w samym potoku IIS.

Aby skonfigurować FRT, z IIS na poziomie witryny utwórz regułę FRT z zakresem statusu HTTP 200–999 i upewnij się, że włączasz FRT (jest to oddzielny krok od panelu akcji).

Następnie odtwórz problem i spójrz na wygenerowane pliki (% SystemDrive% \ inetpub \ logs \ FailedReqLogFiles \ w3svc {siteid}). Otwórz je w przeglądarce Internet Explorer.


0

Gdy usługi IIS opóźniają się przez długi czas bez wyraźnego powodu, zwykle oznacza to, że oczekuje na przekroczenie limitu czasu przez usługę zewnętrzną. Kiedy tak się dzieje, próbuje innego podejścia. W tym przypadku dotyczy to prawie wszystkiego w systemie Windows lub Linux. Pierwszym podejrzanym dla mnie w takich sytuacjach jest zawsze konfiguracja rozpoznawania nazw sieci. Jest winny, dopóki nie zostanie udowodniony niewinności.

Czy można to odtworzyć, gdy jeden użytkownik wejdzie na jedną ze zduplikowanych witryn? Dobrze byłoby wiedzieć, co robią procesor i dyski podczas odtwarzania czasu reakcji od 10 do 20 sekund. Jeśli wydaje się, że w ciągu 10-20 sekund niewiele się dzieje, powinieneś sprawdzić swoje wiążące nazwy i rozpoznawanie nazw dla powiązanych nazw. Jeśli procesor lub dyski przegryzają, musisz dowiedzieć się, który proces działa zbyt ciężko i dlaczego.

Proszę opublikować swoje odkrycia, jestem ciekawy.

PS Sprawdziłbym także rozpoznawanie nazw i dostęp do wszelkich usług uwierzytelniania, które mogą być w grze. Na przykład, jeśli trzeba skonsultować się z serwerem domeny, upewnij się, że pierwszym serwerem DNS na liście jest serwer DNS dla domeny.


0

To nie jest rozwiązanie, ale będziemy nad tym pracować;

  1. Uruchom IISRESET (w godzinach konserwacji) lub zabij W3WP, który należy do niereagującej puli aplikacji

  2. Uruchom aplikację

  3. Chociaż nie odpowiada, pobierz plik zrzutu W3WP, który należy do wolnej puli aplikacji. Użyj eksploratora procesów lub menedżera zadań, aby utworzyć plik zrzutu

  4. Chwyć mscordacwks.dll i mscorwks.dll spod C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.XXXXX

  5. Spakuj i prześlij te pliki gdzieś, skąd mogę je pobrać.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.