1.1, BOLK (?), 10:19, 01/10/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Memcached не нужен на localhost, учите другие способы доступа к разделяемой памяти.
| |
1.2, EugeneVC (?), 12:44, 01/10/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Согласен. Но memcached стандартное решение. Применить его можно быстро и не затратно. А использование shm_open функций не всем по силам. Или есть какая нить обертка над этим?
| |
|
2.3, uldus (ok), 13:28, 01/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Согласен. Но memcached стандартное решение. Применить его можно быстро и не затратно.
>А использование shm_open функций не всем по силам. Или есть какая
>нить обертка над этим?
Использование memcached - это в первую очередь возможность масштабирования, а shared memory лишь временный выход, по производительности не выигрывающий у memcached, особенно работающего через unix socket. Дополнительный геморой - вечные глюки кеширования через средства разных php-акселераторов, в багзилах которых то и дело поднимаются очередные утечки памяти.
| |
|
3.6, User294 (??), 18:47, 01/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>разных php-акселераторов,
Пардон, а php акселераторы кешируют ведь страницу а не запросы к базе, снимая нагрузку на php интерпретер, а не на базу (на нее если только косвенно - если страница отдается как статика запросов к БД на это, очевидно, не делается).
| |
|
4.7, uldus (ok), 21:39, 01/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>>разных php-акселераторов,
>
>Пардон, а php акселераторы кешируют ведь страницу а не запросы к базе,
Речь про API некоторых php акселераторов, позволяющих хранить ключ/значение в shared memory. Натыкался на пару багов приводящих к утечке памяти в eaccelerator, при использовании данной фичи.
| |
|
|
|
1.5, User294 (??), 18:45, 01/10/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
phpBB2 имхо давно пора выкинуть в /dev/null.Бажный, с вагоном секурити дыр. phpBB3 - тотальный rewrite с учетом грабель phpBB2.По-моему, 3-я версия намного лучше 2-й.
P.S. ну не пи..ц?Лечить тормоза базы по сути примитивной DB вида key,value.А если вместо memcached под это скажем, Berkeley DB какоенить припахать или подобную "простую" бд в стиле key, value - интересно, что получится? :)
| |
|
2.9, ihanick (?), 00:11, 03/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
berkley db уже перестало биться?
её можно будет раскидать на 3-4 сервера, для того чтобы обслуживать запросы 50-400 серверов апачей?
а кеши будут когерентные?
| |
|
3.11, User294 (ok), 03:36, 03/10/2008 [^] [^^] [^^^] [ответить]
| +/– |
>berkley db уже перестало биться?
А оно еще и биться умеет?Что с ним для этого надо делать?Как-то не всетречалось случаев разрушения беркелеевских баз.Правда честно говоря я особо и не старался сломать, так, поигрался с оной базой - ну, работает себе.Вроде key-value достаточно быстро разрюхивает.Транзакции оно вроде умеет, как минимум формально фич заявлен а специально сломать этот механизм я как-то честно говоря не пытался (ну не было такой задачи).К тому же я не вижу ничего критичного если даже это каким-то чудом вдруг случится с базой которая всего лишь банальный кэш.В таком случае вообще прибить нахрен и все дела, заново перезаполнится.Невелика потеря, все-равно кэш вечно жить не должен.
>её можно будет раскидать на 3-4 сервера, для того чтобы обслуживать запросы
>50-400 серверов апачей?
Мне к великому счастью не надо столько гуано :).Если вы не заметиле я вовсе не предлагал таким манером такие нагрузки обслуживать.Чего вы взвились?Меня скорее интересует другой случай - есть какое-то обычное весьма среднее железо, а не 400 серверов и еще что-то с вагоном оперативы под этот memcached. Допустим что RAM как раз не дофига и процессоров не 128 а 1-2-4.Не прокатит ли вместо жручего до RAM ... поюзать ..., допустим, диски у железа не слишком позорные?В общем то единственное что меня интересовало.
>а кеши будут когерентные?
Если вам непременно надо это на 400 апачей (ужосн*х!) сами и ломайте голову над вопросом как этого достичь.Мне же к счастью не надо столь монстрильные решения - еще одних "однокласников" и "facebook" я делать вроде не собираюсь.
| |
|
|
|