Wąskie gardła popularnych CMS'ów PHP a hosting

[gravisrs]

Chciałbym poruszyć temat optymalizacji hostingu z perspektywy developera aplikacji internetowych. Drobnych szczegółów, które są coraz częściej zaniedbywane a mają ogromny wpływ na prędkość hostowanych aplikacji opartych o nowoczesne CMS na PHP'ie,

Rzecz pierwsza.

Otóż zauważyłem, że coraz częściej trafiam na hostingi, gdzie baza danych jest na bardzo "odległej" maszynie niż sam serwer http. Złożona witryna oparta na Drupalu, WordPressie czy Joomli generuje 100+ zapytań SQL'owych przy każdorazowym wyświetleniu strony, często bardzo prostych i w większości dobrze zoptymalizowanych po stronie kluczy na tabelach itp. Odległej mam tu na myśli opóźnienie na pojedynczym zapytaniu SQL od 1ms, dochodzących nawet do 10-20ms które pochodzi najczęściej z zastosowanej topologii sieci/VPS/Firewalli. Przy jednym zapytaniu SQL'owym nie ma to znaczenia, ale w skryptach, które blokują się na każdą z setek+ odpowiedzi z bazy - te opóźnienie wynikłe z trasowania rośnie do tysięcy milisekund. Jest to bardzo ważny aspekt optymalizacji hostingów na styku aplikacja <-> baza danych.

Rzecz druga.

Głęboka konfiguracja. Zdarzają się hostingi, które do każdych żądań HTTP dodają nagłówki X-Frame-Options: SAMEORIGIN - rozumiem kwestie bezpieczeństwa anty XSS/XSRF, ale chciałbym mieć możliwość ich wyłączenia. Wciąż w sieci są systemy np. rezerwacji hoteli osadzane w ramkach. Zdarzają się hostingi, gdzie próżno szukać podstawowych ustawień PHP jak limity zasobów/czasów wykonywań. Zdarzają się hostingi, gdzie wciąż nie są interpretowane .htacces.

Jeżeli planujecie (roz)budowę hostingu, pamiętajcie proszę o tych drobnych szczegółach, za które klienci używający popularnych CMS będą bardzo wdzięczni.

Edytowane 13 Września 2017 przez gravisrs

[bybunny]

Pewnych elementów nie można wyłączyć ponieważ mają za zadanie zabezpieczyć właśnie infrastrukturę serwerową. Co do .htacces to trochę jestem zaskoczony ponieważ to jest chyba standard by taka opcja była aktywna z możliwością ingerencji przez użytkownika. Napisałeś coś również o możliwości ustawień PHP a w tym limity zasobów/czasy wykonywania. Tego typu opcje posiadają usługi dedykowane lub własne środowiska deweloperskie. Nie oczekuj że ktoś da tobie dostęp do takich opcji w standardzie. Serwery nie są z gumy niestety.

[Mion]

49 minut temu, gravisrs napisał:

opartych o nowoczesne CMS na PHP'ie,

Nowoczesne CMS stosują cache, wiec nie wykonują za każdym requestem pełną pulę wywołań do bazy danych.

 

51 minut temu, gravisrs napisał:

ochodzących nawet do 10-20ms

Znajomy miał tak zrobione, że serwer dedykowany HTTP miał w OVH we Francji a bazę danych tez na dedykowanym w OVH ale w PL   

 

53 minuty temu, gravisrs napisał:

Zdarzają się hostingi, gdzie wciąż nie są interpretowane .htacces.

Nie rozumiem pojęcia "zdarzają się" ? Losowo je Wybierasz czy co, ze Ci się takie zdarzają ? 

 

56 minut temu, gravisrs napisał:

Jeżeli planujecie (roz)budowę hostingu, pamiętajcie proszę o tych drobnych szczegółach, za które klienci używający popularnych CMS będą bardzo wdzięczni.

Tylko czy z taką samą wdzięcznością będą chcieli płacić za luksusy ? Trochę "dziwny"  ten post 

 

 

[SomeGuy]

Według mnie jeśli klient posiada dedykowaną platformę (najczęściej sprzedażową) to powinien do tego poszukać też dedykowanej usługi, która to obsłuży. 

 

Dziwi mnie, że hosting współdzielony za 100/rok wybierają firmy, które prowadzą duże kobyły sklepowe albo poczta jest u nich "must-have", i "tracą miliony" gdy nagle usługa o gwarantowanym SLA na poziomie 99,7% nie działa, adres IP do wysyłki (współdzielony) wpada na czarną listę lub sklep wolno chodzi.

 

Teraz i tak jest coraz lepiej, mamy PHP7, opcache, cache na warstwie samego softu serwującego nawet static-html, dostępne tweaki max_memory_limit czy timeouty/exectimeoutlimit, a nawet dostęp do SSH na sharedzie.

 

