> > > Например, 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@xxxxxxxxx
_..`--'_..-_/ /--'_.' .' ICQ #UIN:15606140
(il).-'' (li).' ((!.-' AAS79-RIPE
Lets kill this fuckin' band...
=============================================================================
= Apache-Talk@xxxxxxxxxxxxx mailing list =
Mail "unsubscribe apache-talk" to majordomo@xxxxxxxxxxxxx if you want to quit.
= Archive avaliable at http://www.lexa.ru/apache-talk =
"Russian Apache" includes software developed
by the Apache Group for use in the Apache HTTP server project
(http://www.apache.org/) See
Apache LICENSE.
Copyright (C) 1995-2001 The Apache Group. All rights reserved.
Copyright (C) 1996 Dm. Kryukov; Copyright (C)
1997-2009 Alex Tutubalin. Design (C) 1998 Max Smolev.