php - кеширование шаблонов и прочих данных

0

2

На данный момент программирую на perl + fastcgi. В результате, каждая копия процесса держит в себе кучу разобранных html-шаблонов, какие-то куски кеша и прочего, что мне не очень нравится. Доходит до RSZ=50-100Mb, так что данная ветка развития мне кажется тупиковой - на каждый сайт много процессов и много памяти, а если делать «условно-единый» сервер приложений, то просто «много памяти» и проблемы с безопасностью.

Интересуют советы и мысли на эту тему, как это делается на других языках-платформах.

Ссылка

←	хостинг, python/ruby/perl

Node.JS падает при разрыве соединения со стороны клиента

→

в своих приложениях на питон использую beaker

yanka ★★
(23.11.10 10:29:49 MSK)

Ссылка

На некоторых языках/платформах fastcgi процесс выжирает 256Mb за 50 запросов и ничего как-то живут и работают, по миллиону страниц в день показывают.

P.S. А старые данные из кеша выкидывать пробовал?

~~baverman~~ ★★★
(23.11.10 10:30:15 MSK)

Ответ на: комментарий от baverman 23.11.10 10:30:15 MSK

тут вопрос в том что если на сервере только один высоконагруженный сайт, то и хрен с ним. запихнули лишнюю планку памяти и пусть себе тарахтит. а вот если 200 слабо нагруженных сайтов то начинается что-то весёлое.

vahvarh ★★★
(23.11.10 10:32:08 MSK) автор топика

Ответ на: комментарий от vahvarh 23.11.10 10:32:08 MSK

а вот если 200 слабо нагруженных сайтов то начинается что-то весёлое.

Нашел проблему, memory_limit в пхп для этого и придумали или ulimit.

~~baverman~~ ★★★
(23.11.10 10:52:50 MSK)

Ответ на: комментарий от baverman 23.11.10 10:52:50 MSK

Или fcgi диспатчер отстреливает слишком наглые процессы.

~~baverman~~ ★★★
(23.11.10 10:54:32 MSK)

Ответ на: комментарий от baverman 23.11.10 10:54:32 MSK

тебе не кажется что это несколько костыли

vahvarh ★★★
(23.11.10 10:56:16 MSK) автор топика

Ответ на: комментарий от vahvarh 23.11.10 10:56:16 MSK

тебе не кажется что это несколько костыли

Костыль — ненадежное решение, работающее при определенных условиях, смена которых ведет к поломке костыля.

А отстрел жрущих процессов, после того как они завершили обработку запроса это дешево и сердито.

~~baverman~~ ★★★
(23.11.10 10:59:46 MSK)

Ссылка

Не знаю как с перлом, но mod_python на большом количестве сайтов давал хорошую выгоду в памяти в противовес fastcgi.

pi11 ★★★★★
(23.11.10 18:42:25 MSK)

Ответ на: комментарий от pi11 23.11.10 18:42:25 MSK

>но mod_python на большом количестве сайтов давал хорошую выгоду в памяти в противовес fastcgi.

mod_python уже умер давно. Есть mod_wsgi.

anonymous
(23.11.10 19:23:05 MSK)

Ответ на: комментарий от anonymous 23.11.10 19:23:05 MSK

Ну не умер. Я правда на новых проектах его нигде не использую, а старые крутятся отлично. Менять пока не собираюсь.

nginx + uwsgi хорошо себя показал. По поводу сравнению памяти здесь точно сказать не могу, т.к. замеров не делал, но по ощущениям памяти меньше ест чем fastcgi.

pi11 ★★★★★
(23.11.10 20:01:02 MSK)