Często spotykamy się z problemem, z którym najzwyczajniej trzeba się przespać. Właśnie na taki problem natrafiłem, gdy w moim małym projekcie PHP postanowiłem zrobić cache. Mój projekt to parsowanie zewnętrznych stron internetowych w poszukiwaniu konkretnych informacji i wyświetlanie ich w takiej formie, jakiej sobie użytkownik zażyczy. (Aha, link powyżej prowadzi do starej wersji, jak jest tam napisane, pracuję nad nową wersją — dostępna jest w SVN svn://tools.wikimedia.pl/holek/trunk)
Z jednej strony chciałem, aby system był dostosowany do potrzeb platformy, gdybym nagle musiał się przenieść gdzieś daleko poza aktualny Toolserver, z drugiej żeby był prosty w użyciu bez względu na to, jaką metodę cache'owania wykorzystam.
Natrafiłem tym samym na różne metody przechowywania pamięci podręcznej: memcached, APC czy nawet przechowywanie za pomocą sesji. Pamięć ma przechowywać informacje dostępne dla wszystkich. Nie było więc problemu z pierwszymi dwiema metodami.
Zabawa zaczęła się, gdy do przechowywania chciałem zaprząc mechanizm sesji. Tak, wiem, nie od tego tenże mechanizm jest. Jest on natomiast systemem, do którego skrypt ma się przełączać w niemożności wykorzystania dwóch poprzednich. Jego zadaniem jest odciążenie parserów w jak największym możliwym stopniu bez tworzenia stałej bazy u siebie. Natknąłem się na kilka problemów, niektóre natury technicznej, inne wynikające z samej funkcjonalności cache.
- Pierwsze primo: Jak spowodować, by cache oparty na sesjach był dostępny dla wszystkich? Przy każdym rozpoczęciu jest przecież nadawany losowy identyfikator sesji. O ile wiele osób korzysta ze zwykłego
session_start();, o tyle za pomocą session_id(); mogłem w stanie ustawić stałą nazwę dla sesji (citebook-generator-session-cache), tym samym udostępniając tę samą sesję wszystkim użytkownikom skryptu. Przeciwieństwo tego, co zazwyczaj chcemy osiągnąć za pomocą sesji.
- Drugie secundo:: Jak długo powinny być przechowywane dane? Ze statystyk, które robiłem dla siebie sprawdzając, czy opłaca mi się w ogóle myśleć o cache wyszło, że najczęściej ludzie zwykle naciskają kilka razy "Generuj" pod rząd z tymi samymi danymi wejściowymi. Żeby uniknąć niepotrzebnego wykorzystania zasobów postanowiłem pozostawić domyślne ustawienia, gdzie po 24 minutach sesja uznawana jest za śmieć. To oznacza, że po 24 od ostatniego użytkownika, który w tym czasie będzie miał dostęp do największej ilości skeszowanych informacji, cache się wyczyści. Wydaje mi się, że będzie to dobry kompromis pomiędzy ilością informacji a szybkością powrotu do stanu początkowego.
- Trzecie tetrio: Wydajność przy dużym ruchu. Zawsze zostanie możliwość wyrzucenia stałego przyznawania identyfikatora sesji i uruchomienie cache dla każdego z użytkowników. To jednak nie będzie problem, dopóki narzędzia nie zdobędą dużej popularności.
Najgorsze jest w tym wszystkim to, że testowane było to jedynie w warunkach "laboratoryjnych" i nie mam pojęcia, jak ten system będzie się zachowywać w rzeczywistości. Oczywiście jest to fallback, gdyby reszta systemów nie działała, więc nie przywiązywałem aż takiej wielkiej wagi do niego. Chciałbym się jednak Was zapytać, co myślicie o takim wykorzystaniu sesji? Mieliście może z czymś takim do czynienia i stuningowaliście taki system w jakiś ciekawy sposób?
EDIT: Po komentarzach i wyperswadowaniu pomysłu, zrezygnowałem z sesji i mam zamiar pozostać przy dostępnym APC.