а, да.
APC, естественно, быстрее, чем Memcache. раза в 2, насколько я помню. мемкэш работает через сокеты, а APC — через shared memory. НО: у APC кэшированные объекты хранятся с помощью односвязаного списка, т.е. время операций с кэшем линейно зависит от количества объектов. и, если закэшировать 10000 объектов (которые могут быть мелкими и занимать даже меньше 128 мб), то мемкэш начнёт серьёзно обгонять APC. в мемкэше всё хранится с помощью хэш-таблицы и, вероятно, какого-то дерева в случае хэш-коллизий. время в худшем случае пропорционально логарифму от количества объектов, что в реальном мире означает константу.
тут многие пишут, что «статья слабая» и «много воды». и они — правы.
1. совсем не понимаю, как кэшировать в файле всю сериализованную таблицу вообще могла прийти в голову?
2. нужно сразу определиться, какие у нас нагрузки, сколько у нас серверов и какие объёмы данных. например, если мы кэшируем данные в файлах, но в file system cache нашей операционной системы они все не помещаются, то производительность резко упадёт, а (на хоть сколько-нибудь загруженной системе) винчестер через несколько недель тупо выйдет из строя.
ещё нужно определить узкое место — веб-машина (которая генерирует страницу для клиента) или база. ведь кэш мы можем наращивать сколько угодно, а вот mysql при более чем 500 (ну, тысяче) запросах в секунду работает уже не всегда и не у всех. далее я буду предполагать, что процессора нам не жалко, а базу — жалко.
3. и почему цифры приведены такие странные? понятно, что они «демонстрационные» и «для наглядности», но нельзя наглядностью оправдывать взятые совершенно с потолка цифры.
запрос к мемкэшу выполняется порядка 0.001 — 0.01 сек. зависит от задержки в сети.
запрос к базе выполняется, конечно, дольше. не забываем про то, что к БД нужно подключиться, а БД должна ещё сделать выборку из своей системной таблицы с пользователями и проверить ваш пароль (а если это mysql, настроенная каким-нибудь жопоруким кретином, то ещё и сделает запрос на получение символического имени того хоста, к которому вы к ней обращаетесь) — это в том случае, если без persistent. И, вне зависимости от того, persistent ли соединение или нет, БД будет делать выборку по таблицам привелегий на базу данных, на таблицу, к которой вы обращаетесь, и на колонки этой таблицы — всё это занимает время.
4. вообще, стандартная стратегия кэширования довольно проста и работает в 99% случаев.
запросы вида «select * from table where id=123» — кэшировать с ключом table_123. при update/delete из кэша — удалять.
запросы вида «select * from table where some_field=r5283r78» — либо не кэшировать, либо поменять на «select id from table where ...» и далее выбирать уже эти id'ы с помощью мемкэшевского multiselect'а и (если там чего-то не оказалась) второго запроса к базе, складыя его результаты в кэш тоже.
сложные поисковые запросы либо не кэшируются вообще, либо (если это критично) кэшируются на небольшое время (с ключом типа «search_».md5(serialize($serachParams))), но кэш таких поисков никак не обновляется.
APC, естественно, быстрее, чем Memcache. раза в 2, насколько я помню. мемкэш работает через сокеты, а APC — через shared memory. НО: у APC кэшированные объекты хранятся с помощью односвязаного списка, т.е. время операций с кэшем линейно зависит от количества объектов. и, если закэшировать 10000 объектов (которые могут быть мелкими и занимать даже меньше 128 мб), то мемкэш начнёт серьёзно обгонять APC. в мемкэше всё хранится с помощью хэш-таблицы и, вероятно, какого-то дерева в случае хэш-коллизий. время в худшем случае пропорционально логарифму от количества объектов, что в реальном мире означает константу.
у XCache такой проблемы, как у APC, нет.
1. совсем не понимаю, как кэшировать в файле всю сериализованную таблицу вообще могла прийти в голову?
2. нужно сразу определиться, какие у нас нагрузки, сколько у нас серверов и какие объёмы данных. например, если мы кэшируем данные в файлах, но в file system cache нашей операционной системы они все не помещаются, то производительность резко упадёт, а (на хоть сколько-нибудь загруженной системе) винчестер через несколько недель тупо выйдет из строя.
ещё нужно определить узкое место — веб-машина (которая генерирует страницу для клиента) или база. ведь кэш мы можем наращивать сколько угодно, а вот mysql при более чем 500 (ну, тысяче) запросах в секунду работает уже не всегда и не у всех. далее я буду предполагать, что процессора нам не жалко, а базу — жалко.
3. и почему цифры приведены такие странные? понятно, что они «демонстрационные» и «для наглядности», но нельзя наглядностью оправдывать взятые совершенно с потолка цифры.
запрос к мемкэшу выполняется порядка 0.001 — 0.01 сек. зависит от задержки в сети.
запрос к базе выполняется, конечно, дольше. не забываем про то, что к БД нужно подключиться, а БД должна ещё сделать выборку из своей системной таблицы с пользователями и проверить ваш пароль (а если это mysql, настроенная каким-нибудь жопоруким кретином, то ещё и сделает запрос на получение символического имени того хоста, к которому вы к ней обращаетесь) — это в том случае, если без persistent. И, вне зависимости от того, persistent ли соединение или нет, БД будет делать выборку по таблицам привелегий на базу данных, на таблицу, к которой вы обращаетесь, и на колонки этой таблицы — всё это занимает время.
4. вообще, стандартная стратегия кэширования довольно проста и работает в 99% случаев.
запросы вида «select * from table where id=123» — кэшировать с ключом table_123. при update/delete из кэша — удалять.
запросы вида «select * from table where some_field=r5283r78» — либо не кэшировать, либо поменять на «select id from table where ...» и далее выбирать уже эти id'ы с помощью мемкэшевского multiselect'а и (если там чего-то не оказалась) второго запроса к базе, складыя его результаты в кэш тоже.
сложные поисковые запросы либо не кэшируются вообще, либо (если это критично) кэшируются на небольшое время (с ключом типа «search_».md5(serialize($serachParams))), но кэш таких поисков никак не обновляется.
«я, в отличие от вас, не сравниваю себя с другими людьми»
это вы так всех людей, отличающихся от вас, называете, да?
function getSomeArray() {
return array(«A»=>«B»,«C»=>«D»);
}
$x = current(getSomeArray());