Problem z każdorazowym uruchamianiem połączenia polega na tym, że zależy od charakterystyki wydajności otwierania połączeń socket. Stos TCP jest skonfigurowany do ochrony przed "osieroconymi" pakietami z poprzedniego połączenia, przerywającymi nowe połączenie. To część zabezpieczeń spójności, które TCP dodaje do IP. TCP/IP zapewnia tę funkcjonalność poprzez wprowadzanie opóźnienia, w celu ponownego użycia tego samego połączenia socket. Dlatego liczba połączeń TCP socket możliwych do otwarcia w ciągu sekundy jest limitowana. Jednym ze sposobów na ominięcie tego ograniczenia jest ponowne wykorzystanie połączeń między wieloma cyklami żądań. Niestety, ze względu na wspomniany model konkurencyjny PHP nie jest łatwo skorzystać z tego.

Jeśli wyświetlimy listę aktywnych połączeń w serwerze webowym albo bazodanowym podczas działania aplikacji PHP (wykonując polecenie netstat -na), zobaczymy dużą liczbę połączeń do lub z bazy danych w stanach TIME_WAIT albo CLOSE_WAIT. Gdybyśmy uruchomili tę aplikację w środowisku, które pozwala na "pulowanie" połączeń, zobaczylibyśmy stałą liczbę (równą skonfigurowanemu rozmiarowi puli) w stanie ESTABLISHED.

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

Dlaczego PHP pracuje w ten sposób? Początkowo Linux nie obsługiwał wątków a tylko podprocesy. Systemy wywodzące się z Windows NT od zawsze wspierały wątki (chociaż "cięższe" od tych z nowszych wersji Linuksa) i mogło to stanowić ich dużą przewagę. Microsoft nie potrafił jednak tego przekonująco dowieść.

Aby skalować aplikację PHP opartą na relacyjnej bazie danych, warto podzielić na kawałki dane. Oczywiście, należy zrobić to w sposób racjonalny - dla przykładu można podzielić klientów aplikacji na regiony (np. województwa).

Chmura i NoSQL wchodzą do gry

W chmurze nie ma obaw o wydajność konwencjonalnej aplikacji opartej nawet na bazie relacyjnej, kiedy zapewnione jest odpowiednie balansowanie obciążenia. Zamiast serii niepulowanych połączeń do jednej lub 2 maszyn, można rozkładać obciążenie na dużo więcej serwerów bazodanowych.

Większa liczba serwerów webowych ogranicza wpływ braku mechanizmu pulowania połączeń dla klientów bazy danych. Większa liczba baz danych i ich dzielenie na kawałki ograniczają wpływ tego problemu na serwery. Przejście na NoSQL i chmurę może znacznie podnieść skalowalność nawet w obecnych środowiskach uruchomieniowych. Czynniki ekonomiczne, które spowodowały tak dużą popularność PHP, dzięki takiemu podejściu nie tracą na swojej sile.

Jednoczesna migracja do chmury i do przechowywania danych w bazach NoSQL eliminują wspomniane problemy ze skalowalnością. Rozwiązań i produktów pozwalających na uruchomienie aplikacji PHP w środowisku cloud jest dostępnych już wiele. W przypadku baz NoSQL oferowanych jest już kilka projektów, ale trzeba będzie trochę poczekać na "zaprzyjaźnienie" się z nimi większego grona specjalistów i analityków, którzy do tej pory wybierali sprawdzone przez lata tradycyjne silniki relacyjnych baz danych (jednym z przykładów baz danych NoSQL o otwartym kodzie jest Mongo).

(oprac. psz)