In <11a501bf6d4a$9a5e1dd0$0743d1c3@ssu.samara.ru> BeerBong (alexei@samara.net)
wrote:
>> Обычно полезно сначала добиться того, чтобы все работало, а уж затем
>> оптимизитровать...
B> Да все работает прекрасно, потребность в ssl появилась после. Ну и возникло
B> желание что-нить пооптимизировать :)
Не то, что это плохое желание само по себе -- просто нужно всегда соотносить
возможный выигрыш и проигрыш...
>>
>> B> Все идеи изложенные мною выше конечно не я придумал, а прочитал на
>> B> perl.apache.org/guide - где собсно и рассказывается про разные Апачи. Про
>> B> расшаренный код mod_perl скриптов это понятно, это можно на back-end
>сервере
>> B> грузить их лоадером. Не хочу разводить флейм про это, раз уж это
>обсуждалось
>> B> 10 раз. Где можно почитать про сравнение этих моделей ? Или как вообще
>> B> настроить Apache для большого кол-ва пользователей и чтобы mod_perl
>> B> использовался ?
>>
>> Поставить побольше памяти :-) Вообще при современных ценах на пямять все эти
>> штучками с двумя Apache'ами и т.п. стоит занимать тогда, когда понятно -- что
>> это даст.
B> Да и понятно, легкие Апачи потихоньку отдают тормозным клиентам данные,
B> кол-во mod_perl Apache не большое, коннектов к Oracle соответственно тоже не
B> много (2-5 штук, а коннект к Ораклу занимает немалое время, так как не на
B> локальной машине, и памяти - хотя память наверное опять же половина
B> расшаренная :)) и мне совсем не хочется их плодить для каждого пользователя
B> даже с использованием Apache::DBI.
О. Oracle. Oracle -- это ВЕЩЬ. У него ОЧЕНЬ тяжелые клиенты (да и сам он не
шибко легкий :-), так что в этом случае это вполне может быть оправдано.
Таки память наполовину расшаренная, но и того, что не расшарено тоже изрядно
набирается...
=============================================================================
= Apache-Talk@lists.lexa.ru mailing list =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
= Archive avaliable at =
