The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Обзор недостатков Apache и поиск альтернатив."
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Обзор недостатков Apache и поиск альтернатив."
Сообщение от opennews (ok) on 16-Дек-04, 01:07 
Описание способов построения эффективных Web-серверов без использования сервера Apache. Рассматривается вариант замены apache + mod_php на nginx, mathopd, lighttpd и т.д. + php под FastCGI.

URL: http://freesource.info/wiki/Anti_Apache
Новость: https://www.opennet.ru/opennews/art.shtml?num=4792

Cообщить модератору | Наверх | ^

 Оглавление

Сообщения по теме [Сортировка по времени, UBB]


1. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Maxim Chirkov email(ok) on 16-Дек-04, 01:07 
> Каждая копия 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 тысячах.


Cообщить модератору | Наверх | ^

4. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним on 16-Дек-04, 07:15 
Unix версия 1.х использует fork, при этом не происходит полного копирования процесса, копируются только те страницы памяти в которые производилась запись, "которые стали различаться между родителем и ребенком". Потребление памяти при этом незначительное.

Более важно правильно организовать обработку запросов.

Cообщить модератору | Наверх | ^

13. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от mithraen on 17-Дек-04, 19:01 
Если бы всё было так хорошо. На самом деле всё гораздо грустнее.

Сам апача не такой уж прожорливый. Но тот же mod_php, ясен пень, уже при запуске инициализирует часть своих структур данных. 20Mb это была ошибка, признаю. Но сути это не меняет. fork спасает только касаемо статических данных, увы, в процессе работы дочка вынуждена несколько мегабайт реальной памяти себе забрать.

Все эти новомодные Web-серверы борются с этим тем, что обрабатывают сотни клиентов одновременно в каждой дочке.

Cообщить модератору | Наверх | ^

14. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от mithraen on 17-Дек-04, 19:06 
>PS. У нас есть один клиент, у которого в средмем около _600_
>запросов к MySQL из одного вызова php-скрипта. Я вначале думал, что
>статистика глючит, а нет, у него в скрипте на каждый чих
>по несколько SELECT'ов :-(

А это уже без шансов. Жизнь хостера не так сладка :-( А когда количество посетителей на таком сайте становится действительно большим, начинается песня.

Мне периодически приходится самому индексы создавать. Товарищи "веб-разработчики на PHP", увы, часто этого элементарно не умеют.

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

Да, mod_ssl очень часто штука обязательная. mod_perl я практически никому не даю использовать именно по этой самой причине его прожорливости. memory_limit метров 8 ставить приходится, меньше разработчики матерятся.

Cообщить модератору | Наверх | ^

18. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Maxim Chirkov email(ok) on 17-Дек-04, 22:20 
>Да, mod_ssl очень часто штука обязательная.

Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его использования :-(

>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>ставить приходится, меньше разработчики матерятся.

У меня лимит в 2Мб, и то я, напирмер, себе не могу представить, чем и как можно их забить при простой единовременной выборке, допустим, скрипта с форумом, при размере данных в базе 50 Кб. 2 Мб - это почти 450 тыс. слов, 200 страниц текста.

Cообщить модератору | Наверх | ^

22. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним email on 18-Дек-04, 20:54 
Вы даже не представляете, какие бывают странные вебмастера... Ужас.
Cообщить модератору | Наверх | ^

23. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Денис Смирнов email on 22-Дек-04, 00:10 
>>Да, mod_ssl очень часто штука обязательная.
>Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его
>использования :-(

В Apache тоже баги находили :) А на базе openssl у нас ещё и ssh. Будем от него отказываться? ;-)

А реализация крива, без вопросов.

>>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>>ставить приходится, меньше разработчики матерятся.
>У меня лимит в 2Мб, и то я, напирмер, себе не могу
>представить, чем и как можно их забить при простой единовременной выборке,
>допустим, скрипта с форумом, при размере данных в базе 50 Кб.
>2 Мб - это почти 450 тыс. слов, 200 страниц текста.

Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну например, xml, отправлять админу (типа для backup'а). Или вообще вызывать mysqldump из PHP (!) и результат отправлять. Были у меня такие "пользователи", блин.

Во-вторых можно вообще не знать про то, что у SELECT есть выбор запрашиваемых полей, а также поддиректива WHERE. И делать "SELECT * FROM table" всегда и везде. Потом фильтровать в PHP, якобы "так проще".

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

Cообщить модератору | Наверх | ^

24. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Maxim Chirkov email(ok) on 22-Дек-04, 10:00 
>В Apache тоже баги находили :) А на базе openssl у нас
>ещё и ssh. Будем от него отказываться? ;-)

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

