Zmienne statyczne, czyli dlaczego nie lubię PHP

Rzeczą naturalną dla każdego uczącego się programisty C++ jest design pattern zwany singletonem. Właściwie każdy ma do czynienia z tego typu wzorcem projektowym w trakcie pisania nieco bardziej skomplikowanych aplikacji C++/C#. Przykładowymi singletonami w C# (bardzo często używanymi) są różne instancje klasy System.Text.Encoding, będące predefiniowanymi sposobami kodowania w różnych popularnych (wszelkie odmiany WTFUTF) wersjach. Pisząc w ASP.NET również można użyć singletonów - to, moim zdaniem, największa przewaga ASP.NET nad PHP w dowolnej jego odmianie.

PHP, zgodnie z założeniami, wykonywany jest w całości za każdym razem, gdy uruchomiony jest skrypt strony (pomijam różne dziwne sztuczki czynione z serwerem). Czyli (w wielkim skrócie): skrypt jest ładowany, skrypt jest wykonywany, wynik jest wypluwany przez serwer HTTP prosto do łączącego się klienta. I tak za każdym razem. W efekcie - każdorazowo takie operacje, jak połączenie z bazą danych, wczytywanie danych itp. muszą być wykonywane dla każdego (z grubsza) odwołania do skryptu. Jest to elastyczne i niezawodne - fakt; jednak wydajność aplikacji webowej znacznie na tym cierpi.

ASP.NET nie jest zbiorem skryptów, a aplikacją-pluginem serwera HTTP. Jak każda aplikacja - jest wczytywana, uruchamiana, działa, jest zamykana. Podstawowa różnica między PHP i ASP.NET jest jednak taka, że uruchomienie następuje raz, a następnie aplikacja po prostu działa, zwracając coraz to kolejne strony. Dzięki temu zabiegowi programista, tworząc statyczne pole klasy, może zainicjalizować je raz - przy uruchamianiu aplikacji; następnie korzysta z jednej i tej samej instancji, dopóki proces strony z jakiegoś powodu nie zostanie zatrzymany.

Mało tego - jeśli aplikacja posiada zdefiniowany plik Global.asax (rozszerzenie klasy aplikacji ASP.NET), może napisać własne funkcje wykonywane przy uruchamianiu i zatrzymywaniu aplikacji serwerowej. Pozwala to na sporą ilość sztuczek optymalizacyjnych - zaczynając od wczytania z dysku najczęściej używanych danych, aby udostępniać je poszczególnym modułom z pamięci RAM, z pominięciem np. parsowania XML. Dodatkowo, to samo rozszerzenie może (a nawet powinno) obsługiwać kod odpowiedzialny za rozpoczęcie i zakończenie sesji użytkownika, pozwalając również zapisać je w statycznym/globalnym kontenerze serwerowym.

Osoby, które piszą w PHP raczej nie polubią tego rozwiązania - uzależnia w pewien sposób wykonanie skryptu od tego, czy i jak dawno aplikacja webowa została uruchomiona (a uwierzcie, IIS7 czyni cuda z uruchamianiem/zatrzymywaniem obecnych tam aplikacji). Jednak dla kogoś, kto przechodzi do tworzenia stron z aplikacji mobilnych/desktopowych, takie rozwiązanie jest zdecydowanie wygodniejsze, bardziej intuicyjne i prostsze. W końcu czym innym jest HTTP Request, jak nie wywołaniem funkcji przetwarzającej zapytanie na odpowiedź? W tym wypadku - funkcji korzystającej z wczytanych już danych.

Jak wykorzystuję zmienne statyczne u siebie? Znalazłem przynajmniej kilka zastosowań, które powinny znacznie ułatwić i przyspieszyć działanie mojego bloga - przede wszystkim kosztem pamięci. Dodatkowo, aby przy rezygnacji z bazy danych na rzecz "wolnych XMLi" wydajność była niezerowa, buforowanie danych dyskowych w RAMie jest niezbędne. Oto zastosowania:

• przechowywanie konfiguracji bloga, włącznie z często używanymi, redefiniowalnymi stringami
• przechowywanie ostatnich postów w formie podstawowej i przetworzonej do wyświetlania z użyciem aktywnego szablonu
• przechowywanie danych zalogowanych użytkowników, aktywnych sesji
• indeks tagów i słów kluczowych
• obsługa HTTP Push

Oczywiście ilość możliwych zastosowań jest znacznie większa, prawdopodobnie te kilka obiektów statycznych, które wykorzystuję, ulegnie rozbudowie i rozwinięciu. Na chwilę obecną aplikacja po starcie zużywa 17.1MB pamięci operacyjnej (nie licząc .NET Framework 4), osiągając maksimum na poziomie 51MB. Dla typowego serwera - wyjątkowo mało.