The OpenNET Project / Index page

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

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

15.12.2004 22:28

Описание способов построения эффективных Web-серверов без использования сервера Apache. Рассматривается вариант замены apache + mod_php на nginx, mathopd, lighttpd и т.д. + php под FastCGI.

  1. Главная ссылка к новости (http://freesource.info/wiki/An...)
Лицензия: CC-BY
Тип: яз. русский / яз. русский
Короткая ссылка: https://opennet.ru/4792-apache
Ключевые слова: apache, php
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (24) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 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.6, Аноним (-), 10:11, 16/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    s/увеличиться/увеличится/
     
  • 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.10, pazke (?), 15:11, 16/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    Видимо здесь:

    man epoll
    man sendfile

     

  • 1.9, Shaman007 (?), 11:24, 16/12/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Еще один неграмотный опус ни о чем.
     
     
  • 2.12, scum (??), 13:55, 17/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Еще один неграмотный опус ни о чем.

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

     
     
  • 3.16, mithraen (?), 19:23, 17/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    Прикольная характеристика Да, это классическая архитектура Вернее одна из клас... большой текст свёрнут, показать
     
     
  • 4.17, chip (ok), 21:53, 17/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >Конкретно начиная с 2.6 у нас есть epoll, например.

    http://www.freebsd.org/cgi/man.cgi?query=kqueue&apropos=0&sektion=0&manpath=F

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

    http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=0&manpath
    http://www.freebsd.org/cgi/man.cgi?query=writev&apropos=0&sektion=0&manpath=F

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

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

    http://www.freebsd.org/cgi/man.cgi?query=aio&apropos=0&sektion=0&manpath=Free

     
     
  • 5.20, Dim (??), 05:10, 18/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >> А ещё, начиная
    >>с ядра 2.2 (или даже 2.0?) у нас есть sendfile.
    >
    >http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=0&manpath

    По поводу sendfile мимо. Правильно здесь:
    http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=2&manpath

     
     
  • 6.21, chip (ok), 10:31, 18/12/2004 [^] [^^] [^^^] [ответить]  
  • +/
    >По поводу sendfile мимо. Правильно здесь:
    >http://www.freebsd.org/cgi/man.cgi?query=sendfile&apropos=0&sektion=2&manpath

    согласен.

     

  • 1.11, Крититк (?), 13:54, 17/12/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Согласен. Статья от фонаря. Типа: пришел увидел, нацарапал.
     
  • 1.19, llelik (?), 00:01, 18/12/2004 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    2 Shaman007
    Будь добр в таком тоне выражать свое мнение на лоре, там тебя больше любят
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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