Что касается apache 1.3.x, то критическая уязвимость в нем была обнаружена один раз (после этого он у меня только в chroot живет с запрещением коннектов во вне). В mod_ssl дыры сводящие на нет его эффективность появляются регулярно, плюс хвост в виде openssl.

>Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну

У меня пример был для базы с 50Кб данных :-) Там нужно 500 полных select'ов  сделать.

Cообщить модератору | Наверх | ^

2. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним email on 16-Дек-04, 01:23 
> Я вначале думал, что статистика глючит, а нет, у
> него в скрипте на каждый чих по несколько
> SELECT'ов :-(

И как, благородные доны, от этого обычно избавляются?

Cообщить модератору | Наверх | ^

3. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от rippy (??) on 16-Дек-04, 01:43 
Если разработчик вне зоны контроля - практически никак :( А вообще:
- Максимально оптимизировать и апач, и базу (как правило в подобных клинических случаях не спасает)
- Попытаться связаться с разработчиком и намекнуть ему на неаккуратность (как правило - безнадега)
- Попытаться договориться с клиентом и объяснить ему суть проблемы, с тем, чтобы он пинал разработчика (тоже обычно мало шансов, хотя это близкий к идеальному вариант, если получится)
- Если ты в состоянии разобраться в коде - попытаться договорится с клиентом о том, чтобы он позволил тебе поправить код (хотя частенько это "исправление" доходит до состояния "полного переписывания")
- Объяснить клиенту, что в данной ситуации (объем базы * кол-во запросов * "специфика веб-приложения") необходимо значительно нарастить мощности компьютера (К этому совету, как ни странно, клиенты нередко прислушиваются, хотя "клинику" и он не сильно спасает...)
Cообщить модератору | Наверх | ^

5. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним on 16-Дек-04, 10:10 
Нет, я имел в виду, про select'ы.
Чтобы уменьшить их использование, предлагается кэшировать?
Так от этого тоже же процесс в размере увеличиться?
Cообщить модератору | Наверх | ^

6. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним on 16-Дек-04, 10:11 
s/увеличиться/увеличится/
Cообщить модератору | Наверх | ^

15. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от mithraen on 17-Дек-04, 19:16 
>Нет, я имел в виду, про select'ы.
>Чтобы уменьшить их использование, предлагается кэшировать?
>Так от этого тоже же процесс в размере увеличиться?

Чаще всего надо просто логику программы переделывать.
А кое-где, действительно, полезно бывает и кэшировать. memcache рулит. mod_perl тоже. Ну и FastCGI не отстаёт :)

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

Cообщить модератору | Наверх | ^

7. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним email on 16-Дек-04, 11:12 
Кто нибудь тестировал / сравнивал lighttpd +fast cgi php и апач, mathopd на таких тяжеловатых приложениях как SquirrelMail
У меня на простых php запросах выигрыш по загрузке процессора ошутимее в пользу lighttpd . Но при uploade файлов на сервер  при прикреплении к письму вложения . lighttpd  сильнее (раза в 2 )грузит процессор чем все остальные .
все тестировалось на Freebsd  5.2
lighttpd-1.3.2
mathopd-1.5p2
apach 1.x
Cообщить модератору | Наверх | ^

8. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Аноним email on 16-Дек-04, 11:18 
>Есть и ещё один важный момент. В Linux, особенно >начиная с ядра 2.6, имеется масса >усовершенствований для быстрой передачи по сети >большим количеством одновременных потоков из >однопоточного приложения. Apache не может >воспользоваться большей частью этих >усовершенствований.
Интересует что за усовершенствования? Где про это почитать?
Cообщить модератору | Наверх | ^

10. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от pazke email on 16-Дек-04, 15:11 
Видимо здесь:

man epoll
man sendfile

Cообщить модератору | Наверх | ^

9. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Shaman007 on 16-Дек-04, 11:24 
Еще один неграмотный опус ни о чем.
Cообщить модератору | Наверх | ^

12. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от scum email(??) on 17-Дек-04, 13:55 
>Еще один неграмотный опус ни о чем.

Согласен, вроде автор - грамотный человек, но чаще всего полную ахинею несет. Чего стоит только: "В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache". Так то же классическая архитектура. Да и не является "дочка" копией, неправда это.
Или вот еще: "Все модули бинарные, поэтому ошибка в любом из модулей приводит... Да, к чему угодно в рамках конкретной дочки Apache." А что, если модули "не бинарные" - в них ошибок никогда не бывает? Да и что за зверь такой, "не бинарные" модули, хотелось бы узнать? Но особенно меня заинтересовала фраза "В Linux, особенно начиная с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети большим количеством одновременных потоков из однопоточного приложения". Господа, объясните мне пожалуйста, что автор хотел этим сказать? Я лично не понял. Это что это за пупер-дупер новейшие сетевые технологии, позволяющие передавать данные по сети аж в несколько потоков? Правда что ли? Сегодня ведь не первое апреля, вроде бы.

Cообщить модератору | Наверх | ^

16. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от mithraen on 17-Дек-04, 19:23 
>Согласен, вроде автор - грамотный человек, но чаще всего полную ахинею несет.

Прикольная характеристика.

>Чего стоит только: "В 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 в ядре.

Cообщить модератору | Наверх | ^

17. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от chip email(ok) on 17-Дек-04, 21:53 
>Конкретно начиная с 2.6 у нас есть epoll, например.

http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

> А ещё, начиная
>с ядра 2.2 (или даже 2.0?) у нас есть sendfile.

http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html
http://www.freebsd.org/cgi/man.cgi?query=writev&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

> Правильное
>использование которого оч-ч-чень, знаете ли, процессорное время экономит. А ещё у
>нас есть начиная с 2.6 aio в ядре.

а нас в квартире газ, а у Вас?

http://www.freebsd.org/cgi/man.cgi?query=aio&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

Cообщить модератору | Наверх | ^

20. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Dim (??) on 18-Дек-04, 05:10 
>> А ещё, начиная
>>с ядра 2.2 (или даже 2.0?) у нас есть sendfile.
>
>http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=0&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

По поводу sendfile мимо. Правильно здесь:
http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=2&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

Cообщить модератору | Наверх | ^

21. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от chip email(ok) on 18-Дек-04, 10:31 
>По поводу sendfile мимо. Правильно здесь:
>http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=2&manpath=FreeBSD+5.3-RELEASE+and+Ports&format=html

согласен.

Cообщить модератору | Наверх | ^

11. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от Крититк email on 17-Дек-04, 13:54 
Согласен. Статья от фонаря. Типа: пришел увидел, нацарапал.
Cообщить модератору | Наверх | ^

19. "Обзор недостатков Apache и поиск альтернатив."
Сообщение от llelik email on 18-Дек-04, 00:01 
2 Shaman007
Будь добр в таком тоне выражать свое мнение на лоре, там тебя больше любят
Cообщить модератору | Наверх | ^

Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2020 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру