|
|
3.12, Аноним (-), 00:31, 16/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
> гораздо интереснее, какой там запас еще остался
Еще около сотни строчек вида for (i=1,i<1000,i++) {};
| |
|
|
|
2.4, Аноним (-), 19:40, 15/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
В кэширующий прокси - фронт-энд балансировки нагрузки на БД, не?
| |
|
|
4.8, Аноним (-), 22:36, 15/11/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вот я дурак, когда Memcached в помощь nginx использовал, а тот, в свою очередь, отдавал накопленную статику из кэша! Надо было напрямую отдавать SQL-сервер на растерзание, без прикрытия фронт-эндом!..
| |
|
5.11, Аноним (-), 00:29, 16/11/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
Простите, у вас nginx кэшировал ответы БД-сервера?
Скажите, как вам это удалось?
| |
|
6.17, Аноним (-), 10:35, 16/11/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Используй голову, Люк (С)
Что, не доходит? Динамические страницы можно формировать в БД. Новость?
| |
6.18, Аноним (-), 19:14, 16/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем он используется лишь при нестандартных запросах, которых менее 5% от общего числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.
| |
|
7.20, Аноним (-), 19:48, 16/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем
> он используется лишь при нестандартных запросах, которых менее 5% от общего
> числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.
Ты совершенно прав, анон. +100500
| |
|
|
|
|
|
|
1.5, Аноним (-), 20:23, 15/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Эх только перелез на редис.
Хотя и правильно перелез. ТТЛ нужен, а самому его делать не охото и не правильно.
Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.
Короче упреждающее обновление кеша нужно. а без TTL неудобно.
| |
|
2.9, san (??), 22:52, 15/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
Ну, сделай, например, чтобы первый, кто полез за данными в базу, установил в memcache в качестве результата для этой операции специальное значение "Work in progress", чтобы другие подождали. Или если получил данные из memcache и точно знаешь, что их нужно закешировать, а TTL вот-вот обнулиться, продли его (чтобы ты был один такой умный) и обнови данные из SQL (как вариант, можно сделать это с некоторой вероятностью, которая тем больше, чем длительнее рассчет этих данных, вместо продлевания TTL, тогда чем больше запросов лезут к этим данным и больше время тратится на их перерассчет, тем больше шансов, что кто-то попытается их продлить до обнуления TTL). Можно оба подхода скомбинировать. Да и сам, если подумаешь, сможешь придумать получше варианты для своей задачи. Тут только главное не переусердствовать, потому что кеш должен содержать данные, которые (часто нужны)*(длительно рассчитываемы), так как все подряд туда не поместится - оперативка ограничена.
| |
|
3.19, Аноним (-), 19:47, 16/11/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
"Плашка оперативы стоит как лопата д.рьма" (С)
Ты ничо не напутал, Сан? На дворе 2011й, не 1996й. Чем ограничена оператива? Воображением логистика фирмы?
| |
|
2.21, имя (?), 21:47, 16/11/2011 [^] [^^] [^^^] [ответить]
| +/– |
мда мне бы такие проблемы ...
php?
А если серьёзно:
ключевое слово синхронизация.
| |
|
1.15, AlexAT (ok), 07:32, 16/11/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>>> Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.
Если у вас при холодном кеше система неустойчива - её пора серьёзно дорабатывать.
| |
|