Предлагам ти изследванията си върху PHP производителност (или по-скоро, предпочитан вариант специално за Bitrix) работи в различни режими. Целта беше да не се получи някакви фигури на възможно посещаемост, а именно за сравнение на различни версии на равни други условия.

GGI - най-старият начин да стартирате скрипта (включително PHP). В този случай, за всеки хит PHP интерпретатор работи като самостоятелно приложение и се предава на скрипт, за да се изпълнява. Сценарият трябва да се върне заглавията, а след това на HTML код на страницата. След това, на интерпретатора прекратява.

Apache модул - в този случай се намира в паметта на PHP уеб сървъра, не губи време за започване на преводача.

FastCGI - Evolution CGI интерфейс, в този случай PHP тичам в отделен процес, но след изпълнението на скрипта не спира нейната работа.

Той ли е толкова бързо, на FastCGI? Проверете!

На една машина инсталиран Apache 2.2 + MySQL 5, както и демонстрация на сайта "Bitrix бизнес". Bitrix кеширане забранено компоненти на случаен принцип възстановяването на кеш паметта не повлияе на резултатите.
Тук умишлено не се фокусира върху хардуер и конфигурация, тъй като Повтарям, проблемът не е да се получи на абсолютните стойности, а за сравнение на различни начини на PHP работа.
Друга машина в мрежата създава симулация на натоварването на сървъра. За това се използва JMeter.
Той е написан на Java, и той създава приличен товар. Ето защо, за чистотата на експеримента аз трябваше да "отделен" от сървъра.

план тест, състояща се от 6 страници, две паралелно заявка. Опитвам се да се избере най-динамично натоварени страници, за удобство на традиционните наименования, дадени от тях съдържание. не трябва да се свързва откат скорост на страници с едни и същи модули.
Зареждане само динамичен страници код без статиката, съответно Nginx не може да се използва (подробности в урок).

Така че, всичко е готово, се пристъпи към тестване.

Тестване без ускорител PHP

CGI
Резултатът е следният графиката на общите резултати на всички страници:

Blue - Средната продължителност на възвръщаемост на всяко посещение в мс
Purple - средната статистическа
Червен - отклонението от средната стойност
Green - скоростта на качване на страници

В резултат на това ние имаме средно време от 5,5 секунди на страница, скорост на качване на страници - 105 на минута.
Имайте предвид, тук времето на страницата - този път, който е наистина очаква потребителят, отколкото средната стойност на всички паралелни разследвания (във втория случай ние се 105/60 = 1,75 секунди на страница).

Отделно от това, страниците се обърнаха като диаграма (средно време за отговор):

Тук резултатът е по-добра от - 122 страници в минута. И съответно, на графиката:

Много добър резултат в сравнение с традиционния CGI: 120 страници в минута, малко по-бавно, отколкото на модула.
диаграма:

Но как да се промени картината, ако зададете на газта PHP?

Резултатите от теста с установена EAccelerator

CGI - EA
Известно е, че газта не работи както в режим на CGI тя се нуждае от достъп до общата памет на всички процеси. Phpinfo но има данни, че eaccelerator зареден и чувството, че тя работи. Нека да проверим.

108 страници в минута. Това е на практика един и същ резултат, който беше. диаграма:

309 страници в минута, средното време за изчакване 1 секунда отговор. Бих казал, че това е вече нещо. Е и, съответно, на страниците:

294 страници в минута, т.е. около 5% по-бавно от модула. Но все пак това не излиза да има сравнение с традиционното и спокойно режим CGI.

Като цяло, на страниците може да се види леко закъснение от модула.

Има ли някакви други проблеми?

Общежитие CGI често се използва като в този случай е много по-лесно да управлявате [да се чете: нарязани] потребителите на ресурси. И като резултат получаваме "необясними грешки".

Бих искал да спомена за още един важен момент: днес има един PHP файл за CGI и режим на FastCGI, phpinfo да видите:

API сървър: CGI / FastCGI

Така че малко изглежда възможно на ниво потребител, за да разбера как всъщност работи PHP. Като се има предвид оскъдна документация относно конфигурирането на FastCGI, че е много вероятно, че ще бъдат подведени.

Заключения или "Как се избират домакин?"

Ако сте обикновен потребител вероятно превърта цялата техническа натоварване веднага да намерите отговор на този въпрос.

• Изберете режим на CGI, ако вашият сайт е посветен на източната философия и времето за зареждане на посетителите на сайта не ме интересува.
• FastCGI дава добри резултати при изпълнението, но тя има свои собствени проблеми режим CGI, и това постоянно "500" грешки в сървъра.
• В други случаи, аз препоръчвам използването на PHP като Apache модул. Особено, когато става дума за специален сървър или VPS.
• Не забравяйте да се обърне внимание на PHP на газта. За съжаление, много хостинг компании не плащат достатъчно внимание на този проблем.
• И още един важен момент: не вземете носи повече проблеми, отколкото нещо друго, като един съсед домакин на стълбището, понякога елементарни неспособност да създаде системата. Изберете професионалисти.
• Препоръчваме Ви да закупите дългосрочна хостинг тест то в нашия скрипт. Периодично актуализиране на сценария, като се вземат предвид новите предизвикателства.

Вижте сами и да си направите изводи. За съжаление, потребителят започва да разбира значението на "правото" да бъде домакин само след изправени пред редица проблеми.