Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 43
Еще один из плюсов мемкеша - оно может работать на другой машине, за пределами "localhost"
И обычно он так и делает.
Вот на ЖЖ( для которого кэшед и разрабатывался) - сотни серверов спец под него
Вот на ЖЖ( для которого кэшед и разрабатывался) - сотни серверов спец под него
Тут даже не то что "сотни серверов", а то что можно вливать в него и читать с него с других серверов... Т.е. не обязательно кеш должен быть на той машине, где работает софт, пишущий в него ...
Часто выделение отдельной машины под кеш очень помогает разделить нагрузки
Часто выделение отдельной машины под кеш очень помогает разделить нагрузки
Есть такое.
В одном из проектов для ускорения ajax запросов у меня грузятся "картинки" с другого сервера(с сервера базы данных, чтобы побыстрее)
Данные кладутся в кешед.
Потом когда на клиента срабатывает onload картинки идет ajax запрос на основной сервер, который, как фокусник, вытаскивает данные сгенерированные другим сервером.
Раньше он проксировал запросы на таргет сервер( чтобы получить данные из его локального кеша). Работало.. быстро.
Но мемкешед раза в три быстрее эту функцию выполняет. Потому что без накладок http проброса.
В одном из проектов для ускорения ajax запросов у меня грузятся "картинки" с другого сервера(с сервера базы данных, чтобы побыстрее)
Данные кладутся в кешед.
Потом когда на клиента срабатывает onload картинки идет ajax запрос на основной сервер, который, как фокусник, вытаскивает данные сгенерированные другим сервером.
Раньше он проксировал запросы на таргет сервер( чтобы получить данные из его локального кеша). Работало.. быстро.
Но мемкешед раза в три быстрее эту функцию выполняет. Потому что без накладок http проброса.
как то я не понял - XCache это и есть акселератор, то, что там кеш и он доступен через API - это не основная его функция (в смысле - кеша для пользовательских данных). и использовать его в связке с акселератором другим.... да может и вообще не работать. не понимаю зачем вообще
XCache хорошо оптимизирует код( лучше других), и хорошо кэширует данные.
Но у него нету операции lock которая жизненно необходима для нагруженных проектов.
И он может хранить МАЛО ДАННЫХ.
Так как размер shared memory очень ограничен.
На бздях вроде как 32 метра тока(не проверял).
Мемкешед может в свою очередь хранить десятки-сотни гигабайт, но из-за своей распределенно-сетевой организации работает медленнее чем локальный кеш.
Но у него нету операции lock которая жизненно необходима для нагруженных проектов.
И он может хранить МАЛО ДАННЫХ.
Так как размер shared memory очень ограничен.
На бздях вроде как 32 метра тока(не проверял).
Мемкешед может в свою очередь хранить десятки-сотни гигабайт, но из-за своей распределенно-сетевой организации работает медленнее чем локальный кеш.
А зачем lock на нагруженных проектах?
Будем считать что ваш пост кэшируется.
Будем также считать что все коменты кэшируются.
Примем как факт что эту страницу читает 1000 человек.
Будем считать что весь кеш коментов рефрешиться за 0.1 сек( хотя я думаю больше)
Из них чтук 10 нажмет ф5 в пределах 0.1 секунды.
Результат - вы кешируете коменты в 10 потоков. Одновременно одно и тоже, очень сильно мешая друг другу.
У меня есть кешируемые блоки, которые стоят под нагрузкой 1000 обращений в секунду.
Кеш на них 6 часов. Время генерации 60мсек ( будем считать 20 раз в секунду)
Получаем что без локов через 6 часов мы будем кешировать этот код в .. 20 потоков.
а так как это притормозит выполнение заданного участка кода.. Получим в 40 потоков.
Ай хорошо. У меня 8 процесоров стоит, а у вас?
Будем также считать что все коменты кэшируются.
Примем как факт что эту страницу читает 1000 человек.
Будем считать что весь кеш коментов рефрешиться за 0.1 сек( хотя я думаю больше)
Из них чтук 10 нажмет ф5 в пределах 0.1 секунды.
Результат - вы кешируете коменты в 10 потоков. Одновременно одно и тоже, очень сильно мешая друг другу.
У меня есть кешируемые блоки, которые стоят под нагрузкой 1000 обращений в секунду.
Кеш на них 6 часов. Время генерации 60мсек ( будем считать 20 раз в секунду)
Получаем что без локов через 6 часов мы будем кешировать этот код в .. 20 потоков.
а так как это притормозит выполнение заданного участка кода.. Получим в 40 потоков.
Ай хорошо. У меня 8 процесоров стоит, а у вас?
жги!
не останавливайся! :D
не останавливайся! :D
Вторую часть понял, улыбнулся, а вот первую не совсем.
Пост кешируется, по нажатию F5 отдаётся из кеша, всё норм и быстро. Что я не так понял? :(
Пост кешируется, по нажатию F5 отдаётся из кеша, всё норм и быстро. Что я не так понял? :(
Эээ кешируется у вас или на сервере?
Правильно - на сервере.
КАК ОН КЕШИРУЕТСЯ?
line1:$having_cached=get_cache("post_of_~devgru")
line2:if(!$having_cached) make_cache_of_devgru_s_post()
и вот 10 пхп потоков практически одновременно подходят к line1
первый смотрит - нету кеша( он же не бесконечно храниться, да его еще и создать надо)
и начинает его кешировать, но еще не закешировал!
второй пхп поток доходит.. О! нету кеша..
третий.. О! первые два еше cache_store не сделали.. помочь чтоли..
четвертый -. кеш есть, выводим из кеша....
вот за этим локи и нужны :)
Правильно - на сервере.
КАК ОН КЕШИРУЕТСЯ?
line1:$having_cached=get_cache("post_of_~devgru")
line2:if(!$having_cached) make_cache_of_devgru_s_post()
и вот 10 пхп потоков практически одновременно подходят к line1
первый смотрит - нету кеша( он же не бесконечно храниться, да его еще и создать надо)
и начинает его кешировать, но еще не закешировал!
второй пхп поток доходит.. О! нету кеша..
третий.. О! первые два еше cache_store не сделали.. помочь чтоли..
четвертый -. кеш есть, выводим из кеша....
вот за этим локи и нужны :)
Да, понял, спасибо.
А для memcached реально использовать такой костыль или есть лучше чем
?
А для memcached реально использовать такой костыль или есть лучше чем
$having_cached=get_cache("post_of_~devgru")
if(!$having_cached && !$memcache->get('post_of_~devgru|lock'))
{
$memcache->set('post_of_~devgru|lock',true);
$make_cache_of_devgru_s_post()
$memcache->delete('post_of_~devgru|lock');
}
?
Почему не мьютексы ручками или оффлайновая генерация?
К офлайновой генерации сейчас переходим. Не такая уж это и тривиальная задачка.
А мьютексы ручками? Кинтесь ссылок, а то я кроме как
$fp = fopen(TMPDIR . "/abc_data.lock", "w");flock($fp, LOCK_EX);(пример Xcache)
ну или fopen($this->filename, "x")
и не знаю ничего. А файлы меня не прут.
А мьютексы ручками? Кинтесь ссылок, а то я кроме как
$fp = fopen(TMPDIR . "/abc_data.lock", "w");flock($fp, LOCK_EX);(пример Xcache)
ну или fopen($this->filename, "x")
и не знаю ничего. А файлы меня не прут.
чем файлы плохи?
>К офлайновой генерации сейчас переходим. Не такая уж это и тривиальная задачка.
Тривиальных вещей не бывает :)
>А мьютексы ручками? Кинтесь ссылок, а то я кроме как...
Чем наличие данных с определенным ключем в кеше не лок?
Тривиальных вещей не бывает :)
>А мьютексы ручками? Кинтесь ссылок, а то я кроме как...
Чем наличие данных с определенным ключем в кеше не лок?
Как вы будете ждать покуда они уйдут?
while(check(...)){} :)
или менее криво
while(check(...)){usleep(а вот сколько)}
не для этого мьютексы и ивенты придуманы.
странно что в пхп нету нативной поддержки
while(check(...)){} :)
или менее криво
while(check(...)){usleep(а вот сколько)}
не для этого мьютексы и ивенты придуманы.
странно что в пхп нету нативной поддержки
Ко мне этот вопрос обращать глупо, это ваша система, я не знаю, что в ней "дороже".
http://ru2.php.net/manual/ru/ref.sem.php
http://ru2.php.net/manual/ru/ref.sem.php
apc.write_lock boolean
On busy servers when you first start up the server, or when many files are modified, you can end up with all your processes trying to compile and cache the same files. With write_lock enabled, only one process at a time will try to compile an uncached script while the other processes will run uncached instead of sitting around waiting on a lock.
On busy servers when you first start up the server, or when many files are modified, you can end up with all your processes trying to compile and cache the same files. With write_lock enabled, only one process at a time will try to compile an uncached script while the other processes will run uncached instead of sitting around waiting on a lock.
Не правда. У меня на XCache 128 Мб под хранение переменных выделенно (по 64Мб на каждое ядро) и столько же под кеш опкодов. Сейчас занят 71% из кеша переменных. И ничего, пашет ;) ОС - FreeBSD 6.2
чес говоря XCache не пробовал под нагрузкой.
Я пробовал. И пробую до сих пор :) Очень стабильно себя ведёт (1.2.1).
Размер кеша для пользовательских данных - 512мб. ОС- Фря 6.2
У меня систем работает так, что блокировки нужны редко, около одного раза в минуту. Поэтому предложенный выше вариант про while(..) usleep(..) вполне хорош.
Что именно класть в слип этот - решается просто - изначально берётся 10000, затем по ходу обновлений считается среднее значение времени необходимого на обновление за последние 10 операций и берётся половина от него для юслипа. Работает и не жужжит :)
С фрагментацией не сталкивался, хотя последний аптайм был около месяца. Иногда, правда, httpd"шники начинали что-то делать и увеличивать загрузку процессора. У меня возникло впечатление что помимо GC в xCache есть и дефрагментатор памяти.
Размер кеша для пользовательских данных - 512мб. ОС- Фря 6.2
У меня систем работает так, что блокировки нужны редко, около одного раза в минуту. Поэтому предложенный выше вариант про while(..) usleep(..) вполне хорош.
Что именно класть в слип этот - решается просто - изначально берётся 10000, затем по ходу обновлений считается среднее значение времени необходимого на обновление за последние 10 операций и берётся половина от него для юслипа. Работает и не жужжит :)
С фрагментацией не сталкивался, хотя последний аптайм был около месяца. Иногда, правда, httpd"шники начинали что-то делать и увеличивать загрузку процессора. У меня возникло впечатление что помимо GC в xCache есть и дефрагментатор памяти.
Насколько я помню, оптимизатор опкода в xcache ещё не особо реализован. Или я вас неправильно понял? Вы имеете в виду, что он лучше кэширует опкод?
Из известных мне кэшеров оптимизатор нормально работает только у eAcc но ему это особо не помогает :):)
По тестам которые проводил НЕ Я( но и ссылкой не поделюсь)
Скорость работы кода(без кеша данных) была максимальна у XCache(без оптимизации) в большинстве тестов.
APC(без оптимизации, с оптимизайцией половина тестов крашиться) В некоторых тестах быстрее, но общая оценка мелек ниже( да и глючит он)
Потом с 10% отставанием( Xcache давал 170% скорость, eAcc 150-160) идет eAcc
Потом зенд, который в некоторых тестах медленнее чистого php
По тестам которые проводил НЕ Я( но и ссылкой не поделюсь)
Скорость работы кода(без кеша данных) была максимальна у XCache(без оптимизации) в большинстве тестов.
APC(без оптимизации, с оптимизайцией половина тестов крашиться) В некоторых тестах быстрее, но общая оценка мелек ниже( да и глючит он)
Потом с 10% отставанием( Xcache давал 170% скорость, eAcc 150-160) идет eAcc
Потом зенд, который в некоторых тестах медленнее чистого php
если вам статистику интересно, то можно почитать сравнение 2006 года тут
http://itst.net/wp-content/uploads/2006/10/PHP%20Bytecode%20Cacher%20Review.html
или более свежее, но конкретно про Друпал тут
http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html
http://itst.net/wp-content/uploads/2006/10/PHP%20Bytecode%20Cacher%20Review.html
или более свежее, но конкретно про Друпал тут
http://2bits.com/articles/benchmarking-drupal-with-php-op-code-caches-apc-eaccelerator-and-xcache-compared.html
>>Я надеюсь, что нормальные люди уже прониклись
>>необходимостью кешировать вывод данных на своих сайтах
Такое впечатление что Вы тоже только недавно прониклись.
Google: Кеш Инвалидация
В кратце:
Устанавливайте продожительность жизни значения в кеше побольше и удаляйте значение когда оно неактуально
Например:
Список новостей за последнюю неделю
Ставите значение жизни этих данных кеше равным к примеру 24часа (можно и больше)
Как только добавляется новость значение из кеша удаляется.
так же рекомендую погуглить на предмет: Dog-pile Effect
>>необходимостью кешировать вывод данных на своих сайтах
Такое впечатление что Вы тоже только недавно прониклись.
Google: Кеш Инвалидация
В кратце:
Устанавливайте продожительность жизни значения в кеше побольше и удаляйте значение когда оно неактуально
Например:
Список новостей за последнюю неделю
Ставите значение жизни этих данных кеше равным к примеру 24часа (можно и больше)
Как только добавляется новость значение из кеша удаляется.
так же рекомендую погуглить на предмет: Dog-pile Effect
Кеш обновляется раз в день. По данным статистики посещений.
По факту добавление чего либо из админки - да сношу кеши документа, и рубрик где он представлен.
Но это так.. частности. Большинство вещей кэшируется всеже на лету.
По факту добавление чего либо из админки - да сношу кеши документа, и рубрик где он представлен.
Но это так.. частности. Большинство вещей кэшируется всеже на лету.
Скажите пожалуйста, а вы кеш группируете как-то? Чтобы, например, удалять сразу все фрагменты кеша, например, относящиеся к какому-то разделу, а не каждый по-отдельности.. Меня этот вопрос давно мучает, и меня отпугивает мысль о том, что нужно о каждом куске кеша вручную заботиться
знаете, тут малек посложнее.
с каждой сушьностью у меня связано ограничение колличесво кеша.
Если брать новость то это
1.ее красивый URL
2.обратное сопоставление красивого урла номеру документа
3.сама новость с остальными полями
4.Блок в рубрике где она представлена(страница листера образно говоря)
ну и самое главное - правильное именование
:new:#:url
:new:#:body
сделали что-то, вызвали диспачер.
В случае новости от берет list всех переменых и смотрит - подходит начало имени или нет( так как вообще нельзя предсказать чего и где в какой момент времени и под каким именем залезло)
В случае с другими сущностями все просто - диспачер снимает 1-3 известных значений..
Тоесть написали классик про сущность - допишите кеш-удалятор в него.
с каждой сушьностью у меня связано ограничение колличесво кеша.
Если брать новость то это
1.ее красивый URL
2.обратное сопоставление красивого урла номеру документа
3.сама новость с остальными полями
4.Блок в рубрике где она представлена(страница листера образно говоря)
ну и самое главное - правильное именование
:new:#:url
:new:#:body
сделали что-то, вызвали диспачер.
В случае новости от берет list всех переменых и смотрит - подходит начало имени или нет( так как вообще нельзя предсказать чего и где в какой момент времени и под каким именем залезло)
В случае с другими сущностями все просто - диспачер снимает 1-3 известных значений..
Тоесть написали классик про сущность - допишите кеш-удалятор в него.
Кеш надо не валить а помечать на удаление - когда сделается новый тогда замените.
Эээ простите, у него time-to-live экпариться сам по себе.
Есть конечно идеи отменить ttl к черту и жить на основе того чтобы кэшер сам когда память кончается убивал переменные которые долго не аксесяться.
Но я честно - еще к этому не готов.
Сейчас если что,кто накосячил и страница встала раком.. Ну и хрен с ней, через 20 минут кеш обновиться.
А тут лететь в админку надо и лихорадочно жать - ааа стереть то-то и то-то.
Хотя, насколько я читал - крупные порталы работают без ttl
Есть конечно идеи отменить ttl к черту и жить на основе того чтобы кэшер сам когда память кончается убивал переменные которые долго не аксесяться.
Но я честно - еще к этому не готов.
Сейчас если что,кто накосячил и страница встала раком.. Ну и хрен с ней, через 20 минут кеш обновиться.
А тут лететь в админку надо и лихорадочно жать - ааа стереть то-то и то-то.
Хотя, насколько я читал - крупные порталы работают без ttl
Хм. А если как вариант. Кеша нет - в кеш ставится флаг, что нужно добавить. Через время n запускается скрипт, который этот кэш генерит (время n только высчитать, в завимости от нагрузки). Соотвествнно пока время n не прошло - отдавать пока без кеша (n думаю не более 1-2 секунды будет).
Только вот как крон под это дело настроить. Постоянно же он не будет носиться....
Только вот как крон под это дело настроить. Постоянно же он не будет носиться....
Ребята подскажите пожалуйста есть ли понятие совместимости в работе одновременно нескольких кешеров? Что то ничего не нагуглил на эту тему. Служба поддержки хостинга долго пыталась настроить, но в итоге вырубила мне opcache и оставила только xcache, объяснив, что они совместно не работают. Это правда что можно использовать только один кешер на сервере иначе будут конфликты. Вообще у меня довольно тяжеловатые сайты на VPS и я хотел немного ускориться. Стоит apache+nginx php 5.6. Вот и интересуюсь может можно как то настроить совместную работу кешеров, Насчет opcache насколько я понял он кеширует только сами php скрипты а пользовательские данные не кеширует. Т.е. в конфиге движка указано какой кеш использовать file, memory, xcache. Если укажем file то понятно, что проблем не будет, а вот насчет memory и xcache непонятно что и как. Уважаемые гуру помогите пожалуйста разобраться в этом вопросе. Спасибо.
Несколько кешеров «файлов» будут драться друг с другом — тут лучше оставлять один.
А вот кешировать данные может не каждый, да и сама возможность этого часто выключена в дефолтных конфигах.
Все остальное зависит от конфига «двигла» — с каким кешером умеет работать, с тем и надо.
В принципе всегда можно работать на дефолтном opcache — он вроде самый шустрый — а данные кешировать ручками в памяти — мемкеше, редисе или обычно shared_mem, но это к движку.
А вот кешировать данные может не каждый, да и сама возможность этого часто выключена в дефолтных конфигах.
Все остальное зависит от конфига «двигла» — с каким кешером умеет работать, с тем и надо.
В принципе всегда можно работать на дефолтном opcache — он вроде самый шустрый — а данные кешировать ручками в памяти — мемкеше, редисе или обычно shared_mem, но это к движку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Борьба с фрагментацией PHP кешеров