| 1.1, Maxim Chirkov (ok), 01:07, 16/12/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 > Каждая копия 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 тысячах.
| | |
| |
| 2.4, Аноним (-), 07:15, 16/12/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Unix версия 1.х использует fork, при этом не происходит полного копирования процесса, копируются только те страницы памяти в которые производилась запись, "которые стали различаться между родителем и ребенком". Потребление памяти при этом незначительное.
Более важно правильно организовать обработку запросов.
| | |
| 2.13, mithraen (?), 19:01, 17/12/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Если бы всё было так хорошо. На самом деле всё гораздо грустнее.
Сам апача не такой уж прожорливый. Но тот же mod_php, ясен пень, уже при запуске инициализирует часть своих структур данных. 20Mb это была ошибка, признаю. Но сути это не меняет. fork спасает только касаемо статических данных, увы, в процессе работы дочка вынуждена несколько мегабайт реальной памяти себе забрать.
Все эти новомодные Web-серверы борются с этим тем, что обрабатывают сотни клиентов одновременно в каждой дочке.
| | |
| 2.14, mithraen (?), 19:06, 17/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
>PS. У нас есть один клиент, у которого в средмем около _600_
>запросов к MySQL из одного вызова php-скрипта. Я вначале думал, что
>статистика глючит, а нет, у него в скрипте на каждый чих
>по несколько SELECT'ов :-(
А это уже без шансов. Жизнь хостера не так сладка :-( А когда количество посетителей на таком сайте становится действительно большим, начинается песня.
Мне периодически приходится самому индексы создавать. Товарищи "веб-разработчики на PHP", увы, часто этого элементарно не умеют.
Но, слава богу, бывают более приятные задачи -- когда все квалифицированы, но ресурсов как ни крути, всё равно мало.
Да, mod_ssl очень часто штука обязательная. mod_perl я практически никому не даю использовать именно по этой самой причине его прожорливости. memory_limit метров 8 ставить приходится, меньше разработчики матерятся. | | |
| |
| 3.18, Maxim Chirkov (ok), 22:20, 17/12/2004 [^] [^^] [^^^] [ответить]
| +/– | |
>Да, mod_ssl очень часто штука обязательная.
Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его использования :-(
>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>ставить приходится, меньше разработчики матерятся.
У меня лимит в 2Мб, и то я, напирмер, себе не могу представить, чем и как можно их забить при простой единовременной выборке, допустим, скрипта с форумом, при размере данных в базе 50 Кб. 2 Мб - это почти 450 тыс. слов, 200 страниц текста.
| | |
| |
| 4.22, Аноним (22), 20:54, 18/12/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Вы даже не представляете, какие бывают странные вебмастера... Ужас. | | |
| 4.23, Денис Смирнов (?), 00:10, 22/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
 >>Да, mod_ssl очень часто штука обязательная.
>Потенциальная дырявость его реализации и OpenSSL сводит на нет все преимущества его
>использования :-(
В Apache тоже баги находили :) А на базе openssl у нас ещё и ssh. Будем от него отказываться? ;-)
А реализация крива, без вопросов.
>>использовать именно по этой самой причине его прожорливости. memory_limit метров 8
>>ставить приходится, меньше разработчики матерятся.
>У меня лимит в 2Мб, и то я, напирмер, себе не могу
>представить, чем и как можно их забить при простой единовременной выборке,
>допустим, скрипта с форумом, при размере данных в базе 50 Кб.
>2 Мб - это почти 450 тыс. слов, 200 страниц текста.
Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну например, xml, отправлять админу (типа для backup'а). Или вообще вызывать mysqldump из PHP (!) и результат отправлять. Были у меня такие "пользователи", блин.
Во-вторых можно вообще не знать про то, что у SELECT есть выбор запрашиваемых полей, а также поддиректива WHERE. И делать "SELECT * FROM table" всегда и везде. Потом фильтровать в PHP, якобы "так проще".
В общем разработчики-ламеры разные бывают. Я с этим сейчас борюсь тем, что расставляю персональные ограничения. Если кто-то начинает вдруг материться что у него что-то там не работает, провожу лично разъяснительную беседу, и, если особо тупой, увеличиваю лимит. | | |
| |
| 5.24, Maxim Chirkov (ok), 10:00, 22/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
>В Apache тоже баги находили :) А на базе openssl у нас
>ещё и ssh. Будем от него отказываться? ;-)
Незнаю как у вас, а у меня доступ к ssh фаерволом открыт только с доверенных хостов.
Есть одна точка входа в доверенную сеть из внешней сети, на экстренный случай, но на нее не так просто попасть и ssh там висит не там где его обычно привыкли видеть.
Что касается apache 1.3.x, то критическая уязвимость в нем была обнаружена один раз (после этого он у меня только в chroot живет с запрещением коннектов во вне). В mod_ssl дыры сводящие на нет его эффективность появляются регулярно, плюс хвост в виде openssl.
>Элементарно! Для начала достаточно пожелать экспорт из базы данных в виде, ну
У меня пример был для базы с 50Кб данных :-) Там нужно 500 полных select'ов сделать.
| | |
|
|
|
|
| 1.2, Аноним (22), 01:23, 16/12/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Я вначале думал, что статистика глючит, а нет, у
> него в скрипте на каждый чих по несколько
> SELECT'ов :-(
И как, благородные доны, от этого обычно избавляются? | | |
| |
| 2.3, rippy (??), 01:43, 16/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
Если разработчик вне зоны контроля - практически никак :( А вообще:
- Максимально оптимизировать и апач, и базу (как правило в подобных клинических случаях не спасает)
- Попытаться связаться с разработчиком и намекнуть ему на неаккуратность (как правило - безнадега)
- Попытаться договориться с клиентом и объяснить ему суть проблемы, с тем, чтобы он пинал разработчика (тоже обычно мало шансов, хотя это близкий к идеальному вариант, если получится)
- Если ты в состоянии разобраться в коде - попытаться договорится с клиентом о том, чтобы он позволил тебе поправить код (хотя частенько это "исправление" доходит до состояния "полного переписывания")
- Объяснить клиенту, что в данной ситуации (объем базы * кол-во запросов * "специфика веб-приложения") необходимо значительно нарастить мощности компьютера (К этому совету, как ни странно, клиенты нередко прислушиваются, хотя "клинику" и он не сильно спасает...)
| | |
| |
| 3.5, Аноним (-), 10:10, 16/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
Нет, я имел в виду, про select'ы.
Чтобы уменьшить их использование, предлагается кэшировать?
Так от этого тоже же процесс в размере увеличиться? | | |
| |
| 4.15, mithraen (?), 19:16, 17/12/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Нет, я имел в виду, про select'ы.
>Чтобы уменьшить их использование, предлагается кэшировать?
>Так от этого тоже же процесс в размере увеличиться?
Чаще всего надо просто логику программы переделывать.
А кое-где, действительно, полезно бывает и кэшировать. memcache рулит. mod_perl тоже. Ну и FastCGI не отстаёт :)
В некоторых случаях, если приложение действительно сложное, стоит подумать о переходе на более функциональную базу данных -- PostgreSQL. | | |
|
|
|
| 1.7, Аноним (7), 11:12, 16/12/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Кто нибудь тестировал / сравнивал lighttpd +fast cgi php и апач, mathopd на таких тяжеловатых приложениях как SquirrelMail
У меня на простых php запросах выигрыш по загрузке процессора ошутимее в пользу lighttpd . Но при uploade файлов на сервер при прикреплении к письму вложения . lighttpd сильнее (раза в 2 )грузит процессор чем все остальные .
все тестировалось на Freebsd 5.2
lighttpd-1.3.2
mathopd-1.5p2
apach 1.x | | |
| 1.8, Аноним (22), 11:18, 16/12/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Есть и ещё один важный момент. В Linux, особенно >начиная с ядра 2.6, имеется масса >усовершенствований для быстрой передачи по сети >большим количеством одновременных потоков из >однопоточного приложения. Apache не может >воспользоваться большей частью этих >усовершенствований.
Интересует что за усовершенствования? Где про это почитать? | | |
| |
| 2.12, scum (??), 13:55, 17/12/2004 [^] [^^] [^^^] [ответить]
| +/– | |
>Еще один неграмотный опус ни о чем.
Согласен, вроде автор - грамотный человек, но чаще всего полную ахинею несет. Чего стоит только: "В 1.3.* каждое параллельной соединение обрабатывается отдельной копией (дочкой) Apache". Так то же классическая архитектура. Да и не является "дочка" копией, неправда это.
Или вот еще: "Все модули бинарные, поэтому ошибка в любом из модулей приводит... Да, к чему угодно в рамках конкретной дочки Apache." А что, если модули "не бинарные" - в них ошибок никогда не бывает? Да и что за зверь такой, "не бинарные" модули, хотелось бы узнать? Но особенно меня заинтересовала фраза "В Linux, особенно начиная с ядра 2.6, имеется масса усовершенствований для быстрой передачи по сети большим количеством одновременных потоков из однопоточного приложения". Господа, объясните мне пожалуйста, что автор хотел этим сказать? Я лично не понял. Это что это за пупер-дупер новейшие сетевые технологии, позволяющие передавать данные по сети аж в несколько потоков? Правда что ли? Сегодня ведь не первое апреля, вроде бы. | | |
| |
| 3.16, mithraen (?), 19:23, 17/12/2004 [^] [^^] [^^^] [ответить] | +/– | Прикольная характеристика Да, это классическая архитектура Вернее одна из клас... большой текст свёрнут, показать | | |
|
|
| 1.19, llelik (?), 00:01, 18/12/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
2 Shaman007
Будь добр в таком тоне выражать свое мнение на лоре, там тебя больше любят | | |
|
