ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[apache-talk] Re: =?KOI8-r?B?W2FwYWNoZS10YWxrXSBSZTogW2FwYWNoZS10YWxrXSDuxSDQz87JzcHALg==?=



> > > Например, Squid работает через select(), а Oops на phtreads,
> > > которые на FreeBSD реализованы через poll(). И тот, и другой
> > > вызовы достаточно ресурсоемки при большом числе дескрипторов,
> > > а число большое. Кроме того, операции с диском блокирующие.
> > > Для борьбы с этим в Squid может использоваться async io,
> > > не знаю, насколько успешно.
> > > 
> > > Банальное переписывание УРЛа в Squid'е - это просто overkill -
> > > 4 системных вызова + 2 переключение контекста.
> > Допустим overkill, но тогда, кто сможет справится с нагрузкой в 800 запросов
> > в секунду??! Самому апачу похоже это не под силу... потому-что 500 апачей по
> 
> 800 запросов одновременно или 800 запросов в секунду ? Это разные вещи.
> Примерно раз в пять. То есть, 800 запросов одновременно - это 160 запросов
> в секунду. А 800 запросов в секунду - это 4000 запросов одновременно.
Допустим, существует сайт с кучей маленьких картинок, штук 70 на странице...
может даже больше. Таких страниц порядка 100-200. Посещаемость примерно 5000
человек в день, может даже больше. И как нам всем известно, большенство
пользователей юзают IE, который тянет сразу несколькоми стволами. Тобишь
приходиться порождать новые и новые чилды. У меня предел был 450, когда я
успел сказать одну команду killall httpd :)) Перед тем как сервак умер. 


> 
> Я пока таких нагрузок на одной машине не видел.
может это конечно и приувелечение %))

> 

> > 2 метра укладут тачку насмерть, а один squid на 50 метров - это приемлимо.
> > Пускай он даже делает больше обращений к диску и увеличивает нагрузку на
> > проц. Это решение все равно приемлимо.
> 
> 800 запросов одновременно для сквида это означает, что в
> селекте будет 1600 дескрипторов.
> 
> Что касается апачи, то у него из 2М шарится что-то около 1.2М, поэтому 
> 0.8 * 500 = 400M физической памяти, а 0.8 * 800 = 640M.
у меня пока 256. Но теперь понятно, что памяти то нам и не хватало. 


> 
> Вообще же такие вещи хорошо бы разносить на несколько тачек.
дык сервер то один. И на хорошем канале 20 мегабит.

 
> > > Squid и Oops нельзя использовать для отдачи статики или SSI.
> > Почему?! Может первоначально они писались как каэширующие прокси-серверы,
> > но почему нельзя их применять как фронтэнд для апача??!
> 
> Можно, но только как фронт-энд. Как ты в них сделаешь SSI ?

А зачем смешивать фронт-энд с бэк-эндом?! Все cgi, ssi и так далее, что
требует вмешательство апача пускай занимается апач на бэк-эенде, а если это
статика, то пускай занимается фронтэнд. Я так думаю, таков принцып работы
акселератора. Тобишь, каждый элемент этой свзяки (фронт-энд + бэк-энд)
выполняет строго свою задачу.

> 
> > > В случае mod_accel имеются все прелести Apache с его же недостатками.
> > А можно вкратце узнать, что за прелести?:) Может это то, о чем так долго
> > говорили большевеки??:)
> 
> Ну использование любых модулей апачи на фронтэнде.
ясно.  Спасибо.


-- 

     ("`-''-/").___..--''"`-._                     With best regards,
      `o_ o  )   `-.  (     ).`-.__.`)             Andrew Stroganow
      (_Y_.)'  ._   )  `._ `. ``-..-'              E-mail:worm@is.com.ua
    _..`--'_..-_/  /--'_.' .'                      ICQ #UIN:15606140
   (il).-''  (li).'  ((!.-'                        AAS79-RIPE


Lets kill this fuckin' band... 
=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.