Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów Opcje

[hawk]

Problem stary jak świat: system wymaga włączenia sporej liczby plików i zarządzanie tym jest upierdliwe. Do tego nie należy włączać więcej kodu niż potrzeba, a najlepiej zrobić jakieś lazy load.

Oczywiście, technik jest wiele:

1) require_once rozsiane po plikach, najlepiej poprzedzone jakąś stałą, np. require_once ROOT_DIR . '/foo/Foo.class.php';

2) Prado: deklarujemy namespacy - np. za pomocą funkcji using(), co dodaje nam ścieżki do include_path, a potem niech php znajdzie klasę.

3) Autoloader + mapa (nazwa klasy => ścieżka do pliku); autoloader wczytuje mapę i na jej podstawie jest w stanie znaleźć każdą klasę

Są jeszcze jakieś inteligentne sposoby? Dobry mechanizm powinien być odporny na "przemeblowanie" struktury plików (np. chcemy połączyć kilka klas w jeden plik).

BTW, włączanie plików bez klas (tylko funkcje i kod) jest gorsze, bo nie ma tego czegoś, czego można szukać po plikach... kolejna zaleta OOP?

[Zyx]

Wykorzystanie gniazd uniksowych niewiele Ci da. Tracisz wtedy główną zaletę Memcached, a zyskujesz? W zasadzie nic, ponieważ zapytanie i odpowiedź wciąż musi przejść przez jądro systemu operacyjnego, gdzie są kilka razy kopiowane z jednego bufora do drugiego. Samo przełączanie się w tryb jądra również jest kosztowne. Żadne gniazda, żadne inne mechanizmy komunikacji międzyprocesowej nie są w stanie dorównać pamięci dzielonej.

Domyślnie w PHP każde żądanie traktowane jest jako zupełnie niezależny byt. Pojedynczy proces FastCGI lub moduł Apache'a może jednak przetwarzać wiele żądań jako osobne wątki. APC zezwala jedynie na wymianę informacji między tymi wątkami (kod bajtowy + dane), nie przekracza natomiast granicy procesu. Z tego powodu:
* W trybie modułu Apache'a dane są współdzielone jedynie między wątkami tego samego procesu Apache'a,
* W trybie FastCGI dane są współdzielone między wątkami tego samego procesu FastCGI.

Przy czym w FastCGI najczęściej uruchomionych jest równolegle kilka/kilkanaście procesów, które na dodatek mogą być co X żądań restartowane w celu eliminacji potencjalnych wycieków pamięci. APC nie pozwala ani na współdzielenie danych między tymi procesami (każdy proces jest odizolowany od drugiego), ani na manipulację nimi np. z poziomu skryptu konsolowego, ponieważ to jest jeszcze jeden proces. Podobnie, z tego co wiem, działa XCache. Z tego powodu jedynym 100%-pewnym sposobem wyczyszczenia cache jest tutaj restart Apache'a lub wszystkich procesów FastCGI.

Pamięć współdzielona to mechanizm pozwalający na zmapowanie pewnego fragmentu pamięci na przestrzeń adresową więcej niż jednego procesu. Oba te procesy widzą ten fragment jako "swój" i mają do niego pełne prawa odczytu oraz zapisu. Najczęściej współdzielony fragment reprezentuje się jako plik na dysku, który działa trochę jak pamięć wymiany - w momencie pierwszego użycia poszczególne jego bloki są importowane do pamięci i odpowiednio oznaczane. Gdy blok znajdzie się w pamięci, zasadniczo nie ma różnic wydajnościowych między dostępem do prywatnej pamięci procesu, a pamięcią współdzieloną. Wszystko wygląda fajnie, ale jest tutaj jeden problem, który tłumaczy dlaczego typowe akceleratory go nie wykorzystują: programista musi samodzielnie zaimplementować całe i w dodatku współbieżne zarządzanie takim obszarem pamięci, co nie jest zadaniem trywialnym. Jedynym znanym mi rozszerzeniem PHP, które wykorzystuje systemowy mechanizm pamięci dzielonej, jest wspomniany już chdb, który radzi sobie z powyższym problemem bardzo prosto: pamięć jest tylko do odczytu -> nie potrzeba żadnej synchronizacji -> nie trzeba implementować zarządzania taką pamięcią. Zawartość takiego cache można przebudować jedynie hurtem.

OK, ale chyba tyle na temat mechanizmów cache, ponieważ trochę zboczyliśmy z tematu. Mam nadzieję jednak, że rozwiałem tym wpisem wszelkie wątpliwości, dlaczego:
* nie powinno się stosować Memcached do obsługi map klas,
* dlaczego APC działa tak, jak działa.

Ten post edytował Zyx 16.07.2011, 12:21:44