Анонсирован (http://groups.google.com/group/memcached/msg/7a7d944616502a4a) выход нового релиза системы кеширования данных в оперативной памяти Memcached 1.4.10 (http://memcached.org/), оперирующей данными в формате ключ/значение и отличающейся простотой использования. Новая версия примечательна работой (http://code.google.com/p/memcached/wiki/ReleaseNotes1410), проделанной в направлении увеличения производительности и улучшения поддержки многопоточности. Внесённые оптимизации позволили заметно увеличить производительность конфигураций, в которых memcached работает в 3-6 потоков (от "-t 3" до "-t 6", при использовании значений "-t" больше 6 - производительность падает).
Тестирование пакетом mc-crusher (http://github.com/dormando/mc-crusher) на сервере с четырёхядерным процессором показало, что пропускная способность Memcached возросла с 300 до 930 тысяч операций "set" в секунду, а скорость извлечения данных по ключам увеличилась с 1.6 до 3.7 миллионов операций "get" в секунду. Про...URL: http://groups.google.com/group/memcached/msg/7a7d944616502a4a
Новость: http://www.opennet.me/opennews/art.shtml?num=32306
Ни чего себе так поаптомайзили
гораздо интереснее, какой там запас еще остался
> гораздо интереснее, какой там запас еще осталсяЕще около сотни строчек вида for (i=1,i<1000,i++) {};
пустые циклы? они выкидываются компилятором
Осталось придумать куда бы его засунуть?! :)
В кэширующий прокси - фронт-энд балансировки нагрузки на БД, не?
у всего этого обычно есть свои кеши и memcached там ни в каком виде не нужен.
Вот я дурак, когда Memcached в помощь nginx использовал, а тот, в свою очередь, отдавал накопленную статику из кэша! Надо было напрямую отдавать SQL-сервер на растерзание, без прикрытия фронт-эндом!..
Простите, у вас nginx кэшировал ответы БД-сервера?
Скажите, как вам это удалось?
Используй голову, Люк (С)Что, не доходит? Динамические страницы можно формировать в БД. Новость?
БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем он используется лишь при нестандартных запросах, которых менее 5% от общего числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.
> БД-сервер активно используется лишь в начале, когда копится статика для кэша. Затем
> он используется лишь при нестандартных запросах, которых менее 5% от общего
> числа в моём случае. Некоторые nginx'ом Apache прикрывают, используя и Memcached.Ты совершенно прав, анон. +100500
Эх только перелез на редис.
Хотя и правильно перелез. ТТЛ нужен, а самому его делать не охото и не правильно.
Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.
Короче упреждающее обновление кеша нужно. а без TTL неудобно.
а устранить условие гонки никак?
Ну, сделай, например, чтобы первый, кто полез за данными в базу, установил в memcache в качестве результата для этой операции специальное значение "Work in progress", чтобы другие подождали. Или если получил данные из memcache и точно знаешь, что их нужно закешировать, а TTL вот-вот обнулиться, продли его (чтобы ты был один такой умный) и обнови данные из SQL (как вариант, можно сделать это с некоторой вероятностью, которая тем больше, чем длительнее рассчет этих данных, вместо продлевания TTL, тогда чем больше запросов лезут к этим данным и больше время тратится на их перерассчет, тем больше шансов, что кто-то попытается их продлить до обнуления TTL). Можно оба подхода скомбинировать. Да и сам, если подумаешь, сможешь придумать получше варианты для своей задачи. Тут только главное не переусердствовать, потому что кеш должен содержать данные, которые (часто нужны)*(длительно рассчитываемы), так как все подряд туда не поместится - оперативка ограничена.
"Плашка оперативы стоит как лопата д.рьма" (С)Ты ничо не напутал, Сан? На дворе 2011й, не 1996й. Чем ограничена оператива? Воображением логистика фирмы?
мда мне бы такие проблемы ...
php?
А если серьёзно:
ключевое слово синхронизация.
>>> Потому как когда время жизни ключа истекает идет запрос в SQL. А запрос в SQL Это время, пусть несколько десятков милисикунд но время. И в это время кэш пустой. А раз он пустой SQL вдогонку получает еще несколько сотен запросов, от чего все и падает.Если у вас при холодном кеше система неустойчива - её пора серьёзно дорабатывать.
Вот поэтому и редис