Есть сомнения в целесообразности FastCGI

Я весь сайт переделываю. там много лишнего.
инет магазин с небольшим выбором (5 категорий по 3-7 товаров)
заодно делаю небольшое улучшение юзабилити, которое дает неплохую прибавку в конверте трафа.
отказываюсь от привычной авторизации заодно

Цитата ("ArtPro"):

Куча комплексных компонент с чпу
наследие прошлого + пару разделов переносили и ссылки сохранить надо

Pilat66 правильную идейку подсказал + вместо .htacess - очень неплохо юзать для сохранения ссылочной массы на старые урлы обычный 301 редирект через php.

header('HTTP/1.1 301 Moved Permanently');

header('Location: новый урл');

обычно задаётся одна маска для старых урлов, создаётся php файлик, который разбирает по условиям и редиректит на новые урлы - так целесообразнее.

Nginx+fastcgi+eAccelerator+php+MEMCACHED+MySQL и никакого апача.
Грамотно построеный софт.
И в итоге можно добиться того что в 90% случаев при запросе скриптов НЕ БУДЕТ обращения к жесткому диску вообще. То есть данные берутся из мемкашеда, исходники хранятся уже в скомпилированном виде и загруженные в оперативку.

У меня коре2дуо 3000 с 4гб оперативки сервак держал 8000 запросов в минуту и не потел

Думаю и в 2 раза больше выдержал бы, но пока не приходилось ему к сожалению(

render, Вы не пробовали из Вашей схемы выбросить eAccelerator - что будет с производительностью?

Ключевую роль тут все-таки играет минимум обращений к БД благодаря рациональному использованию memcached. eAcceleraor 20-30% производительности дает. Переписать скрипты с использованием memcached может дать разницу в производительности в несколько ПОРЯДКОВ. Полный отказ от апача это еще 20-30% производительности. Цифры примерные я точных исследований не проводил.

Ну и конечно же результат очень зависит от конкретной задачи. Можно придумать задачу где кеширование ничего не даст совсем.

render, я в который раз вижу страшные цифры про отказ от апача, но ещё ни один человек не сделал проверку на тестах. Насчёт eAccelerator+FastCGI тоже - цифры 20-30% странные, я бы предположил что 0.1% - ближе к истине, но проверить это не могу - так как не использую такую связку. Может, отключите как-нибудь eAccelerator в конфиге и протестируете? Живая нагруженная система - хорошая возможность.

На счет eAccelerator'а цифра адекватная действительности. Его как-раз когда включил то нагрузка на сервер (LA) упала на 20-30% в среднем.
Сами подумайте - каждый раз открывать кучу файлов, собирать все вместе и компилировать. Или взять уже откомпилированный кусок кода из оперативки. Что быстрее и на сколько?

А вот на счет апача ничего не замерял точно. По ощущениям быстрее. И еще одна мелочь, а приятно - на 100-200Мб в среднем больше стало свободно оперативки) Апач очень любит её кушать. Хотя для меня это и не критично но на ВДСах с малым количеством оперативки в тарифе думаю очень серьезная разница.

Тесты видел на статических файлах кто-то проводил. нгиникс в 6-10 раз быстрее.

render, FastCGI должен делать в частности то же что и eAccelerator, и только один раз при запуске, поэтому странно что включение eAccelerator дало такой эффект - этого быть не должно просто потому, что в среднем при 30% выгоде при компиляции на 1-м запросе к той же копии php эффективность в среднем составит 0.3% . Лучше проверить отключением eAccelerator .

Апач ест памяти столько же, сколько и FastCGi - ну может на 100К разницы на процесс и будет - так как процессов-то столько же и размер самого апача, без PHP, не очень большой. Я сильно подозреваю, что у Вас первоначальная конфигурация была неправильная, откуда и повышение быстродействия.

Тесты nginx неинтересны

Цитата:

FastCGI должен делать в частности то же что и eAccelerator

Он запускает ПХП один раз в отличии от обычного CGI. А eAccelerator конкретные ПХП файлы кеширует и компилирует один раз пока они не изменятся.
По моему это совсем не одно и то же...

