Jeśli aplikacja regularnie napotyka na problemy wydajnościowe i wykonanie restartu rozwiązuje ten problem, można pomyśleć o skonfigurowaniu WebAppPool do automatycznego restartu. Odnalezienie właściwej opcji jest możliwe dzięki sprawdzaniu wartości zagnieżdżonych właściwości opcji. Najpierw sprawdź dostępne właściwości application pool:
PowerShell i IIS 16: Konfiguracja WebAppPool do autorestartu
2016-11-01
PowerShell i IIS 15: Administracja WebAppPool
2016-11-01
Ponieważ WebApplicationPool jest dla IIS furtką do korzystania z zasobów, to wymaga ona szczególnych czynności administracyjnych. Najczęstszym problemem rozwiązywanym przez administratora jest spadek wydajności dla aplikacji wykorzystującej wybrany application pool. Może to być powodowane (i najczęściej jest) przez wadliwy kod aplikacji WebSite, która np. nie zwalnia zajmowanej pamięci. Na szczęście w tym przypadku można wymusić restart aplikacji bez powodowania zatrzymania obsługi użytkowników i tym samym niedostępności usługi.
Aby po stronie IIS zrestartować Application Pool można skorzystać z polecenia Restart-WebAppPool:
PowerShell i IIS 14: Domyślne ustawienia dla nowych WebSite i WebApplicationPool
2016-11-01
Każdorazowo gdy tworzony jest nowy WebSite lub nowy WebApplicationPool, otrzymuje on pewne domyślne ustawienia. Te domyślne wartości można edytować w interfejsie graficznym za pomocą odnośników widocznych na panelu Actions:
PowerShell i IIS 13: Właściwości WebApplicationPool
2016-11-01
Aby przejrzeć właściwości WebApplicationPool skorzystaj z napędu IIS:\. W folderze AppPool znajdują się elementy reprezentujące Application Pool. Aby wyświetlić wszystkie właściwości prześlij taki obiekt potokiem do format-list:
PowerShell i IIS 12: Worker Process – w3wp
2016-11-01
Usługa IIS jest realizowana przez proces w3wp. Dokładniej, każdy WebSite jest przypisany do jakiegoś WebApplicationPool. WebApplicationPool jest z kolei obsługiwany przez co najmniej jeden „Worker proces”. Zazwyczaj jeden WebApplicationPool nie potrzebuje większej ilości Worker proces, ale jedną za technik optymalizacyjnych jest wprowadzenie wielowątkowości obsługi WebApplicationPool przez przypisanie do niej większej ilości procesów w3wp (worker thread). Jest to tzw. WebGarden (w odróżnieniu od Web Farm, które angażuje więcej serwerów tutaj mamy do czynienia tylko z jednym serwerem, na którym jest uruchomionych więcej procesów). Poniżej widać worker proces obsługujący WebApplicationPool DefaultAppPool:
PowerShell i IIS 11: IIS w Windows 2016
2016-10-30
Wraz z wersją Windows 2016, zarządzanie IIS z poziomu Powershell może się stać jeszcze prostsze, bo administratorzy oprócz modułu WebAdministration dostają także nowy IISAdministration. Ze względu na kompatybilność wsteczną starszy moduł nadal będzie dostarczany, jednak wielu administratorów stwierdza że praca z nowym modułem jest prostsza i bardziej intuicyjna.
Wiele z poleceń działa podobnie jeśli nie tak samo jak ich poprzedniki: Czytaj dalej »
PowerShell i IIS 10: WebApplication
2016-10-30
WebSites mogą korzystać z tego samego WebApplicationPool lub z różnych, co pozwala zapobiegać między innymi problemom wydajnościowym wynikającym np. z bardzo wysokiej aktywności jednego site w application pool. Application pool nie wystarcza jednak jeśli wysoka aktywność jest generowana przez część site znajdującą się w wybranym folderze lub katalogu wirtualnym. W takim przypadku można tworzyć osobne WebApplication dla wybranego katalogu, które można dalej przypisać do oddzielnego application pool.
Dodatkowo każda z WebApplication ma również swój oddzielny application domain, session state i application state. Z dużym prawdopodobieństwem, jeśli twój site ma hostować komponenty pochodzące od różnych dostawców, to również należałoby je definiować jako odrębne WebApplication, co pozwoli odseparować je od siebie i uniknąć potencjalnych konfliktów.
Oto polecenia pozwalające zarządzać obiektami application:
