Hello Victor,
понедельник, 5 апреля 1999 г., you wrote:
>> опыту. У меня при интенсивном использовании Perl/SSI размеры
>> соответственно 6000 / 5000 ориентировочно. Я думал, это очень много
>> Ж-)
VBW> Ну, когда у нас будет 20 req/sec поставим туда гиг памяти. Поскольку
VBW> вся крутизна communiware заключается в полном отсутсвии статического
Это, с одной стороны, крутизна, а с другой - слабость. Потому что
логично наиболее часто запрашиваемые варианты делать статическими
(прегенерация) или псевдостатическими (с помощью кэширования).
VBW> На самом деле, все не так страшно. Поскольку 100% перлового кода грузятся
VBW> в папашу и наследуются детишками. В результате страшные цифры SIZE/RSS
VBW> реально хранятся в памяти один раз.
SIZE - да. RSS, AFAIK - нет. У каждого httpd child свои ресурсы.
VBW> Мы тут скорее думаем по поводу вкручивания в mod_perlовый код корректной
VBW> обработки HEAD и If-Modified-Since и постановки squid в режиме ускорения,
Я собираюсь сделать примерно то же самое.
VBW> чтобы уменьшить
VBW> количество дерганья LONG-полей из базы данных. Правда, подозреваю, что при
VBW> 20 запросах в секунду ценность этой системы сильно понизится, поскольку
Если запросы будут сильно дифференцированные - похоже, что да...
VBW> количество народу, желающего туда что-нибудь написать, тоже будет расти
VBW> пропорционально, а следовательно время жизни страниц в кэше будет не
VBW> слишком большим. Причем чем интереснее страница - тем меньше.
С дискуссионными страницами, которые часто обновляются, это вполне
реальная проблема. Но в любом случае, наличие кэша уменьшит количество
запросов к базе данных как минимум на 1 на каждого юзера. При
MaxClients=64 это уже немало Ж-).
Best regards,
Ilya mailto:ilya@zhurnal.ru
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
