форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Архивированная нить - только для чтения!  Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (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 (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 (ok) on 17-Дек-04, 22:20
	>Да, mod_ssl очень часто штука обязательная. Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его использования :-( >использовать именно по этой самой причине его прожорливости. memory_limit метров 8 >ставить приходится, меньше разработчики матерятся. У меня лимит в 2Мб, и то я, напирмер, себе не могу представить, чем и как можно их забить при простой единовременной выборке, допустим, скрипта с форумом, при размере данных в базе 50 Кб. 2 Мб - это почти 450 тыс. слов, 200 страниц текста.
	Cообщить модератору | Наверх | ^

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

	23. "Обзор недостатков Apache и поиск альтернатив."
	Сообщение от Денис Смирнов 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 (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 и поиск альтернатив."

Сообщение от Аноним 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 и поиск альтернатив."

Сообщение от Аноним 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 и поиск альтернатив."

Сообщение от Аноним on 16-Дек-04, 11:18

>Есть и ещё один важный момент. В Linux, особенно >начиная с ядра 2.6, имеется масса >усовершенствований для быстрой передачи по сети >большим количеством одновременных потоков из >однопоточного приложения. Apache не может >воспользоваться большей частью этих >усовершенствований. Интересует что за усовершенствования? Где про это почитать?

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

	10. "Обзор недостатков Apache и поиск альтернатив."
	Сообщение от pazke on 16-Дек-04, 15:11
	Видимо здесь: man epoll man sendfile
	Cообщить модератору | Наверх | ^

9. "Обзор недостатков Apache и поиск альтернатив."

Сообщение от Shaman007 on 16-Дек-04, 11:24

Еще один неграмотный опус ни о чем.

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

	12. "Обзор недостатков Apache и поиск альтернатив."
	Сообщение от scum (??) 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 (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 (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 и поиск альтернатив."

Сообщение от Крититк on 17-Дек-04, 13:54

Согласен. Статья от фонаря. Типа: пришел увидел, нацарапал.

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

19. "Обзор недостатков Apache и поиск альтернатив."

Сообщение от llelik on 18-Дек-04, 00:01

2 Shaman007 Будь добр в таком тоне выражать свое мнение на лоре, там тебя больше любят

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

Удалить

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