WordPress.com перевел (http://barry.wordpress.com/2008/04/28/load-balancer-update/) свои балансировщики нагрузки на nginx (http://www.sysoev.ru/nginx/) - очень серьезный шаг для nginx, так как когда такие мощные пользователи начинают использовать продукт, к ним присматриваются другие проекты, что в свое время повлияло на росте популярности lighttpd (http://www.lighttpd.net/). WordPress.com один из лидеров блог-хостинга, ожидается заметный рост доли nginx в следующем отчете netcraft (http://survey.netcraft.com/Reports/).
В процессе принятия решения рассматривались варианты использования балансировщиков HAProxy, Perlbal и LVS, но конечный выбор остановился на nginx, в силу трех причин:
- Простая и гибкая система конфигурации, возможность перечитывания конфигурации на лету;
- Возможность использования в качестве полноценного web-сервера, а не только балансировщика нагрузки;
- Только nginx в тестах на реальном трафике смог справиться с нагрузкой 8000 запросов в секунду.
...URL: http://barry.wordpress.com/2008/04/28/load-balancer-update/
Новость: http://www.opennet.me/opennews/art.shtml?num=15708
Просто супер!
осталось только дождаться выхода версии с кешированием и привалит счастье :)
>Просто супер!
>осталось только дождаться выхода версии с кешированием и привалит счастье :)ИМХО сервер должен сервить а не кешированием заниматься.Хотя если это будет отключаемым модулем - так и хрен с ним.Но лично мне в серверах типа lighttpd или nginx нужен именно маленький и ядреный сервер который при минимуме потребления ресурсов отгрузит файла оптом,а не монстр который умеет дофига всего когда оно нафиг не надо и только грузит систему почем зря.А так - поздравления автору.В целом довольно хороший и при том ШУСТРЫЙ и НЕ РЕСУРСОЕМКИЙ сервак.
Таки есть ещё Программисты в России :) Троекратное УРА!
Кстати как платформу они используют Дебиан и Убунту... ;)
Где это написано?Найдите сами :).Кстати да, если вы найдете это тем же методом что и я - там еще довольно прикольная надпись есть :) парни из вордпресса обладают чувством юмора.>Our platform currently consists of the following software: Debian/Ubuntu, PHP, MySQL,
>Litespeed, Pound, Wackamole, Spread, Nagios, Munin, Monit, NFS, Postfix, MyDNS.P.S. а 8000 запросов в секунду - это круто...
Когда же он сможет читать файлы в каталогах, наподобии .htaccess?
>Когда же он сможет читать файлы в каталогах, наподобии .htaccess?никогда... учи мат. часть и не позорься так больше...
А он (nginx) сам cgi-скрипты может выполнять/запускать? А то что-то у меня не получилось. ;-(
>А он (nginx) сам cgi-скрипты может выполнять/запускать? А то что-то у меня
>не получилось. ;-(Сам не может, есть встроенный перл, можно нарисовать модуль с нужной функциональностью. А cgi-скрипты можно под fastcgi-менеджером выполнять.
нет, не умеет. юзайте FastCGI или бекенды.
Да, к сожалению NginX пока не решает 99.9% проблем человечества, как все того хотели... :)Нужен .htaccess - опишите его сами, либо можете использовать немного измененный модуль Apache'а 1.3, которые занимается только тем, что обрабатывает .htaccess'ы и отдает результат. Я не спорю, .htaccess штука удобная, а порой является requirement'ом софта, но с точки зрения ее функциональности (перечитывание всего дерева директорий на предмет нахождения в нем .htaccess при КАЖДОМ запросе) - довольно емкая.
Насколько я понял из описания он запросы fast-cgi может перебрасывать на другой сервер для их обработки, а вот что он сам их обрабатывает как-то не очевидно. Насчет бэкендов, дак я и сейчас пользую апач, но он для моих задач несколько тяжеловат...
> Насколько я понял из описания он запросы fast-cgi может перебрасывать на другой серверВи сплутали CGI (протокол) і FastCGI (програму).
> для их обработки, а вот что он сам их обрабатывает как-то не очевидно.
http://blog.kovyrin.net/2006/05/30/nginx-php-fastcgi-howto/l.../
> Насчет бэкендов, дак я и сейчас пользую апач, но он для моих задач несколько тяжеловат...
Ну от і поставте NginX перед Apach-ем.
> Ви сплутали CGI (протокол) і FastCGI (програму).лишь в силу встроенного занудства добавлю, что FastCGI - это таки ещё и протокол :)
http://www.fastcgi.com/devkit/doc/fcgi-spec.html
// wbr
>Насколько я понял из описания он запросы fast-cgi может перебрасывать на другой
>сервер для их обработки,Логично.А зачем серверу внутри себя данные по fastcgi гонять если он все что надо напрямую может(в меру талантов)?Чтобы себя же притормозить лишней работой которая нафиг не нужна?Fastcgi - протокол позволяющий сбагрить запросы кому-то внешнему чтобы тот их обработал и отдал результат.Этот кто-то может быть и интерпретатором PHP, Perl или чем там еще который может нагенерить скажем на запрос страницу скриптом и сервак ее отдаст.Исторически первым был CGI. CGI позволяет серверу запустить для каких-то нужд внешнюю программу и передать ей параметры поступившего запроса в стандартном виде который поймут все программы понимающие что такое CGI и выгрести ответ, отдав его юзеру как будто это сам сервер страничку отдал.Сие решение однако имеет минус - на каждый запрос форкается внешняя программа, что весьма ресурсоемко.Подумали и решили что не стоит постоянно перезапускать CGI приложения.Так появился fastcgi.В нем общение между программой и сервером идет по протоколу fastcgi и программа не перезапускается каждый раз а постоянно висит и ждет запросов.
> а вот что он сам их обрабатывает как-то не очевидно.
А напуркуа бы серверу генерить и тут же обрабатывать fastcgi запросы?Прикиньте дворника который сперва мусорит чтобы потом за собой убрать?Ну вот и тут так же :)
>но он для моих задач несколько тяжеловат...
Апач тяжел в основном потому что форкает много тредов или процессов.Сие немало грузит проц и требует дофига RAM.С отдачей статики nginx или lighttpd справятся однозначно лучше - они не форкают процессы или треды на каждый запрос и потому КАРДИНАЛЬНО легковеснее в плане отдачи статики и на равных ресурсах потянут НАМНОГО больше.Да и вообще такие сервера никогда не будут дико грузить проц и жрать гигабайты RAM при отдаче статики.Не на чем.Скорее в способности дисковой подсистемы упрутся.Так что если вы отдаете файло кучами - апач явно в пролете а переведя файлоотгрузку с апача на лайт или nginx можно некисло сэкономить: крутой сервак с гигазами оперативы им не нужен.
С сервированием приложений все хитрее.У апача скажем PHP встроено как модуль в сервер.У nginx или лайта - таких модулей обычно нет.Но никто не мешает использовать fastcgi версию PHP (или чего вам там за интерпретер надо).При fastcgi интерпретер стартует как fastcgi сервер и ему наш сервак спихивает запросы.Для сайтов с небольшим и средним траффиком в итоге один такой сервак может осилить все, тем не менее, возможно потребуется немного что-то подправить по сравнению с апачом.Типа упомянутого htaccess.Однако в итоге на скромных ресурсах может поселиться вполне взрослый сайт на зависть остальным, кто покупает для такого же мощный и дорогой сервер.
Для очень нагруженных сайтов делают несколько иначе.Сервера приложений (да хоть тот же апач) ставятся за сервером типа нжинкса который запросы типа выполнения скриптов раскидывает на них, а статика как правило по прежнему отдается маленьким и легким сервером.В итоге неповоротливые апачи избавлены от нужды форкать на каждый статичный файл свои процессы или треды и намного больше занимаются выполнением веб-приложений и меньше - форками себя любимого.
P.S. Насколько по ресурсоемкости соотносится апач с модулем для PHP супротив PHP в виде fastcgi - я не знаю и не мерял.Если кто знает - велкам, расскажите, довольно интересно (читайте между строк "что легковеснее как сервие приложений - пхп в фастцги или пхп в виде апача", подозреваю что ответ может варьироваться в зависимости от ситуации).
>А он (nginx) сам cgi-скрипты может выполнять/запускать? А то что-то у меня
>не получилось. ;-(Если вам надо именно CGI а не FastCGI - посмотрите на lighttpd, он умеет и CGI и FastCGI.Однако...советую подумать дважды: CGI форкает процесс на каждый запрос.Это ресурсоемко.И не быстро.Сие приемлимо только если процесс небольшой, запросы не такие уж и частые и не занимают много времени.CGI который не fast имеет смысл *только* если есть готовая и жутко нужная приблуда на CGI а аналога на FastCGI нету(увы, и такое тоже бывает).Запускать штуки типа PHP через CGI можно, но мазохистично.Ибо такой сервер приложений по ресурсоемкости легко потягается с апачом постоянно форкая CGI процессы.FastCGI намного более продвинутый, легкий и быстрый вариант.По возможности используйте его.Насколько я знаю бывают готовые болванки для скриптов юзающих fastcgi и т.п..