Mod_php vs cgi vs fastcgi - vagy - hogyan kell kiválasztani a hoster, afterware (bitrix, ios programozó)

Felhívom a figyelmet a php (vagy inkább a Bitrix esetében az előnyben részesített lehetőségre) vonatkozó kutatásaimra a különböző indítási módokban. A cél nem az volt, hogy számokat mutasson a lehetséges részvételről, vagyis hasonlítsa össze a különböző lehetőségeket, és más dolgokkal egyenlő legyen.

A GGI a legrégebbi módja a szkriptek (köztük a php) futtatásához. Ebben az esetben minden egyes találathoz a php-tolmács önálló alkalmazásként fut, és parancsfájlra kerül. A szkriptnek vissza kell adnia a fejléceket, majd az oldal html kódját. Ezt követően a tolmács megállítja munkáját.

Az Apache modul - ebben az esetben a php folyamatosan a webszerver memóriájában van, nem kell idő a tolmács indításához.

FastCGI - a CGI interfész kialakulása, ebben az esetben a php-t egy külön folyamat indítja el, de a szkript végrehajtása után nem áll le.

Tényleg olyan gyorsan, ez a FastCGI? Ellenőrizzük!

Az Apache 2.2 + MySQL 5 telepítve van egy gépen, valamint a Bitrix Business demó oldalán. A Bitrix komponens gyorsítótárának ki van kapcsolva, így a gyorsítótár véletlenszerű újbóli létrehozása nem befolyásolja az eredményeket.
Itt szándékosan nem a hardverre és a konfigurációra koncentrálok. Ismétlem, a feladat nem az abszolút értékek megszerzése, hanem a php különböző működési módjainak összehasonlítása.
Egy másik gép a helyi hálózaton szimulálja a terhelést a kiszolgálón. Ehhez használtam JMeter-et.
Java-ban van írva, és ez egy tisztességes terhelést eredményez. így a kísérlet tisztaságához "el kellett különíteni" a kiszolgálótól.

A tesztterv 6 oldalból állt, 2 párhuzamos kérés. Megpróbáltam kiválasztani a legdinamikusabban betöltött oldalakat, kényelemért adtam nekik feltételes neveket a tartalomhoz. Ne társítsa az oldalak visszaadási arányát ugyanazon modulokkal.
Csak dinamikus oldalkód lett statika nélkül letöltött, így a nginx nem használta (részletek a tanfolyamon).

Tehát minden készen van, elkezdjük tesztelni.

Tesztelés gyorsító nélkül php

CGI
Az összes oldal összesített eredményének következő grafikája:

Kék - átlagos visszahúzási idő minden találatban ms-ban
Lila - statisztikai átlag
Piros - eltérés az átlagtól
Zöld - a visszatérési oldalak sebessége

Ennek eredményeképpen átlagosan 5,5 másodperc van oldalanként, a visszacsatolási oldalak sebessége - 105 percenként.
Ne feledje, hogy itt az idő az oldalra az az idő, amelyre a felhasználó tényleg vár, és nem az összes párhuzamos kérés átlaga (a második esetben oldalanként 105/60 = 1,75 másodperc).

Az oldalakon külön a diagram (átlagos válaszidő):

Itt már az eredmény jobb - 122 oldal / perc. És ennek megfelelően a diagram:

Jó eredmény a hagyományos CGI-hez képest: 120 oldal / perc, valamivel lassabb a modulnál.
chart:

De hogyan változik meg a kép, ha a php gyorsító telepítve van?

A teszt eredmények az EAccelerator segítségével történtek

CGI - EA
Ismeretes, hogy a gyorsító nem működik CGI módban. minden folyamathoz hozzáférést kell biztosítania a megosztott memóriához. De a phpinfo-ban vannak olyan információk, amelyek az akkumulátort töltik be, és az érzés, hogy működik. Ellenőrizzük.

108 oldal percenként. Ez gyakorlatilag ugyanolyan eredmény, mint volt. chart:

309 oldal / perc, az átlagos válaszidő 1 másodperc. Azt mondanám, hogy ez már valami. Nos, az oldalakon:

294 oldal percenként, azaz. kb. 5% -kal lassabb a modulnál. De még mindig nem hasonlítható össze a hagyományos és kényelmes CGI móddal.

Átlagosan az oldalak is kissé elmaradnak a modul mögött.

Van más probléma?

A hosterek gyakran használják a CGI-t, mert ebben az esetben sokkal kényelmesebb a [read: cut] felhasználói erőforrásokat kezelni. És ennek eredményeként "érthetetlen hibákat" kapunk.

Még egy fontos pontot szeretnék megemlíteni: ma a php egy fájl CGI és FastCGI módokhoz, a phpinfo-ban:

Szerver API: CGI / FastCGI

Így gyengén lehetséges a felhasználói szinten, hogy megtudja, hogyan működik a php. Figyelembe véve a FastCGI létrehozására vonatkozó szigorú dokumentációt, nagyon jól lehet, hogy félrevezető lesz.

Következtetések vagy "Hogyan válasszunk ki egy lakót?"

Ha egyszerű felhasználó vagy, valószínűleg átkerült az egész technikai terhelésen, hogy azonnal megtalálja a választ a kérdésre.

• Válassza ki a CGI módot, ha webhelye elkötelezett a keleti filozófián, és a webhely látogatóinak oldalainak betöltése nem izgat.
• A FastCGI jó teljesítményt nyújt, de CGI módú problémákkal küzd, ezek állandó szerverhibák, "500".
• Más esetekben javaslom a php használatát Apache modulként. Különösen, ha ez egy dedikált szerver vagy VPS.
• Győződjön meg róla, hogy figyeljen a gyorsító php. Sajnos sok vendéglátó nem fordít figyelmet erre a kérdésre.
• És itt van még egy fontos pont: ne válassza a szomszéd házigazdáját a lépcsőházban, néha az alapszintű képtelenség a rendszer felállításához több problémát okoz, mint bármi más. Válassz szakembereket.
• Javasoljuk, hogy teszteljük a szkripttel a hosting hosszú távú vásárlása előtt. A szkriptet rendszeresen frissítjük az új problémák figyelembevételével.

Nézz magadra és vonj le következtetéseket. Sajnos a felhasználó csak akkor kezd megérteni a "helyes" tárhely fontosságát, ha problémákat szenvedett.