Описание способов построения эффективных Web-серверов без использования сервера Apache. Рассматривается вариант замены apache + mod_php на nginx, mathopd, lighttpd и т.д. + php под FastCGI.URL: http://freesource.info/wiki/Anti_Apache
Новость: http://www.opennet.me/opennews/art.shtml?num=4792
> Каждая копия Apache требует приблизительно 20Mb
> памяти. 100 одновременных соединений - 200Mb
> памяти. 1000 одновременных соединений - 2G памяти.Данные процессов расшариваются, т.е. 10 процессов по 20 Мб в сумме не 200 Мб, так как часть из этих 20Мб используется всеми процессами совместно. К тому же, получить 20 Мб процесс нужно очень постараться: как минимум иметь mod_perl или mod_php без memory_limit, прожорливого perl/php скрипта и активный mod_ssl.
PS. У нас есть один клиент, у которого в средмем около _600_ запросов к MySQL из одного вызова php-скрипта. Я вначале думал, что статистика глючит, а нет, у него в скрипте на каждый чих по несколько SELECT'ов :-( С разработчиками в зоне ответственности проще, их достаточно заставить погонять прект не на 50 тестовых записях, а на 50 тысячах.
Unix версия 1.х использует fork, при этом не происходит полного копирования процесса, копируются только те страницы памяти в которые производилась запись, "которые стали различаться между родителем и ребенком". Потребление памяти при этом незначительное.Более важно правильно организовать обработку запросов.
Если бы всё было так хорошо. На самом деле всё гораздо грустнее.Сам апача не такой уж прожорливый. Но тот же mod_php, ясен пень, уже при запуске инициализирует часть своих структур данных. 20Mb это была ошибка, признаю. Но сути это не меняет. fork спасает только касаемо статических данных, увы, в процессе работы дочка вынуждена несколько мегабайт реальной памяти себе забрать.
Все эти новомодные Web-серверы борются с этим тем, что обрабатывают сотни клиентов одновременно в каждой дочке.
>PS. У нас есть один клиент, у которого в средмем около _600_
>запросов к MySQL из одного вызова php-скрипта. Я вначале думал, что
>статистика глючит, а нет, у него в скрипте на каждый чих
>по несколько SELECT'ов :-(А это уже без шансов. Жизнь хостера не так сладка :-( А когда количество посетителей на таком сайте становится действительно большим, начинается песня.
Мне периодически приходится самому индексы создавать. Товарищи "веб-разработчики на PHP", увы, часто этого элементарно не умеют.
Но, слава богу, бывают более приятные задачи -- когда все квалифицированы, но ресурсов как ни крути, всё равно мало.
Да, mod_ssl очень часто штука обязательная. mod_perl я практически никому не даю использовать именно по этой самой причине его прожорливости. memory_limit метров 8 ставить приходится, меньше разработчики матерятся.
>Да, mod_ssl очень часто штука обязательная.Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его использования :-(
>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>ставить приходится, меньше разработчики матерятся.У меня лимит в 2Мб, и то я, напирмер, себе не могу представить, чем и как можно их забить при простой единовременной выборке, допустим, скрипта с форумом, при размере данных в базе 50 Кб. 2 Мб - это почти 450 тыс. слов, 200 страниц текста.
Вы даже не представляете, какие бывают странные вебмастера... Ужас.
>>Да, mod_ssl очень часто штука обязательная.
>Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его
>использования :-(В Apache тоже баги находили :) А на базе openssl у нас ещё и ssh. Будем от него отказываться? ;-)
А реализация крива, без вопросов.
>>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>>ставить приходится, меньше разработчики матерятся.
>У меня лимит в 2Мб, и то я, напирмер, себе не могу
>представить, чем и как можно их забить при простой единовременной выборке,
>допустим, скрипта с форумом, при размере данных в базе 50 Кб.
>2 Мб - это почти 450 тыс. слов, 200 страниц текста.Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну например, xml, отправлять админу (типа для backup'а). Или вообще вызывать mysqldump из PHP (!) и результат отправлять. Были у меня такие "пользователи", блин.
Во-вторых можно вообще не знать про то, что у SELECT есть выбор запрашиваемых полей, а также поддиректива WHERE. И делать "SELECT * FROM table" всегда и везде. Потом фильтровать в PHP, якобы "так проще".
В общем разработчики-ламеры разные бывают. Я с этим сейчас борюсь тем, что расставляю персональные ограничения. Если кто-то начинает вдруг материться что у него что-то там не работает, провожу лично разъяснительную беседу, и, если особо тупой, увеличиваю лимит.
>В Apache тоже баги находили :) А на базе openssl у нас
>ещё и ssh. Будем от него отказываться? ;-)Незнаю как у вас, а у меня доступ к ssh фаерволом открыт только с доверенных хостов.
Есть одна точка входа в доверенную сеть из внешней сети, на экстренный случай, но на нее не так просто попасть и ssh там висит не там где его обычно привыкли видеть.Что касается apache 1.3.x, то критическая уязвимость в нем была обнаружена один раз (после этого он у меня только в chroot живет с запрещением коннектов во вне). В mod_ssl дыры сводящие на нет его эффективность появляются регулярно, плюс хвост в виде openssl.
>Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну
У меня пример был для базы с 50Кб данных :-) Там нужно 500 полных select'ов сделать.
> Я вначале думал, что статистика глючит, а нет, у
> него в скрипте на каждый чих по несколько
> SELECT'ов :-(И как, благородные доны, от этого обычно избавляются?
Если разработчик вне зоны контроля - практически никак :( А вообще:
- Максимально оптимизировать и апач, и базу (как правило в подобных клинических случаях не спасает)
- Попытаться связаться с разработчиком и намекнуть ему на неаккуратность (как правило - безнадега)
- Попытаться договориться с клиентом и объяснить ему суть проблемы, с тем, чтобы он пинал разработчика (тоже обычно мало шансов, хотя это близкий к идеальному вариант, если получится)
- Если ты в состоянии разобраться в коде - попытаться договорится с клиентом о том, чтобы он позволил тебе поправить код (хотя частенько это "исправление" доходит до состояния "полного переписывания")
- Объяснить клиенту, что в данной ситуации (объем базы * кол-во запросов * "специфика веб-приложения") необходимо значительно нарастить мощности компьютера (К этому совету, как ни странно, клиенты нередко прислушиваются, хотя "клинику" и он не сильно спасает...)
Нет, я имел в виду, про select'ы.
Чтобы уменьшить их использование, предлагается кэшировать?
Так от этого тоже же процесс в размере увеличиться?
s/увеличиться/увеличится/
>Нет, я имел в виду, про select'ы.
>Чтобы уменьшить их использование, предлагается кэшировать?
>Так от этого тоже же процесс в размере увеличиться?Чаще всего надо просто логику программы переделывать.
А кое-где, действительно, полезно бывает и кэшировать. memcache рулит. mod_perl тоже. Ну и FastCGI не отстаёт :)В некоторых случаях, если приложение действительно сложное, стоит подумать о переходе на более функциональную базу данных -- PostgreSQL.
Кто нибудь тестировал / сравнивал lighttpd +fast cgi php и апач, mathopd на таких тяжеловатых приложениях как SquirrelMail
У меня на простых php запросах выигрыш по загрузке процессора ошутимее в пользу lighttpd . Но при uploade файлов на сервер при прикреплении к письму вложения . lighttpd сильнее (раза в 2 )грузит процессор чем все остальные .
все тестировалось на Freebsd 5.2
lighttpd-1.3.2
mathopd-1.5p2
apach 1.x
>Есть и ещё один важный момент. В Linux, особенно >начиная с ядра 2.6, имеется масса >усовершенствований для быстрой передачи по сети >большим количеством одновременных потоков из >однопоточного приложения. Apache не может >воспользоваться большей частью этих >усовершенствований.
Интересует что за усовершенствования? Где про это почитать?
Видимо здесь:man epoll
man sendfile
Еще один неграмотный опус ни о чем.
>Еще один неграмотный опус ни о чем.Согласен, вроде автор - грамотный человек, но чаще всего полную ахинею несет. Чего стоит только: "В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache". Так то же классическая архитектура. Да и не является "дочка" копией, неправда это.
Или вот еще: "Все модули бинарные, поэтому ошибка в любом из модулей приводит... Да, к чему угодно в рамках конкретной дочки Apache." А что, если модули "не бинарные" - в них ошибок никогда не бывает? Да и что за зверь такой, "не бинарные" модули, хотелось бы узнать? Но особенно меня заинтересовала фраза "В Linux, особенно начиная с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети большим количеством одновременных потоков из однопоточного приложения". Господа, объясните мне пожалуйста, что автор хотел этим сказать? Я лично не понял. Это что это за пупер-дупер новейшие сетевые технологии, позволяющие передавать данные по сети аж в несколько потоков? Правда что ли? Сегодня ведь не первое апреля, вроде бы.
>Согласен, вроде автор - грамотный человек, но чаще всего полную ахинею несет.Прикольная характеристика.
>Чего стоит только: "В 1.3.* каждое параллельной соединение обрабатывается отдельной копией
>(дочкой) Apache". Так то же классическая архитектура. Да и не является
>"дочка" копией, неправда это.Да, это классическая архитектура. Вернее одна из классических. Самая простая в реализации, но далеко не самая эффективная. Увы.
Далее. fork() рождает именно _копию_. Благодаря использованию механизма CopyOnWrite во всех UNIX-like ОС память при этом расходуется минимально. Но это именно копия.
>Или вот еще: "Все модули бинарные, поэтому ошибка в любом из модулей
>приводит... Да, к чему угодно в рамках конкретной дочки Apache." А
>что, если модули "не бинарные" - в них ошибок никогда не
>бывает? Да и что за зверь такой, "не бинарные" модули, хотелось
>бы узнать?Это было неточное объяснение.
Под бинарными модулями я имел в виду классический подход с динамически подгружаемыми shared-objects. Действительно, любая ошибка в таком модуле может привести к любым изменениям в поведении Apache.
Более приятный подход, это когда модули связываются друг с другом посредством pipe'ов, сокетов, и других методов общения без общей памяти.
>Но особенно меня заинтересовала фраза "В Linux, особенно начиная
>с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети
>большим количеством одновременных потоков из однопоточного приложения". Господа, объясните мне пожалуйста,
>что автор хотел этим сказать? Я лично не понял. Это что
>это за пупер-дупер новейшие сетевые технологии, позволяющие передавать данные по сети
>аж в несколько потоков? Правда что ли? Сегодня ведь не первое
>апреля, вроде бы.Читайте доки, они рулез.
Конкретно начиная с 2.6 у нас есть epoll, например. А ещё, начиная с ядра 2.2 (или даже 2.0?) у нас есть sendfile. Правильное использование которого оч-ч-чень, знаете ли, процессорное время экономит. А ещё у нас есть начиная с 2.6 aio в ядре.
>Конкретно начиная с 2.6 у нас есть epoll, например.http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&se...
> А ещё, начиная
>с ядра 2.2 (или даже 2.0?) у нас есть sendfile.http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&...
http://www.freebsd.org/cgi/man.cgi?query=writev&apropos=0&se...> Правильное
>использование которого оч-ч-чень, знаете ли, процессорное время экономит. А ещё у
>нас есть начиная с 2.6 aio в ядре.а нас в квартире газ, а у Вас?
http://www.freebsd.org/cgi/man.cgi?query=aio&apropos=0&sekti...
>> А ещё, начиная
>>с ядра 2.2 (или даже 2.0?) у нас есть sendfile.
>
>http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&...По поводу sendfile мимо. Правильно здесь:
http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&...
>По поводу sendfile мимо. Правильно здесь:
>http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&...согласен.
Согласен. Статья от фонаря. Типа: пришел увидел, нацарапал.
2 Shaman007
Будь добр в таком тоне выражать свое мнение на лоре, там тебя больше любят