Апач если его очень постаратся ободрать, выкинуть все лишнее будет может в полтора раза меньше чем fastCGI процесс жрать, а из коробки он вообще огромен.
Может это у Вас FastCGI Так настроен что жрет так же много как и апач?

Апач из коробки жрёт совсем не много памяти, что-то Вы путаете, там просто нечему память жрать.

Кстати, Ваш FastCGI вообще проходит фазу загрузки и компиляции PHP скриптов один раз или при каждом запросе?

Не буду спорить про апач. Только скажите почему по вашему тогда все крупные проекты в интернете давно уже отказались от апача?

FastCGI загрузку и компилацию скриптов PHP делает при каждом запросе - но сам интерпритатор PHP все время в памати. На сколько я знаю по другому он и не умеет иначе зачем нужны были бы PHP акселераторы? А eAccelrator в свою очередь держит в памяти уже откомпилированные ПХП скрипты.

Я посмотрел бегло - все проекты, по которым удалось найти информацию, работают под апачем, даже если запускают fastcgi - то из него. Может кто-то и перешёл, но два года назад такого массового перехода ещё не было.

Насчёт того что fastcgi сам умеет хранить опкод я, похоже, не прав, действительно - он подключает внешний акселератор. Но о повышении скорости при удалении апача цифр как не было, так и нет, причём ни у кого. Возможно, именно потому что такого перехода не делали.

• Rambler
  
• Yandex
  
• Begun
  
• Wordpress.com
  
• Wrike
  
• SourceForge.net
  
• vkontakte.ru
  
• megashara.com
  
• Либрусек
  
• Taba.ru

список с википедии тех кто использует нгиникс. Из этих проектов про все не знаю но часть точно не используют апач даже как бакенд.
еще могу добавить ukrhome.net, vmashine.com они точно не используют апача - мой друг делал.

Или что в Вашем понимании крупный проект? )

Использовать NGINX и не использовать Apache - суть разные явления, не находите?
То, что на фронте крутится NGINX не мешает на бэке работать Apache.

render, давайте на примере первых двух строчек - яндекса и рамблера - откуда информация? Крупнейшие части обоих работают вообще на перле. Так откуда инфа о переходе на php+fastcgi-apache ?

на счёт lib.rus.ec - апач там, скорее всего, судя по этому: ссылка

Воообще если посмотреть на презентации крупных систем - например facebook или почты рамблера - вопрос апач или не апач вообще не возникает, узкое место не в этом. И действительно, смешивать nginx и апач не стоит.

Цитата:

Так откуда инфа о переходе на php+fastcgi-apache ?

Я не говорил о переходе на конкретную связку, я говорил о не использовании апача.
В таких проектах каждая мелочь это повод сэкономить очень крупные суммы на железе.

Цитата:

То, что на фронте крутится NGINX не мешает на бэке работать Apache.

Цитата:

Из этих проектов про все не знаю но часть точно не используют апач даже как бакенд.

render, хорошо, откуда информация о неиспользовании апача на данных проектах - рамблер и яндекс?

Вот хорошая статья ссылка, из неё кусочек:
Цитата:

В качестве сервера бизнес-логики, то есть того, что отдает пользователям почту, нами используется Apache+mod_perl 1.3. Начнем снизу слайд презентации.

Почему не FastCGI? Вообще, FastCGI – прекрасная технология, но практика показывает, что принципиальной разницы между mod_perl и FastCGI нет, потому что основное количество времени – это не взаимодействие между уровнем mod-чего-то там и nginx, или Apache и nginx. А это все взаимодействие – ожидание базы, ожидание кэша… Если у вас есть возможность начинать проект заново, начинайте его с чего хотите. Если есть возможность проект не переписывать или нет желания – не переписывайте, оно будет одинаково работать как на mod_perl, так и на FastCGI.

Опять-же где я тыкал пальцем именно в эти проекты и говорил что там нет апача? :P :P :P

Цитата ("render"):

Опять-же где я тыкал пальцем именно в эти проекты и говорил что там нет апача? :P :P :P

Так зачем Вы их тогда указали? Я потерял нить Ваших рассуждений...

Подскажите, кто знает, osCommerce поддерживает fastcgi?