Przyczyną takiego zachowania było ustawienie wartości Maksymalna liczba procesów roboczych większej niż 1 i ustawienie sesji w aplikacji webowej na InProc. Ta wartość mówi o ilości kopii programu uruchomionych w pamięci. Można ją znaleźć w ustawieniach zaawansowanych puli IISa (poniżej zrzut dla IIS 7.5).
Początkowo wydawało mi się, że to samo zło. Aczkolwiek po przemyśleniach doszedłem do konstruktywnego wniosku kiedy może nam się to przydać:
1) Wstępne testowanie aplikacji, która ma działać w przyszłości z load balancerem lub w cloudzie (np. AWS)
2) Weryfikacja aplikacji pod kątem wykorzystywania sesji (np. pod kątem poprawnej implementacji)
W sytuacji kiedy maksymalna ilość procesów roboczych może być większa niż 1 na danej puli, występuje w sytuacji, gdy przechowujemy sesję po stronie bazy danych lub po stronie state server'a. Baza danych ma tą wadę, że wymaga konfiguracji i dodatkowego utrzymania i najczęściej oznacza konieczność utrzymania dodatkowego serwera. W przypadku state server'a możemy go skonfigurować tylko i wyłącznie na jednej maszynie, dlatego przy load balancerze, gdy jeden node przestanie działać, i będzie to ten ze state server'em - to aplikacja przestanie działać. Jeżeli skorzystamy z bazy danych - jesteśmy bezpieczniejsi - tak długo jak długo serwer działa bezproblemowo (np. korzystamy z klastra).
Brak komentarzy:
Prześlij komentarz