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

Итак есть VPS на FreeBSD.
Apache 1.3.41
PHP 5.2.6
MySQL - не помню какой

CPU: ~2000
RAM: ~1152

Есть нагруженный проект с большой базой, кучей выборок из нее и т.д.
В индекс яши попадает около 250 000 страниц. Всё - динамика, генериться через php.

Посещалка пока около 800 в сутки активных пользователей, которые все выборки юзают.


Есть необходимость для снижения нагрузки и подобия защиты от http DDoS, в качестве frontend воткнуть Nginx.

Вот думаю, стоит ли игра свеч поднимать еще и FastCGI бэкэндом, т.е. сооружать связку Nginx - Apache - FastCGI.
Посещения будут расти дальше, будут появляться новые разделы сайта, с поиском по параметрам и т.д. (сопоставление в среднем 4-х таблиц, выборки из таблиц объемом 40 мегабайт и т.д.)

Кто как думает?

статья сподвигнувшая на размышлизмы:

ссылка

Nginx - Apache удобна, если статику первым выдавать.
php на апаче крутиться может без проблем.

800 человек - это если по 10 страниц на каждого, то 8000 страниц сгенерировать надо, допустим пик в 60% на 2 часа приходится в сутки.

(8000*60/100)*/2*3600 короче около 2 пользователей за 2 секунды.

с такой нагрузкой справится без проблем целерон 600MHz

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

Nginx - Apache удобна, если статику первым выдавать.
php на апаче крутиться может без проблем.

800 человек - это если по 10 страниц на каждого, то 8000 страниц сгенерировать надо, допустим пик в 60% на 2 часа приходится в сутки.

(8000*60/100)*/2*3600 короче около 2 пользователей за 2 секунды.

с такой нагрузкой справится без проблем целерон 600MHz

ды про справиться может цилер 600 - это понятно...и меньшее железо справлялось... тут тема в другом - во первых 800 - это не предел, там может шагнуть и за несколько тысяч,
во вторых тематика такая, что среднее количество просмотренных страниц - 20 на юзверя.
ну и в третьих, сейчас болтаемся голым апачем наружу, что собственно звиздец при малейшей http DDoS атаке.
Хочется сразу всё предусмотреть, чтобы потом в конфигах меньше ковыряться.

Звиздец будет и на nginx при ddos

тут смотри. тема вот какая.
нужно правильно выстроить политику кэширования и выдачи инфы.

допустим.
у нас страница с файлами занимает 500 кило. из них статики на 450 кило - их отдает nginx + выставить в ответе сервера срок хранения файлов (кэш браузера) пару суток.
40 кило самой странички - пусть будет 10 запросов в секунду.
смотрим в мониторе сколько отбирает sql - допустим 500 метров. 1152-500=~600
я так понимаю, что все пользователи в базе капаются? если да, то для таких страниц кэш как бы тупо делать, по сему все напрямую.
смотрим сколько сжирает 1 пользователь на страницу памяти.. допустим по 20 мегабайт +50-70 метров на сам апач итого 70-90 метров.. на остатке памяти от sql "влезет" 6-7-8 клиентов одновременно при мгновенной отдаче. или в 2 раза больше, при отклике в 2 раза больше.

не знаю, что у Вас за система, но у меня инет магаз или база автозапчастей генерят по 30-120 запросов к бд на 1 страницу. время генерирования 0,3 сек. время отклика 1,3-2,2 секунды
реально канал серванта 12мегабит. страничка около 350-600 кило каждая. итого я в секунду не могу выдать более 2-3-5 страниц клиентам. т.е. апач стоит и на раслабоне пашет, зато nginx копит очередь и выдает клиентам всем их страницы.
при 20-30 клиентах в секунду сервант начинает тормозить и время отклика становится около 5-7 секунд (гугл нервно бесится)


к чему я все это??

страница сколько весит? канал? пинг средний для клиентов? памяти на поток? свободной после sql? сколько sql времени тратит на страницу?

В автозапчастях сам все писал, там много чего на странице показывается и база боее 14 гигов..

а магазин.. битрикс, мать его

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

Итак есть VPS на FreeBSD.
...
Кто как думает?

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

Ставить всякие ngnix'ы, fastcgi и прочие чудеса, это похоже на стрельбу по площадям - можно попасть, а можно и не попасть. Можно копнуть и еще глубже: например, linux с файловой системой reiserFS работает процентов на 10-15 быстрее чем FreeBSD. А можно и ядро FreeBSD перекомпилировать с повышенным уровнем оптимизации - тоже немного быстрее будет работать. Несть развлечний для пытливого ума...

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

статья сподвигнувшая на размышлизмы:

ссылка

Хорошая статья, правильная. Еще бы в ней поменьше грамматических ошибок было, то доверия она вызывала бы еще больше. Странно, что автор не привел ни одной цифры иллюстрирующей скорость обработки запросов до и после.

Статья не очень хороша.
то, что статику nginx выдавать может - это любой дурак знает

хотелось бы РЕАЛЬНЫХ ОБЪЕКТИВНЫХ ТЕСТОВ связки nginx (или любого другого легкого сервера) + апач + акселератора какого нить для php + sql

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

Вот думаю, стоит ли игра свеч поднимать еще и FastCGI бэкэндом, т.е. сооружать связку Nginx - Apache - FastCGI.

Не стоит. Для сложного сайта php+FastCGI никакого заметного прироста производительности не даст и не может дать просто в силу устройства этого протокола для php. Об анти-DDOS вообще мечтать не надо. HelloWorld! сайты ускорятся.

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

Звиздец будет и на nginx при ddos

ну если фронтэндом идёт nginx, апач вертиться только на локалхосте, т.е. бэкэнд...
при http ddos подменяем динамическую страницу сайта на статический html и тихо прёмся, т.к. статичесую html-ку nginx может спокойно раздавать почти до бесконечности...
З.Ы. правда еще нужно не забыть про директиву ngx_http_limit_req_module или утилиту аля ctl для временного автоматического временного бана ip, с которых дофига запросов генериться.

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

временного автоматического временного бана ip

это 90-е года до н.э.
ddos заказывают с ботнета, с кучи IP
нагрузку может снять циска + промежуточный сервер + еще есть пара наработок

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

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

временного автоматического временного бана ip

это 90-е года до н.э.
ddos заказывают с ботнета, с кучи IP
нагрузку может снять циска + промежуточный сервер + еще есть пара наработок

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

Через 1 ip давно я ddos не видел. так что тут особо вариантов мало.
есть варианты с выносом фронта частично в облако.

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

Через 1 ip давно я ddos не видел. так что тут особо вариантов мало.
есть варианты с выносом фронта частично в облако.

хм.. а при чем тут 1 ip? с сегодняшними мощностями серверов - это не атака.
видел ddos-ы с несколько сотен и около десятка тысяч ip, как раз адекватная конфигурация nginx + csf нормально выдерживали.

Смотря какой сервак.
реально сейчас у меня на неслабом серванте битрикс тормозит из-за htacess
20-30 клиентов и валит сервант.
сайт сложный, много комплексных компонент.
ща просто тупо с нуля переделываю

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

Смотря какой сервак.
реально сейчас у меня на неслабом серванте битрикс тормозит из-за htacess
20-30 клиентов и валит сервант.
сайт сложный, много комплексных компонент.
ща просто тупо с нуля переделываю

кэширование в битриксе включено?
просто очень странное поведение.. либо сервак настроен не правильно, либо в битриксе отключено кэширование напрочь...
Либо php как CGI крутиться...
Очень нездоровая тенденция...

Кэширование работает. там htacess наворотили на 70 килобайт. он по каждому php файлу проверки устраивает. файловые операции еле ворочаются.
переделываю все постепенно

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

Кэширование работает. там htacess наворотили на 70 килобайт. он по каждому php файлу проверки устраивает. файловые операции еле ворочаются.
переделываю все постепенно

я не большой знаток битрикса, но нафига .htacess на 70 килобайт?
по моему это проблемы с логикой у разработчика сайта...
Сейчас специально глянул, что за монстры среди .htacess у меня есть, самые большие - это 4кб.
На битриксе около 1 кб.

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

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

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

а если вынести конфигурацию в основной файл апача, чтобы один раз парсить?