Wielu programistów nie przejmuje się utrzymaniem i hostingiem tworzonych przez siebie aplikacji PHP. Ich aplikacje sprawiają wrażenie jednorazowych, a przy tym bardzo często są mocno obciążane przez wielu użytkowników. Weźmy dla przykładu aplikację PHP z relacyjną bazą Oracle dla firmy marketingowej, która umożliwia zakup produktów i wymianę uzyskanych punktów na dodatki do gry online. Sprawdza się ona doskonale, do czasu gdy zacznie z niej korzystać kilka milionów użytkowników.

Teoretycznie, jeśli dysponujemy wystarczającą liczbą serwerów, nie powinno być problemów. Jednak kombinacja PHP z relacyjną bazą danych jest trudna do efektywnego skalowania, tak aby osiągnąć jednocześnie odpowiednią wydajność odczytu i zapisu danych.

Zobacz również:

• Cyfrowa transformacja z AI - co nowego na Google Cloud Next 24
• Nvidia odtworzyła całą planetę. Teraz wykorzysta jej cyfrowego bliźniaka do dokładnego prognozowania pogody
• Google ostrzega przed monopolem Microsoftu w chmurze

Jednym z możliwych rozwiązań w tej sytuacji jest zastosowanie hostingu w chmurze oraz baz NoSQL (Not only SQL). Infrastruktura cloud pozwala na elastyczne rezerwowanie zasobów i uruchamianie kolejnych serwerów, natomiast bazy NoSQL pozwalają bardziej efektywnie czerpać dane.

Typowo i niewydajnie

Zastanówmy się najpierw, zanim opiszemy zalety nowego podejścia, czemu typowe środowisko uruchomieniowe PHP jest nieoptymalne

Najpopularniejsza instalacja, w której pracuje PHP to webserwer Apache z modułem PHP w trybie prefork. Ten tryb oznacza, że serwer webowy uruchamia serię osobnych podprocesów, aby obsłużyć konkurencyjne żądania. Kiedy połączymy tę konkurencyjną specyfikę z tradycyjną bazą danych, jak np. MySQL, PostgreSQL czy Oracle, to rozwiązanie spowoduje rozłączne połączenia z bazą danych - ich łączenie (pooling) wymaga współdzielonego obszaru pamięci.

Z drugiej strony natywne wątki mają współdzielone obszary pamięci jako część procesu głównego. Podprocesy nie mają współdzielonego obszaru pamięci, chyba że używamy specyficznego obszaru systemu - pamięci współdzielonej. To rozwiązanie nie jest jednak tak szybkie jak przekazywanie pamięci przez referencje, poza tym Apache w trybie prefork nie pozwala na stosowanie współdzielonej pamięci w tym celu. Możliwe jest uruchomienie PHP w natywnych wątkach w trybie worker, ale ograniczeniem może być lista modułów dostępnych w tym trybie i to, czy są one "wątkowo bezpieczne".

Model konkurencyjny w PHP ma główny wpływ na pionową skalowalność, gdy korzystamy z tradycyjnych baz RDBMS. Podczas gdy jest możliwe otwarcie tysięcy niewspółdzielonych, jednoczesnych połączeń do MySQL czy Oracle, ma to negatywny wpływ na liczbę jednoczesnych żądań. Typowa aplikacja internetowa działa według następującej logiki:

żądanie - pobranie danych - wykonanie operacji - pobranie większej ilości danych - wykonanie dodatkowych operacji - zapisanie danych - wysłanie odpowiedzi

W tego rodzaju kodzie występują dość długie okresy, w których aplikacja nie wymienia danych z bazą danych i inne żądanie mogłoby "skorzystać" z tego samego połączenia z bazą danych. Oczywiście, gdyby możliwy był pooling połączeń. Ponieważ model procesów PHP to uniemożliwia, jesteśmy zmuszeni do podjęcia decyzji: albo utrzymać połączenie na czas cyklu żądania/odpowiedzi, albo tworzyć je za każdym razem.