http://freesource.info/wiki/AntiApache History/revisions of FreeSource/AntiApache en-us http://freesource.info/wiki/AntiApache/show?time=2004-12-22+00%3A04%3A37 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a name=".antiapache" href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-22+00%3A04%3A37">2004-12-22 00:04:37</a> и <a href="http://freesource.info/wiki/AntiApache">2005-04-05 19:44:56</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">В&nbsp;настоящее время безусловным лидером среди Web-серверов на&nbsp;просторах Internet является <a name=".software.apache" href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a>. Это&nbsp;самый функциональный Web-сервер, и, к&nbsp;тому же, большинство системных администраторов свободный UNIX-like систем в&nbsp;той или&nbsp;иной степени с&nbsp;ним сталкивались и&nbsp;умеют его&nbsp;конфигурировать. Также неоспоримым преимуществом является его&nbsp;портабельность (он есть практически подо все&nbsp;UNIX-like ОС, а&nbsp;также под&nbsp;<a name="windows" href="http://freesource.info/wiki/Windows&" class="" title="Windows">Windows</a>, MAC&nbsp;OS&nbsp;и OS/2).<br /> Кроме того у&nbsp;каждого хостера, предоставляющего Linux или&nbsp;<a name="freebsd" href="http://freesource.info/wiki/FreeBSD&" class="">Free&nbsp;BSD</a> хостинг установлен обычно именно он&nbsp;&mdash; родной и&nbsp;любимый <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a>.<br /> Сейчас есть две&nbsp;ветки <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> &mdash; 1.3.* и&nbsp;2.*.<br /> В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> в&nbsp;среднем требует приблизительно 2Mb памяти (по моей статистике). 100 одновременных соединений &mdash; 200Mb памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.<br /> Вся&nbsp;удивительная функциональность <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> достигается за&nbsp;счёт модульной архитектуры. Все&nbsp;модули бинарные, поэтому ошибка в&nbsp;любом из&nbsp;модулей приводит... Да, к&nbsp;чему угодно в&nbsp;рамках конкретной дочки <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a>. Опять же, слава богу, ввиду отлаженности большинства модулей это&nbsp;обычно не&nbsp;слишком важно. Но&nbsp;всё-таки существенно, ибо&nbsp;ошибка, например, в&nbsp;mod_ssl (что уже&nbsp;бывало) предоставляет доступ ко&nbsp;всем обслуживаемым ресурсам. С&nbsp;учётом роста возможностей, а&nbsp;также массы внешних расширений, написаных сторонними разработчиками (например самое распространённое такое расширение &mdash; mod_php) удерживать в&nbsp;полной безопаности такую систему становится сложно. Полноценного механизма разделения привелегий пока так&nbsp;и&nbsp;нет.<br /> Результат &mdash; дочка <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a>, размером в&nbsp;20Mb висит в&nbsp;памяти большую часть времени лишь для&nbsp;того, чтобы отдать пользователю запрос размером в&nbsp;<span class="nobr">5&ndash;20</span>Kb. До&nbsp;очарования идиотичная трата такого дорогостоящего ресурса, как&nbsp;память (которая чаще всего становится в&nbsp;серверах &laquo;бутылочным горлышком&raquo;).<br /> Ясен пень, что&nbsp;администраторы (как и&nbsp;их руководство) не&nbsp;шибко любят тратить ресурсы сервера впустую. Поэтому (ну не&nbsp;только поэтому, конечно) было изоберетно такое гениальное средство как&nbsp;&#8220;reverse proxy&#8221;. Идея проста &mdash; пусть средство, предназначеное для&nbsp;быстрой передачи данных клиенту этим и&nbsp;занимается, а&nbsp;<a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> просто подготавливает данные для&nbsp;отправки пользователю. Результат &mdash; экономия памяти и&nbsp;увеличение производительности. А&nbsp;если ещё авторы скриптов озаботились столь корректным их&nbsp;написанием, что&nbsp;прокси могут по&nbsp;возможности кэшировать их&nbsp;вывод, то&nbsp;экономия становится ещё более ощутимой.<br /> Ещё одна неприятность <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> &mdash; большие накладные расходы при&nbsp;передаче чисто статических данных. Обычно на&nbsp;одну генерируемую страницу приходится огромное количество изображений, которые в&nbsp;основном являются статическими данными, а&nbsp;не генерируются при&nbsp;каждом обращении (за исключением, разве что, счётчиков). Тут&nbsp;функциональность <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> играет против него.<br /> Есть и&nbsp;ещё один важный момент. В&nbsp;Linux, особенно начиная с&nbsp;ядра 2.6, имеется масса усовершенствований для&nbsp;быстрой передачи по&nbsp;сети большим количеством одновременных потоков из&nbsp;<u>однопоточного</u> приложения. <a href="http://freesource.info/wiki/SoftWare/Apache&" class="" title="Soft&nbsp;Ware&nbsp;/&nbsp;Apache">Apache</a> не&nbsp;может воспользоваться большей частью этих усовершенствований.</div><br /> <b>Удалено:</b><br /> <div class="deletions">В&nbsp;настоящее время безусловным лидером среди Web-серверов на&nbsp;просторах Internet является Apache. Это&nbsp;самый функциональный Web-сервер, и, к&nbsp;тому же, большинство системных администраторов свободный UNIX-like систем в&nbsp;той или&nbsp;иной степени с&nbsp;ним сталкивались и&nbsp;умеют его&nbsp;конфигурировать. Также неоспоримым преимуществом является его&nbsp;портабельность (он есть практически подо все&nbsp;UNIX-like ОС, а&nbsp;также под&nbsp;Windows, MAC&nbsp;OS&nbsp;и OS/2).<br /> Кроме того у&nbsp;каждого хостера, предоставляющего Linux или&nbsp;<a href="http://freesource.info/wiki/FreeBSD&" class="">Free&nbsp;BSD</a> хостинг установлен обычно именно он&nbsp;&mdash; родной и&nbsp;любимый Apache.<br /> Сейчас есть две&nbsp;ветки Apache &mdash; 1.3.* и&nbsp;2.*.<br /> В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия Apache в&nbsp;среднем требует приблизительно 2Mb памяти (по моей статистике). 100 одновременных соединений &mdash; 200Mb памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.<br /> Вся&nbsp;удивительная функциональность Apache достигается за&nbsp;счёт модульной архитектуры. Все&nbsp;модули бинарные, поэтому ошибка в&nbsp;любом из&nbsp;модулей приводит... Да, к&nbsp;чему угодно в&nbsp;рамках конкретной дочки Apache. Опять же, слава богу, ввиду отлаженности большинства модулей это&nbsp;обычно не&nbsp;слишком важно. Но&nbsp;всё-таки существенно, ибо&nbsp;ошибка, например, в&nbsp;mod_ssl (что уже&nbsp;бывало) предоставляет доступ ко&nbsp;всем обслуживаемым ресурсам. С&nbsp;учётом роста возможностей, а&nbsp;также массы внешних расширений, написаных сторонними разработчиками (например самое распространённое такое расширение &mdash; mod_php) удерживать в&nbsp;полной безопаности такую систему становится сложно. Полноценного механизма разделения привелегий пока так&nbsp;и&nbsp;нет.<br /> Результат &mdash; дочка Apache, размером в&nbsp;20Mb висит в&nbsp;памяти большую часть времени лишь для&nbsp;того, чтобы отдать пользователю запрос размером в&nbsp;<span class="nobr">5&ndash;20</span>Kb. До&nbsp;очарования идиотичная трата такого дорогостоящего ресурса, как&nbsp;память (которая чаще всего становится в&nbsp;серверах &laquo;бутылочным горлышком&raquo;).<br /> Ясен пень, что&nbsp;администраторы (как и&nbsp;их руководство) не&nbsp;шибко любят тратить ресурсы сервера впустую. Поэтому (ну не&nbsp;только поэтому, конечно) было изоберетно такое гениальное средство как&nbsp;&#8220;reverse proxy&#8221;. Идея проста &mdash; пусть средство, предназначеное для&nbsp;быстрой передачи данных клиенту этим и&nbsp;занимается, а&nbsp;Apache просто подготавливает данные для&nbsp;отправки пользователю. Результат &mdash; экономия памяти и&nbsp;увеличение производительности. А&nbsp;если ещё авторы скриптов озаботились столь корректным их&nbsp;написанием, что&nbsp;прокси могут по&nbsp;возможности кэшировать их&nbsp;вывод, то&nbsp;экономия становится ещё более ощутимой.<br /> Ещё одна неприятность Apache &mdash; большие накладные расходы при&nbsp;передаче чисто статических данных. Обычно на&nbsp;одну генерируемую страницу приходится огромное количество изображений, которые в&nbsp;основном являются статическими данными, а&nbsp;не генерируются при&nbsp;каждом обращении (за исключением, разве что, счётчиков). Тут&nbsp;функциональность Apache играет против него.<br /> Есть и&nbsp;ещё один важный момент. В&nbsp;Linux, особенно начиная с&nbsp;ядра 2.6, имеется масса усовершенствований для&nbsp;быстрой передачи по&nbsp;сети большим количеством одновременных потоков из&nbsp;<u>однопоточного</u> приложения. Apache не&nbsp;может воспользоваться большей частью этих усовершенствований.</div></div> http://freesource.info/wiki/AntiApache/show?time=2004-12-18+20%3A57%3A55 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-18+20%3A57%3A55">2004-12-18 20:57:55</a> и <a href="http://freesource.info/wiki/AntiApache?time=2004-12-22+00%3A04%3A37">2004-12-22 00:04:37</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия Apache в&nbsp;среднем требует приблизительно 2Mb памяти (по моей статистике). 100 одновременных соединений &mdash; 200Mb памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.</div><br /> <b>Удалено:</b><br /> <div class="deletions">В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия Apache требует приблизительно 20Mb памяти. 100 одновременных соединений &mdash; 200Mb памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.</div></div> http://freesource.info/wiki/AntiApache/show?time=2004-12-15+19%3A38%3A35 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+19%3A38%3A35">2004-12-15 19:38:35</a> и <a href="http://freesource.info/wiki/AntiApache?time=2004-12-18+20%3A57%3A55">2004-12-18 20:57:55</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Резюме: существование Fast CGI&nbsp;и&nbsp;поддержка его&nbsp;многими специализироваными &laquo;быстрыми&raquo; браузерами делает несущественным наличие mod_php. А&nbsp;тот факт, что&nbsp;php можно собрать и&nbsp;в виде fastcgi версии убивает одно из&nbsp;самых главных мнимых преимуществ Apache &mdash; то, что&nbsp;под него, якобы, заточен PHP.</div><br /> <b>Удалено:</b><br /> <div class="deletions">Резюме: существование Fast CGI&nbsp;и&nbsp;поддержка его&nbsp;многими специализироваными &laquo;быстрыми&raquo; браузерами делает несущественной наличии mod_php. А&nbsp;тот факт, что&nbsp;php можно собрать и&nbsp;в виде fastcgi версии убивает одно из&nbsp;самых главных мнимых преимуществ Apache &mdash; то, что&nbsp;под него, якобы, заточек PHP.</div></div> http://freesource.info/wiki/AntiApache/show?time=2004-12-15+17%3A16%3A41 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+17%3A16%3A41">2004-12-15 17:16:41</a> и <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+19%3A38%3A35">2004-12-15 19:38:35</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions"><a href="http://freesource.info/wiki/Novosti_Sajjta_Freesource_Info" target="_blank" title="" class="outerlink">подписка</a> на&nbsp;новости сайта и&nbsp;полные тексты статей</div></div> http://freesource.info/wiki/AntiApache/show?time=2004-12-15+17%3A15%3A33 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+17%3A15%3A33">2004-12-15 17:15:33</a> и <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+17%3A16%3A41">2004-12-15 17:16:41</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">Хорошим бысрым http-сервером, поддерживающим <span class="missingpage">Fast&nbsp;CGI</span><a href="http://freesource.info/wiki/FastCGI/edit?add=1&" title="Создать эту страницу">?</a> является lighttpd.</div><br /> <b>Удалено:</b><br /> <div class="deletions"><div class="indent"><div class="indent"></div></div></div></div> http://freesource.info/wiki/AntiApache/show?time=2004-12-15+17%3A13%3A10 <div class="pageBefore"><img src="http://freesource.info/wiki/images/z.gif" width="1" height="1" border="0" alt="" style="display:block" align="top" /></div><div class="page"> <b>Сравнение версий <a href="http://freesource.info/wiki/AntiApache&" class="">/Anti&nbsp;Apache</a> за <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+17%3A13%3A10">2004-12-15 17:13:10</a> и <a href="http://freesource.info/wiki/AntiApache?time=2004-12-15+17%3A15%3A33">2004-12-15 17:15:33</a></b><br /> <br /> <b>Добавлено:</b><br /> <div class="additions">В&nbsp;настоящее время безусловным лидером среди Web-серверов на&nbsp;просторах Internet является Apache. Это&nbsp;самый функциональный Web-сервер, и, к&nbsp;тому же, большинство системных администраторов свободный UNIX-like систем в&nbsp;той или&nbsp;иной степени с&nbsp;ним сталкивались и&nbsp;умеют его&nbsp;конфигурировать. Также неоспоримым преимуществом является его&nbsp;портабельность (он есть практически подо все&nbsp;UNIX-like ОС, а&nbsp;также под&nbsp;Windows, MAC&nbsp;OS&nbsp;и OS/2).<br /> Кроме того у&nbsp;каждого хостера, предоставляющего Linux или&nbsp;<a href="http://freesource.info/wiki/FreeBSD&" class="">Free&nbsp;BSD</a> хостинг установлен обычно именно он&nbsp;&mdash; родной и&nbsp;любимый Apache.<br /> Однако у&nbsp;меня есть основания считать его&nbsp;<u>в настоящее время</u> не&nbsp;лучшим выбором для&nbsp;построения своего сайта. И&nbsp;я хочу описать здесь эти&nbsp;основания.<br /> Первая является реально стабильной и&nbsp;чаще всего применяемой. Новых усовершенствований в&nbsp;неё давно не&nbsp;вносится, но&nbsp;и имеющегося набора функциональности хватает большинство пользователей за&nbsp;глаза.<br /> Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в&nbsp;теории добиться и&nbsp;большей производительности, и&nbsp;большей безопасности, и&nbsp;при этом большей портируемости (имеется в&nbsp;виду в&nbsp;первую очередь в&nbsp;не-UNIX системы). Но, увы, серьёзные проблемы безопасности в&nbsp;ней находят хорошо хоть не&nbsp;каждый день. И, несмотря на&nbsp;то что&nbsp;официально она&nbsp;именуется стабильной, реально это&nbsp;хорошее средство системному администратору сделать свою жизнь менее скучной.<br /> В&nbsp;общем-то сейчас опытных администраторов эта&nbsp;мышиная возня слабо интересует, потому как&nbsp;1.3.* работал, работает, и&nbsp;ещё ой&nbsp;как долго проработает.<br /> В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия Apache требует приблизительно 20Mb памяти. 100 одновременных соединений &mdash; 200Mb памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.<br /> Вся&nbsp;удивительная функциональность Apache достигается за&nbsp;счёт модульной архитектуры. Все&nbsp;модули бинарные, поэтому ошибка в&nbsp;любом из&nbsp;модулей приводит... Да, к&nbsp;чему угодно в&nbsp;рамках конкретной дочки Apache. Опять же, слава богу, ввиду отлаженности большинства модулей это&nbsp;обычно не&nbsp;слишком важно. Но&nbsp;всё-таки существенно, ибо&nbsp;ошибка, например, в&nbsp;mod_ssl (что уже&nbsp;бывало) предоставляет доступ ко&nbsp;всем обслуживаемым ресурсам. С&nbsp;учётом роста возможностей, а&nbsp;также массы внешних расширений, написаных сторонними разработчиками (например самое распространённое такое расширение &mdash; mod_php) удерживать в&nbsp;полной безопаности такую систему становится сложно. Полноценного механизма разделения привелегий пока так&nbsp;и&nbsp;нет.<br /> Ну&nbsp;и самое неприятное, портабельность вынуждает реализовывать не&nbsp;самую эффективную архитектуру, а&nbsp;самую универсальную. А&nbsp;разница между оптимальными подходами в&nbsp;Windows и&nbsp;UNIX-like ОС&nbsp;огромна.<br /> Основной режим работе серверов (особенно в&nbsp;России, где&nbsp;больше всего подключений низкоскоростные) выглядит следующим образом:<br /> Результат &mdash; дочка Apache, размером в&nbsp;20Mb висит в&nbsp;памяти большую часть времени лишь для&nbsp;того, чтобы отдать пользователю запрос размером в&nbsp;<span class="nobr">5&ndash;20</span>Kb. До&nbsp;очарования идиотичная трата такого дорогостоящего ресурса, как&nbsp;память (которая чаще всего становится в&nbsp;серверах &laquo;бутылочным горлышком&raquo;).<br /> Ясен пень, что&nbsp;администраторы (как и&nbsp;их руководство) не&nbsp;шибко любят тратить ресурсы сервера впустую. Поэтому (ну не&nbsp;только поэтому, конечно) было изоберетно такое гениальное средство как&nbsp;&#8220;reverse proxy&#8221;. Идея проста &mdash; пусть средство, предназначеное для&nbsp;быстрой передачи данных клиенту этим и&nbsp;занимается, а&nbsp;Apache просто подготавливает данные для&nbsp;отправки пользователю. Результат &mdash; экономия памяти и&nbsp;увеличение производительности. А&nbsp;если ещё авторы скриптов озаботились столь корректным их&nbsp;написанием, что&nbsp;прокси могут по&nbsp;возможности кэшировать их&nbsp;вывод, то&nbsp;экономия становится ещё более ощутимой.<br /> Кроме того этот подход ещё и&nbsp;снижает нагрузку на&nbsp;базы данных, уменьшая количество одновременных запросов. Ещё один плюс такой технологии ускорения.<br /> Ещё одна неприятность Apache &mdash; большие накладные расходы при&nbsp;передаче чисто статических данных. Обычно на&nbsp;одну генерируемую страницу приходится огромное количество изображений, которые в&nbsp;основном являются статическими данными, а&nbsp;не генерируются при&nbsp;каждом обращении (за исключением, разве что, счётчиков). Тут&nbsp;функциональность Apache играет против него.<br /> Есть и&nbsp;ещё один важный момент. В&nbsp;Linux, особенно начиная с&nbsp;ядра 2.6, имеется масса усовершенствований для&nbsp;быстрой передачи по&nbsp;сети большим количеством одновременных потоков из&nbsp;<u>однопоточного</u> приложения. Apache не&nbsp;может воспользоваться большей частью этих усовершенствований.<br /> Результат: nginx выдерживает на&nbsp;раздаче статического контента нагрузку по&nbsp;одновременному количеству соединений более чем&nbsp;в&nbsp;100 раз&nbsp;большую.<br /> Многие помнят почему всеми так&nbsp;любим mod_php. Любими он&nbsp;просто потому, что&nbsp;модуль, естественно быстрее чем&nbsp;вызывать интерпретатор каждый раз&nbsp;при обращении к&nbsp;скрипту (как это&nbsp;происходит в&nbsp;случае с&nbsp;CGI). В&nbsp;результате mod_php многократно выигрывает по&nbsp;скорости как&nbsp;у&nbsp;CLI php, так&nbsp;и&nbsp;у perl (не считая mod_perl, разумеется, но&nbsp;это отдельная долгая печальная история, почему большинство хостеров эту&nbsp;чудесную для&nbsp;программиста возможность предоставляют крайне редко). Так&nbsp;вот, Fast CGI&nbsp;даёт те&nbsp;же самые возможности и&nbsp;даже больше. В&nbsp;этом он&nbsp;ближе к&nbsp;mod_perl. Суть Fast CGI&nbsp;&mdash; скрипт вызывается <u>один раз</u>, а&nbsp;потом ему&nbsp;передаются запросы и&nbsp;забираются ответы. Это&nbsp;требует более внимательного программирования, однако даёт потрясающие возможности, такие как&nbsp;кэширование некоторых данных между сессиями, чего нет&nbsp;у&nbsp;mod_php (и что&nbsp;и&nbsp;даёт такое потрясающее преимущество по&nbsp;производительности хорошо написаным mod_perl скриптам).<br /> Резюме: существование Fast CGI&nbsp;и&nbsp;поддержка его&nbsp;многими специализироваными &laquo;быстрыми&raquo; браузерами делает несущественной наличии mod_php. А&nbsp;тот факт, что&nbsp;php можно собрать и&nbsp;в виде fastcgi версии убивает одно из&nbsp;самых главных мнимых преимуществ Apache &mdash; то, что&nbsp;под него, якобы, заточек PHP.<br /> <ul><li> формирует очередь из&nbsp;небольшого количества параллельных запросов, которые будут отданы серверу приложений</li></ul> 2-я линия это&nbsp;сервер приложений, любой http-сервер поддерживающий fastcgi. В&nbsp;случае наличия нескольких разных сервисов даже на&nbsp;одном сайте разумно запустить их&nbsp;под разными серверами &mdash; паранойя лучший друг системного администратора. Этим сервером, кстати, вполне может быть и&nbsp;старый добрый Apache, если вы&nbsp;к нему привыкли, или&nbsp;если есть какие-то специфические приложения. Но&nbsp;лучше заменить его&nbsp;чем-нибудь гораздо более лёгким.<br /> 3-я линия это, как&nbsp;обычно, <span class="missingpage">My&nbsp;SQL</span><a href="http://freesource.info/wiki/MySQL/edit?add=1&" title="Создать эту страницу">?</a> или&nbsp;<span class="missingpage">Postgre&nbsp;SQL</span><a href="http://freesource.info/wiki/PostgreSQL/edit?add=1&" title="Создать эту страницу">?</a>, в&nbsp;зависимости от&nbsp;особенностей данного проекта и&nbsp;его моделей данных. Во&nbsp;многих случаях также может отсутствовать, будучи заменённым на&nbsp;встраиваемый движок баз&nbsp;данных sqlite (<a href="http://www.sqlite.ru)" target="_blank" title="Внешняя ссылка (откроется в новом окне)" class="outerlink"><img src="http://freesource.info/wiki/themes/coffee/icons/web.gif" alt="" border="0" />http://www.sqlite.ru)</a>. <br /> На&nbsp;крупном портале, или&nbsp;хостинг-сервисе имеет смысл первую линию разбить на&nbsp;несколько этпаов, выполняющихся на&nbsp;разных серверах, а&nbsp;также добавить кэширующий прокси-сервер, который бы&nbsp;держал все&nbsp;данные в&nbsp;памяти. <br /> Описаные выше идеи далеко не&nbsp;новы, и&nbsp;известны многим специалистам. Увы, подход LAMP (Linux Apache <span class="missingpage">My&nbsp;SQL</span><a href="http://freesource.info/wiki/MySQL/edit?add=1&" title="Создать эту страницу">?</a> PHP) настолько вселился в&nbsp;души современных web-разработчиков, что&nbsp;они часто даже не&nbsp;задумываются о&nbsp;наличии альтернативных решений, более эффективных чем&nbsp;известные им&nbsp;сейчас.<br /> Эта&nbsp;статья будет постоянно дорабатываться и&nbsp;корректироваться у&nbsp;меня на&nbsp;сайте, ибо&nbsp;тема эта&nbsp;неисчерпаема, и&nbsp;подлежит ещё долгому и&nbsp;ценному (я надеюсь) обсуждению.<br /> 3. или, то&nbsp;же самое другими словами &mdash; правильная настройка системы гораздо важнее крутизны вашего сервера :)</div><br /> <b>Удалено:</b><br /> <div class="deletions">В&nbsp;настоящее время безусловным лидером среди Web-серверов на&nbsp;просторах Internet<br /> является Apache. Это&nbsp;самый функциональный Web-сервер, и, к&nbsp;тому же, большинство<br /> системных администраторов свободный UNIX-like систем в&nbsp;той или&nbsp;иной степени с<br /> ним&nbsp;сталкивались и&nbsp;умеют его&nbsp;конфигурировать. Также неоспоримым преимуществом<br /> является его&nbsp;портабельность (он есть практически подо все&nbsp;UNIX-like ОС, а&nbsp;также<br /> под&nbsp;Windows, MAC&nbsp;OS&nbsp;и OS/2).<br /> Кроме того у&nbsp;каждого хостера, предоставляющего Linux или&nbsp;<a href="http://freesource.info/wiki/FreeBSD&" class="">Free&nbsp;BSD</a> хостинг<br /> установлен обычно именно он&nbsp;&mdash; родной и&nbsp;любимый Apache.<br /> Однако у&nbsp;меня есть основания считать его&nbsp;<u>в настоящее время</u> не&nbsp;лучшим<br /> выбором для&nbsp;построения своего сайта. И&nbsp;я хочу описать здесь эти&nbsp;основания.<br /> Первая является реально стабильной и&nbsp;чаще всего применяемой. Новых<br /> усовершенствований в&nbsp;неё давно не&nbsp;вносится, но&nbsp;и имеющегося набора<br /> функциональности хватает большинство пользователей за&nbsp;глаза.<br /> Вторая имеет сильно переработаную архитектуру, кое-где позволяющую в&nbsp;теории<br /> добиться и&nbsp;большей производительности, и&nbsp;большей безопасности, и&nbsp;при этом<br /> большей портируемости (имеется в&nbsp;виду в&nbsp;первую очередь в&nbsp;не-UNIX системы).<br /> Но, увы, серьёзные проблемы безопасности в&nbsp;ней находят хорошо хоть не&nbsp;каждый<br /> день. И, несмотря на&nbsp;то что&nbsp;официально она&nbsp;именуется стабильной, реально это<br /> хорошее средство системному администратору сделать свою жизнь менее скучной.<br /> В&nbsp;общем-то сейчас опытных администраторов эта&nbsp;мышиная возня слабо интересует,<br /> потому как&nbsp;1.3.* работал, работает, и&nbsp;ещё ой&nbsp;как долго проработает.<br /> В&nbsp;1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой)<br /> Apache (в 2.* это&nbsp;отдельная нить, что&nbsp;несколько экономнее). Каждая копия Apache<br /> требует приблизительно 20Mb памяти. 100 одновременных соединений &mdash; 200Mb<br /> памяти. 1000 одновременных соединений &mdash; 2G памяти. Для&nbsp;сайта крупной компании<br /> или&nbsp;для хостинга это&nbsp;очень большая проблема. А&nbsp;также это&nbsp;может стать крупной<br /> проблемой для&nbsp;любого сайта после лёгенькой <span class="missingpage">Do&nbsp;S</span><a href="http://freesource.info/wiki/DoS/edit?add=1&" title="Создать эту страницу">?</a>-атаки.<br /> Вся&nbsp;удивительная функциональность Apache достигается за&nbsp;счёт модульной<br /> архитектуры. Все&nbsp;модули бинарные, поэтому ошибка в&nbsp;любом из&nbsp;модулей приводит...<br /> Да, к&nbsp;чему угодно в&nbsp;рамках конкретной дочки Apache. Опять же, слава богу, ввиду<br /> отлаженности большинства модулей это&nbsp;обычно не&nbsp;слишком важно. Но&nbsp;всё-таки<br /> существенно, ибо&nbsp;ошибка, например, в&nbsp;mod_ssl (что уже&nbsp;бывало) предоставляет<br /> доступ ко&nbsp;всем обслуживаемым ресурсам. С&nbsp;учётом роста возможностей, а&nbsp;также<br /> массы внешних расширений, написаных сторонними разработчиками (например самое<br /> распространённое такое расширение &mdash; mod_php) удерживать в&nbsp;полной безопаности<br /> такую систему становится сложно. Полноценного механизма разделения привелегий<br /> пока так&nbsp;и&nbsp;нет.<br /> Ну&nbsp;и самое неприятное, портабельность вынуждает реализовывать не&nbsp;самую<br /> эффективную архитектуру, а&nbsp;самую универсальную. А&nbsp;разница между оптимальными<br /> подходами в&nbsp;Windows и&nbsp;UNIX-like ОС&nbsp;огромна.<br /> Основной режим работе серверов (особенно в&nbsp;России, где&nbsp;больше всего подключений<br /> низкоскоростные) выглядит следующим образом:<br /> Результат &mdash; дочка Apache, размером в&nbsp;20Mb висит в&nbsp;памяти большую часть времени<br /> лишь для&nbsp;того, чтобы отдать пользователю запрос размером в&nbsp;<span class="nobr">5&ndash;20</span>Kb. До<br /> очарования идиотичная трата такого дорогостоящего ресурса, как&nbsp;память (которая<br /> чаще всего становится в&nbsp;серверах &laquo;бутылочным горлышком&raquo;).<br /> Ясен пень, что&nbsp;администраторы (как и&nbsp;их руководство) не&nbsp;шибко любят тратить<br /> ресурсы сервера впустую. Поэтому (ну не&nbsp;только поэтому, конечно) было<br /> изоберетно такое гениальное средство как&nbsp;&#8220;reverse proxy&#8221;. Идея проста &mdash; пусть<br /> средство, предназначеное для&nbsp;быстрой передачи данных клиенту этим и&nbsp;занимается,<br /> а&nbsp;Apache просто подготавливает данные для&nbsp;отправки пользователю. Результат --<br /> экономия памяти и&nbsp;увеличение производительности. А&nbsp;если ещё авторы скриптов<br /> озаботились столь корректным их&nbsp;написанием, что&nbsp;прокси могут по&nbsp;возможности<br /> кэшировать их&nbsp;вывод, то&nbsp;экономия становится ещё более ощутимой.<br /> Кроме того этот подход ещё и&nbsp;снижает нагрузку на&nbsp;базы данных, уменьшая<br /> количество одновременных запросов. Ещё один плюс такой технологии ускорения.<br /> Ещё одна неприятность Apache &mdash; большие накладные расходы при&nbsp;передаче чисто<br /> статических данных. Обычно на&nbsp;одну генерируемую страницу приходится огромное<br /> количество изображений, которые в&nbsp;основном являются статическими данными, а&nbsp;не<br /> генерируются при&nbsp;каждом обращении (за исключением, разве что, счётчиков). Тут<br /> функциональность Apache играет против него.<br /> Есть и&nbsp;ещё один важный момент. В&nbsp;Linux, особенно начиная с&nbsp;ядра 2.6, имеется<br /> масса усовершенствований для&nbsp;быстрой передачи по&nbsp;сети большим количеством<br /> одновременных потоков из&nbsp;<u>однопоточного</u> приложения. Apache не&nbsp;может<br /> воспользоваться большей частью этих усовершенствований.<br /> Результат: nginx выдерживает на&nbsp;раздаче статического контента нагрузку по<br /> одновременному количеству соединений более чем&nbsp;в&nbsp;100 раз&nbsp;большую.<br /> Многие помнят почему всеми так&nbsp;любим mod_php. Любими он&nbsp;просто потому, что<br /> модуль, естественно быстрее чем&nbsp;вызывать интерпретатор каждый раз&nbsp;при обращении<br /> к&nbsp;скрипту (как это&nbsp;происходит в&nbsp;случае с&nbsp;CGI). В&nbsp;результате mod_php многократно<br /> выигрывает по&nbsp;скорости как&nbsp;у&nbsp;CLI php, так&nbsp;и&nbsp;у perl (не считая mod_perl,<br /> разумеется, но&nbsp;это отдельная долгая печальная история, почему большинство<br /> хостеров эту&nbsp;чудесную для&nbsp;программиста возможность предоставляют крайне редко).<br /> Так&nbsp;вот, Fast CGI&nbsp;даёт те&nbsp;же самые возможности и&nbsp;даже больше. В&nbsp;этом он&nbsp;ближе к<br /> mod_perl. Суть Fast CGI&nbsp;&mdash; скрипт вызывается <u>один раз</u>, а&nbsp;потом ему<br /> передаются запросы и&nbsp;забираются ответы. Это&nbsp;требует более внимательного<br /> программирования, однако даёт потрясающие возможности, такие как&nbsp;кэширование<br /> некоторых данных между сессиями, чего нет&nbsp;у&nbsp;mod_php (и что&nbsp;и&nbsp;даёт такое<br /> потрясающее преимущество по&nbsp;производительности хорошо написаным mod_perl<br /> скриптам).<br /> Резюме: существование Fast CGI&nbsp;и&nbsp;поддержка его&nbsp;многими специализироваными<br /> &laquo;быстрыми&raquo; браузерами делает несущественной наличии mod_php. А&nbsp;тот факт, что<br /> php&nbsp;можно собрать и&nbsp;в виде fastcgi версии убивает одно из&nbsp;самых главных мнимых<br /> преимуществ Apache &mdash; то, что&nbsp;под него, якобы, заточек PHP.<br /> <ul><li> формирует очередь из&nbsp;небольшого количества параллельных запросов, <div class="indent">которые будут отданы серверу приложений</div></li></ul> 2-я линия это&nbsp;сервер приложений, любой http-сервер поддерживающий fastcgi. В<br /> случае наличия нескольких разных сервисов даже на&nbsp;одном сайте разумно запустить<br /> их&nbsp;под разными серверами &mdash; паранойя лучший друг системного администратора.<br /> Этим сервером, кстати, вполне может быть и&nbsp;старый добрый Apache, если вы&nbsp;к нему<br /> привыкли, или&nbsp;если есть какие-то специфические приложения. Но&nbsp;лучше заменить<br /> его&nbsp;чем-нибудь гораздо более лёгким.<br /> 3-я линия это, как&nbsp;обычно, <span class="missingpage">My&nbsp;SQL</span><a href="http://freesource.info/wiki/MySQL/edit?add=1&" title="Создать эту страницу">?</a> или&nbsp;<span class="missingpage">Postgre&nbsp;SQL</span><a href="http://freesource.info/wiki/PostgreSQL/edit?add=1&" title="Создать эту страницу">?</a>, в&nbsp;зависимости от&nbsp;особенностей<br /> данного проекта и&nbsp;его моделей данных. Во&nbsp;многих случаях также может <br /> отсутствовать, будучи заменённым на&nbsp;встраиваемый движок баз&nbsp;данных sqlite <br /> (<a href="http://www.sqlite.ru)" target="_blank" title="Внешняя ссылка (откроется в новом окне)" class="outerlink"><img src="http://freesource.info/wiki/themes/coffee/icons/web.gif" alt="" border="0" />http://www.sqlite.ru)</a>. <br /> На&nbsp;крупном портале, или&nbsp;хостинг-сервисе имеет смысл первую линию разбить на<br /> несколько этпаов, выполняющихся на&nbsp;разных серверах, а&nbsp;также добавить кэширующий<br /> прокси-сервер, который бы&nbsp;держал все&nbsp;данные в&nbsp;памяти. <br /> Описаные выше идеи далеко не&nbsp;новы, и&nbsp;известны многим специалистам. Увы, подход<br /> LAMP (Linux Apache <span class="missingpage">My&nbsp;SQL</span><a href="http://freesource.info/wiki/MySQL/edit?add=1&" title="Создать эту страницу">?</a> PHP) настолько вселился в&nbsp;души современных<br /> web-разработчиков, что&nbsp;они часто даже не&nbsp;задумываются о&nbsp;наличии альтернативных<br /> решений, более эффективных чем&nbsp;известные им&nbsp;сейчас.<br /> Эта&nbsp;статья будет постоянно дорабатываться и&nbsp;корректироваться у&nbsp;меня на&nbsp;сайте,<br /> ибо&nbsp;тема эта&nbsp;неисчерпаема, и&nbsp;подлежит ещё долгому и&nbsp;ценному (я надеюсь)<br /> обсуждению.<br /> 3. или, то&nbsp;же самое другими словами &mdash; правильная настройка системы гораздо<br /> важнее крутизны вашего сервера :)</div></div>