| 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 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>berkley db уже перестало биться?
А оно еще и биться умеет?Что с ним для этого надо делать?Как-то не всетречалось случаев разрушения беркелеевских баз.Правда честно говоря я особо и не старался сломать, так, поигрался с оной базой - ну, работает себе.Вроде key-value достаточно быстро разрюхивает.Транзакции оно вроде умеет, как минимум формально фич заявлен а специально сломать этот механизм я как-то честно говоря не пытался (ну не было такой задачи).К тому же я не вижу ничего критичного если даже это каким-то чудом вдруг случится с базой которая всего лишь банальный кэш.В таком случае вообще прибить нахрен и все дела, заново перезаполнится.Невелика потеря, все-равно кэш вечно жить не должен.
>её можно будет раскидать на 3-4 сервера, для того чтобы обслуживать запросы
>50-400 серверов апачей?
Мне к великому счастью не надо столько гуано :).Если вы не заметиле я вовсе не предлагал таким манером такие нагрузки обслуживать.Чего вы взвились?Меня скорее интересует другой случай - есть какое-то обычное весьма среднее железо, а не 400 серверов и еще что-то с вагоном оперативы под этот memcached. Допустим что RAM как раз не дофига и процессоров не 128 а 1-2-4.Не прокатит ли вместо жручего до RAM ... поюзать ..., допустим, диски у железа не слишком позорные?В общем то единственное что меня интересовало.
>а кеши будут когерентные?
Если вам непременно надо это на 400 апачей (ужосн*х!) сами и ломайте голову над вопросом как этого достичь.Мне же к счастью не надо столь монстрильные решения - еще одних "однокласников" и "facebook" я делать вроде не собираюсь.
| | |
|
|
| 1.33, LazurittireBut (?), 07:29, 17/07/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
ООО ЛАЗУРИТ прямой поставщик грузовых шин LANVIGATOR из Вьетнама с эко-сертификацией 2026. B2B-партнёрство экономия >30%. Сертификаты ЕАЭС, ТР ТС 018, Честный знак. Оплата: безнал (НДС 22%) или касса. Рассрочка на ASIANCATALOG. Срок: 1530 суток. Доставка 40-фт контейнерами ж/д или авто по РФ. Модели: SL101, AM201, AV211, DL301, DV302, DM325 и др. в размерах 11R22.5, 11R24.5, 285/75R24.5, 295/75R22.5, 255/70R22.5, 275/80R22.5, 295/80R22.5, 215/75R17.5, 235/75R17.5, 385/65R22.5, 315/80R22.5, 275/70R22.5, 385/55R22.5, 315/70R22.5, 13R22.5, 245/70R19.5, 265/70R19.5, 325/95R24, 245/70R17.5, 225/70R19.5, 285/70R19.5, 295/60R22.5, 315/60R22.5. Цены производителя с НДС. Доставка по России. ASIANCATALOG.
| | |
|