[spoiler]
Небольшая вводная
GGI - самый старый способ запуска скриптов (в том числе и php). В этом случае на каждый хит запускается интерпретатор php как самостоятельное приложение и ему отдаётся скрипт для запуска. Скрипт должен вернуть заголовки, затем код html страницы. После этого интерпретатор прекращает свою работу.
Модуль Apache - в этом случае php постоянно находится в памяти веб сервера, не тратится время на запуск интерпретатора.
FastCGI - эволюция CGI интерфейса, в этом случае php запускается отдельным процессом, но после выполнения скрипта не прекращает свою работу.
Действительно ли он такой быстрый, этот FastCGI? Проверим!
Инструменты
На одной машине установлен Apache 2.2 + MySQL 5, а также демонстрационный сайт "Битрикс Бизнес". Кеширование компонентов битрикс отключил чтобы случайное пересоздание кеша не повлияло на результаты.
Здесь я умышленно не акцентирую внимание на аппаратной части и конфигурации т.к. повторюсь, задача не получить абсолютные величины, а сравнить разные режимы работы php.
Другая машина по локальной сети создаёт имитацию нагрузки на сервер. Для этого я использовал .
Он написан на Java и сам создаёт приличную нагрузку
, поэтому для чистоты эксперимента мне пришлось его "отделить" от сервера.
План тестирования состоял из 6 страниц, по 2 параллельных запроса. Постарался выбрать наиболее динамически загруженные страницы, для удобства дал им условные названия по контенту. Не следует ассоциировать скорость отдачи страниц с одноимёнными модулями.
Загружался только динамический код страниц без статики, соответственно nginx не использовал (подробности в ).
Итак, всё готово, приступаем к тестированию.
Тестирование без акселератора php
CGI
Получился следующий график суммарных результатов по всем страницам:
Синий - среднее время отдачи на каждом хите в мс
Пурпурный - статистическое среднее
Красный - отклонение от среднего
Зелёный - скорость отдачи страниц
В итоге имеем среднее время 5,5 секунды на страницу, скорость отдачи страниц - 105 в минуту.
Обратите внимание, здесь время на страницу - это время, которое реально ждёт пользователь, а не среднее по всем параллельным запросам (во втором случае мы получим 105/60 = 1,75 сек на страницу).
Отдельно по страницам получилась такая диаграмма (среднее время ответа):
Модуль Apache
Здесь уже результат получше - 122 страницы в минуту. И соответственно, диаграмма:
FastCGI
Совсем неплохой результат по сравнению с традиционным CGI: 120 страниц в минуту, чуть медленнее, чем модуль.
Диаграмма:
Но как изменится картина если установить акселератор php?
Результаты тестирования с установленным EAccelerator
CGI - EA
Известно, что акселератор не работает в CGI режиме т.к. ему нужен доступ к общей памяти из всех процессов. Но в phpinfo есть информация о том, что eaccelerator загружен и создаётся ощущение, что он работает. Давайте проверим.
108 страниц в минуту. Это практически тот же результат что и был. Диаграмма:
Модуль Apache
309 страниц в минуту, среднее время ожидания ответа 1 секунда. Я бы сказал, это уже что-то. Ну и соответственно по страницам:
FastCGI
294 страницы в минуту, т.е. примерно на 5% медленнее, чем модуль. Но всё равно не идёт ни в какое сравнение с традиционным и неторопливым CGI режимом.
В среднем по страницам также прослеживается небольшое отставание от модуля.
А есть ли другие проблемы?
- Как CGI, так и FastCGI работают независимо от веб сервера. А это значит что если происходит какая-то ошибка, веб сервер не получает заголовки от скрипта и возвращает нам в ответ " на стороне сервера". Чтобы узнать какая произошла ошибка, надо смотреть логи сервера, к которым далеко не всегда есть прямой доступ у пользователя. В случае модуля Apache ошибка может сразу отобразиться на экране (если включен вывод ошибок) и отладка скриптов осуществляется гораздо проще и быстрее.
- В CGI/FastCGI режимах есть проблема с авторизацией HTTP, как следствие - проблема с интеграцией с 1С, есть и другие специфические проблемы.
- При загрузке в Apache модуля php мы получаем замечательную возможность менять на лету некоторые настройки php через .htaccess, в CGI/FastCGI опять же получим ошибку 500.
- Основной довод сторонников CGI/FastCGI - это безопасность. Т.к. php работает как отдельное приложение - пользователи хостинга на системном уровне отделены друг от друга, а в режиме модуля существует гипотетическая возможность ломать соседние сайты на хостинге. Отчасти это так, но на сегодняшний день существуют определённые механизмы защиты и по опыту техподдержки могу сказать, что основную проблему безопасности пользователей представляют трояны, которые воруют пароли ftp и вживляют паразитный код на сайты.
Хостеры часто используют CGI т.к. в этом случае гораздо удобнее управлять [читать: резать] ресурсами пользователей. И в итоге получаем "непонятные ошибки".
Хочу упомянуть ещё об одном важном моменте: сегодня php идёт одним файлом для CGI и FastCGI режимов, в phpinfo видим:
| Server API: CGI/FastCGI |
Выводы или "Как же выбрать хостера?"
Если вы простой пользователь, вероятно, прокрутили весь технический груз чтобы сразу найти ответ на вопрос.
Пишу результаты.
- Выбирайте CGI режим если ваш сайт посвящён восточной философии и время загрузки страниц посетителей сайта не волнует.
- FastCGI даёт хорошие результаты по производительности, но ему присущи проблемы CGI режима, а это постоянные ошибки сервера "500".
- В остальных случаях рекомендую использовать php как модуль Apache. Особенно если речь идёт о выделенном сервере или VPS.
- Обязательно обращайте внимание на акселератор php. К сожалению, многие хостеры не уделяют этому вопросу должного внимания.
- И вот ещё важный момент: не выбирайте в качестве хостера соседа по лестничной клетке, порой элементарное неумение настроить систему приносит больше проблем, чем всё остальное. Выбирайте профессионалов.
- Рекомендуем перед долговременной покупкой хостинга тестировать его . Мы периодически обновляем скрипт с учётом новых проблем.
Смотрите сами и делайте выводы. К сожалению, пользователь начинает понимать важность "правильного" хостинга только после того как столкнулся с чередой проблем.
А позвольте полюбопытствовать, во время собственного поиска решения пересеклись ли как-то выводы с моими? Как Вы запускаете php? Используете ли акселератор? Стоит ли nginx?
У нас вот как раз другой случай. Я именно и хотел отметить, что мы "не имели возможность" (сейчас конечно имеем), а "были вынуждены" самим заморачиваться. И это был хоть и проблемный, но полезный опыт.
А началось все с того, что один из проектов, которым я занимаюсь, переехал на выделенный сервер, арендованный у одного хостера. (я позже скажу кто это) Сервер взяли с администрированием, т.е. они должны были все поддерживать и следить за сервером. После некоторых переговоров с ТП хостера, и ихних заверений, что сделаем все как надо (я им скидывал ваши рекомендации), мы оплатили и перенесли сайт. И начались проблемы!!! Сайт лежал по два часа в день. Перечислять что и как все решалось, сколько времени я убил на разговоры почти со всеми из их ТП и т.д. - мне пол дня понадобится.
Я, тем временем болея за проект, сам вникал во всю вашу документацию по настройке (я то как раз мат. часть хорошо знаю - т.е. теорию и все технологии... и мне все понятно, но вот где ручками что сделать надо, увы - нет практики) и вместе с ТП хостера пытался выяснить в чем проблема.
В итоге они нас "развели" на гиг памяти, хотя надо признаться он реально был нужен. После этого вроде стало все стабильно работать, но прошла неделя стабильной работы и опять начались проблемы такие же. Хотя посещаемость не выросла, нагрузка тоже. Начались опять дебаты, в процессе которых они начали опять говорить про еще два гига памяти. Причем аренда гига памяти у них стоит 350 рублей в месяц, при стоимости самого гига в 800 р
Естественно они это перенести не смогли и даже пообещали в одностороннем порядке расторгнуть договор (чего они не сделали, конечно,ибо были бы юридически не правы).
После такого поворота событий я был вынужден искать помощи, кстати в первую очередь обратился здесь на форуме. Откликнулся Евгений Педан, за что ему отдельное спасибо. Он нам там "подкрутил некоторые гайки", и кстати он и обнаружил, что там даже не стояло (!!!) php-акселератора. Вообщем хостер реально плевать хотел на те ваши рекомендации, которые я им скидывал, кстати, они потом прокомментировали это так: битрикс кто? пишет цмс? ну вот и пусть пишет - они нам не показатель, а мы хостинг компания - нам лучше знать.
Нафига нам было обещать тогда рекомендации выполнить до заключения договора!?!? Непонятно..
Евгений нам помог, но решить полностью проблему не смог, т.к. сервер на FreeBSD, а Евгений опытен в Linux. Вообще пришлось открывать свою записную книжку старую, и искать контакты бывших однокашников и прочих, кто мне мог помочь. После чего, вышел на очень профессиональных людей, один из которых за два дня привел все в порядок. Сервер стал работать стабильно.
На момент проблем нагрузка была около 7000. Сейчас бывает и по 20000. И сервер справляется без проблем. Но мы уже глядя в будущее собрали свой сервер более мощный. За весь период общения с профессионалами, я многое узнал. С теми с кем я общаюсь, работают в серьезных организациях, например в РЖД, где обеспечивают работу систем безопасности - серьезные ребята вообщем (многие бородатые
Так вот они поведали, что режим mod_php при грамотной сборке должен быть производительней в среднем на 20% чем FastCGI. Причем если нужно отделить пользователей, то даже использование виртуальных ОС, на каждую из которых естественно тратятся ресурсы, дает фору режиму FastCGI. Но использование виртулов требует больше памяти.
Надо отметить у Вас даже получились неплохие результаты в пользу FastCGI.
Можно сказать, что моё исследование - это лабораторная работа, т.к. проводилось на небольшом отрезке времени, результаты приближённые чтобы показать общую картину.
Но вот уже есть дополнение: решил понаблюдать, как будет дальше работать FastCGI и сегодня упал EAccelerator, с модулем такого не было. Понятно, что это, возможно, специфический вопрос EAccelerator'а, но могу с уверенностью сказать, что в режиме модуля он работает стабильнее.
Дмитрий, хочется верить, что ваш опыт, изложенный здесь, поможет другим не наступить на те же грабли.
ссылка на непонятный архив в котором непонятно что ?
Маркетинговое название статьи.
У нас блин везде этот маркетниг, другим словом, все нужно называть своими словами.
Наверно нужно назвать "Советую сисадминам" и то для тех у кого свои серваки.
Хотя наверно они лучше вас знают что установить, так чтобы еще можно было несколько левых сайтов впихнуть без особой потери производительности
Если советуете разработчикам, то нам как-то фиолетово будут ли ошибки выдваться пхп не будут ли выдаваться. Мы найдем способ отладить.
В общем статья не очем. Точнее говоря хорошая статья о том как пользоваться JMeter.
Очень странный вывод! Как говорится смотрю в книгу вижу ....
А не в том что у них на каком-то сервере стоит модуль или цги.
Поверьте мне по крайней мере с полтора десятками хостеров я работал и с поддержкой.
И с выделенными серверами и виртуальными выделенными серверами.
И просто с площадками на которых свою железку можно поставить.
И я вас уверяю, что то что вы описали это вообще не повод выбирать хостера.
Т.е. как бы в тему вы не раскрыли, но упорно хотите показать, что именно то что нужно для пользователя при выборе хостинга.
Вы сами то понимаете что у хостера с десяток серверов, а то и больше. И просто одним звонок в техподдержку может перекинуть ваш сайт на сервер этого же хостера за океаном.
Вы описали, что-то по типу - как выбирать магазин автозапчастей в зависимости от того как открываются двери, автоматически или нет. Да удобнее тот магазин, где двери открываются автоматически, т.к. если вы купите большую деталь, то у вас не будет свободных рук чтобы открыть дверь в магазине и выйти.
А вот статья с картинками о том как пользоваться скриптом на который вы дали ссылку была бы полезна, т.к. мне допустим было интересно посмотреть возможности скрипта, без скачивания и уж точно без пользования. И я бы мог понять стоит мне скачивать этот архив или же пользоваться своими знаниями хостеров и/или обычным импирическим способом устанавливая дистрибутив битрикс.
В целом статья полезная и освещает ряд настроек\возможных проблем с хостером, что несомненно поможет как начинающим так и специалистам.
Закрываем сайт. Всех пользователем даем отлуп на время отладки.
И шаг за шагом, функция за функцией вставляем.
die("I hate a bo-boom!!!");
Таким образом, находим больное место, выясняем кто виноват и что делать.
Собственно все.
Если валится сервер во время больших нагрзок и причины непонятны и хостер не может объяснить в чем дело. То не скупимся на сервачок. И устанавливаем на площадке, где все доступно и никакие бубумы в логи вам валится не будут. А будет то что вы сами себе пожелаете и настроили.
Григорий, пожалуйста, не обижайтесь, мне видится такая картина: сидят тут дети в песочнице, строят замки из песка, и тут приходите вы - этакий инженер-строитель, и смотрите прямо таки сверху и, сдержанно улыбаясь, рассказываете законы Ньютона...
Но поймите, пожалуйста, такую вещь: в техподдержке сегодня работает 7 человек, мы каждый день решаем более 100 обращений и, по меньшей мере, половина из них связана с работой хостинга. И мне бы очень хотелось изменить эту статистику.
По вашему - это маркетинг, дело ваше, но блог читают другие клиенты и мне бы не хотелось, чтобы у них сложилось неправильное мнение о проблеме.
Для его кэша выделяется общая память, этот кэш должен использоваться всеми процессами или он выделяется для каждого процесса ?
Для Apache собранном в prefork
Кэш акселератора добавляется к каждому процессу
например:
при eaccelerator.shm_size = 32
39175 www 1 20 0 53256K 27648K lockf 2 0:02 6.63% httpd
39184 www 1 20 0 53224K 27688K lockf 1 0:01 5.13% httpd
39179 www 1 20 0 53944K 28344K lockf 5 0:01 5.06% httpd
39180 www 1 20 0 52048K 17732K lockf 1 0:01 4.72% httpd
39193 www 1 20 0 52904K 24316K lockf 1 0:01 4.65% httpd
при eaccelerator.shm_size = 96
83004 www 1 20 0 116M 94044K lockf 5 0:46 1.56% httpd
83227 www 1 20 0 116M 87856K lockf 4 1:01 1.51% httpd
83167 www 1 20 0 115M 93276K lockf 4 0:51 1.46% httpd
83202 www 1 20 0 116M 95788K lockf 2 0:50 0.68% httpd
83080 www 1 20 0 117M 93812K lockf 7 0:52 0.63% httpd
83093 www 1 20 0 115M 92376K lockf 2 0:42 0.59% httpd
83047 www 1 20 0 116M 90884K lockf 7 0:49 0.49% httpd
83068 www 1 20 0 115M 94220K lockf 1 0:46 0.15% httpd
83196 www 1 20 0 116M 88276K lockf 6 0:49 0.10% httpd
получается что для prefork очень важен параметр MaxRequestsPerChild
Есть данные, по тому как работает акселератор собранный в worker или event ?
Если обратиться к man, выясним, что VIRT - это суммарная память вместе с разделяемой, а RES - физически используемая память процессом.
Отсюда вывод: eaccelerator.shm_size - общая память для всех процессов Apache
Сейчас скриншот с названиями столбцов
при eaccelerator.shm_size = 64
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
73115 www 1 20 0 86420K 71188K lockf 4 0:25 5.96% httpd
72188 www 1 20 0 87056K 72136K lockf 0 0:29 4.64% httpd
при eaccelerator.shm_size = 32
PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
99467 www 1 20 0 51764K 21768K lockf 4 0:01 14.49% httpd
99470 www 1 20 0 52280K 26384K lockf 4 0:01 13.74% httpd
99468 www 1 20 0 51864K 19076K lockf 6 0:00 6.40% httpd
SIZE is the total size of the
process (text, data, and stack), RES is the current amount of resident
memory
Как видно увеличивается SIZE (процесс + данные + стек) и так же увеличился захват памяти для самого процесса - RES.
Значит - этот кэш для каждого процесса, и использоваться он будет пока процесс не отработает заданное количество используемых запросов (MaxRequestsPerChild).
Поэтому я написал, что важен параметр MaxRequestsPerChild
Отставание fcgi тут логично так как вы запускаете его через апач, как я понимаю? Тут вполне логично, что встроенный в апач модуль будет быстрее, чем внешний, с которым еще по tcp/ip пообщаться нужно. Ну и опять же, ньюансы запуска/настройки могут влиять.
Определенные механизмы защиты - это safe mode, от которого всех тошнит
Спасибо за материал. После изучения вашего сообщения попросили своего хостера добавить eAccelerator.
Подскажите, какие лимиты памяти памяти стоит установить ему? У нас VPS, гарантированный объём памяти - 256MB, рабочий - 768.
Memory Allocated 25,576,884 Bytes
С целью экономичного расхода памяти мы рекомендуем ставить фильтр:
Потому что ранее вы запрашивали следующее изменение конфигурации eAccelerator:
eaccelerator.filter="!*/help/* !*/admin/* !*/bitrix/cache/* */bitrix/* */.*.php"
Я это отключил, теперь закэшированные скрипты показываются в eAccelerator control panel.
Ведь должно быть достаточно просто в фильтре прописать
!*/help/* !*/admin/* !*/bitrix/cache/*
и всё остальное будет по умолчанию кешироваться.
Сейчас у нас eAccelerator успешно наконец-то запущен и работает.
В его контрольной панели видно, что в том числе кэшируются скрипты вида:
/bitrix/managed_cache/MYSQL/b_vote_channel/ea/ea24be25ea00a98a16784536b16e5576.php
Хотел уточнить, не следует ли отключить и этот путь через !*/bitrix/managed_cache/*
managed_cache при этом не кешируется.
Судя по ответу Сергея, если позволяет место, из фильтра нужно убрать
!*/bitrix/*cache/*
а оставить только:
!*/bitrix/managed_cache/*
У Вас PHP работает через CGI/FastCGI.
Запуск PHP как модуля Apache на VPS'е с администрированием невозможен, т.к. это гораздо менее
безопасно.
Сейчас стоит mod_suphp и для текущей нагрузки его более чем достаточно.
FastCGI имеет смысл ставить на высоконагруженных системах. В вашем
случае это не даст никакого эффекта.
По-умолчанию мы всегда используем suphp (т.е. cgi-интерфейс).
Следует ли из этого, что у нас php запущен в варианте обычного cgi?
Сравните графики времени открытия страниц с акселератором и без него.
В данной ситуации хостер идёт по пути наименьшего сопротивления и, мягко говоря, несколько лукавит в отношении того, что переход с CGI не оправдан.
Особенно интересен пункт "Время на создание 1000 файлов (сек):". Когда это время около 3с, редактирование страниц идет нормально, а когда это время повышается до 10с и более, то сайт при редактировании тормозит.
Нет ли программы, чтобы посмотреть этот параметр в динамике. Например, раз в час или раз в 10 минут. Тогда с хостером можно было бы обсуждать проблемы с цифрами в руках.
Но это будет дополнительная нагрузка на сервер, такой анализ сам по себе может стать причиной отключения
if($sapi=="cgi")
на
if($sapi=="cgi" or $sapi=="cgi-fcgi")
иначе пример часто не работает
Не? Я ошибаюсь?
Кто прав? Или за годы оптимизорвали FC и он стал быстрее?
А как насчёт nginx без Апача?
Считаю что нужно сделать новую статью с актуальными версиями серверов и добавить nginx и ещё может что-то новое, всё-таки как 10 лет в обед...