Jeśli cokolwiek generuje 100+ zapytań do serwera SQL / per refresh strony  i jest ten potwór umieszczony na sharedzie, to należy go przenieść na usługę dedykowaną i zoptymalizować. 

To czy jest to jakiś skrypt opensourcowy używany przez miliony, do tego mnóstwo pluginów to wcale nie znaczy, że jest to soft porządny. Tym bardziej kiedy owe pluginy są wspierane głównie przez pojedynczych członków społeczności.

 

Nie twierdzę, że się nie da tego trzymać na współdzielonym, ale nie warto też skąpić na coś co jest narzędziem pracy. 

 

[szarik]

W chwili obecnej mamy usługi chmurowe, gdzie są markety z aplikacjami, w których jednym kliknięciem możesz taka zamówić wraz z usługą serwerową (domyślnie już skonfigurowaną z zainstalowanym oprogramowaniem np. system CMS)  ... zasoby wówczas możesz w locie całkiem duże przydzielać nawet nie martwiąc się o optymalizacje po stronie oprogramowania wybranego systemu zarządzania treścią...

 

PRZYKŁAD: https://www.oktawave.com/marketplace/Pages/Templates/TemplatesList.aspx?srtBy=0&srtDir=0&pgNr=1&ctg=1546&srTxt= 

 

 

...mamy też dedykowane usługi hostingowe pod konkretne rozwiązania, gdzie gwarantowane są odpowiednio duże zasoby z możliwością ich zwiększenia... 

 

PRZYKŁAD: Hosting Magneto w http://swits.pl/ 

 

...typowy hosting współdzielony musi mieć ograniczenia związane z zasobami z uwagi choćby na koszty...  tego się nie przeskoczy...

Edytowane 13 Września 2017 przez szarik

[Artur Pajkert Hekko.pl]

Przy okazji wydajności w aplikacjach warto też zwrócić uwagę na wersję PHP.

PHP 7.1 w Benchmarkach miażdży linię 5.x

Być może szukającym maksymalnej wydajności w ramach hostingu współdzielonego przyda się więcej informacji o wpływie wersji PHP na szybkość:

http://blog.hekko.pl/przyspieszyc-wczytywanie-strony/

 

Tylko tyle, że czasem spotka się plugin napisany tak, że zadziała tylko pod 5.x ale na to nie ma rady, czasem samodzielnie

można poprawić w kodzie źródło błędu.

[lokoz.com]

12 godzin temu, Mion napisał:

13 godzin temu, gravisrs napisał:

Jeżeli planujecie (roz)budowę hostingu, pamiętajcie proszę o tych drobnych szczegółach, za które klienci używający popularnych CMS będą bardzo wdzięczni.

Tylko czy z taką samą wdzięcznością będą chcieli płacić za luksusy ? Trochę "dziwny"  ten post 

 

Poprawne i szybkie działanie strony Klienta to nie jest luksus  To powinien być standard. Na moich serwerach bardzo dbam o to żeby IO wait prawie nie istniało, a średnie użycie CPU nie przekraczało 50% i wykres był płaski. Podobnie ma się kwestia serwerów MySQL, a ich "odległość" od serwera www nie przekracza u mnie 0,3ms. Gdy w DC, którego używam na chwilę musieli zmienić trasę i czasy skoczyły do 10ms wpłynęło to bardzo mocno na jakość działania stron.

 

Cały system działa tak jak jego najsłabszy element. Jeżeli masz dużą odległość pomiędzy serwerem www, a MySQL to nawet jak użyjesz do tego najmocniejszych serwerów na świecie to i tak nie będzie działało tak jak powinno. Tak samo gdy będziesz pozwalał na "zęby" w wykresach CPU i IO wait, które dodatkowo się na siebie nakładają. Oczywiście nie można zapomnieć o wycinaniu zbędnego ruchu robotów typu ataki XML-RPC, wp-login itp. itd.

 

Grafika przedstawia serwer, na którym jest kilka tysięcy domen, a ten jeden ząbek na górze(IO wait) to przyrostowy backup, który robi się w nocy.

[Artur Pajkert Hekko.pl]

Różnice między serwerem MySql lokalnie, a - co czasem może się zdarzać - nawet w innym DC, są duże. Czasami podobne operacje potrafią trwać 10x dłużej (sami mieliśmy taki przypadek developując jeden z naszych systemów, gdzie te same operacje wykonywalne na kliencie lokalnym były właśnie o tyle szybsze niż na zdalnym). W niektórych wypadkach, aby zminimalizować impakt na user experience, dobrze jest stosować kod asynchroniczny, ale to nie zawsze jest możliwe i trzeba mieć trochę większe pojęcie o programowaniu - może dla niektórych czytających ten wątek będzie to jakaś wskazówka, jeśli z jakiegoś powodu muszą męczyć się z "odległym" sql'em.