Php apcu etc

[babahalki]

Привет коллеги!

Моя разработка форка cms магазина на базе simpla уверенно идет вперед.

Я внедрил на самые затратные методы в системе кеш. Так что теперь для этих операций самое затратное - считать данные и преобразовать их (unserialize). Самая тяжелая страница в системе - загрузка каталога товаров. Сейчас загрузка выполняется за ~500мс. Из них целых 400мс уходит на операцию, которая не зависит от конкретной страницы. Т.е. Она выполняется каждый раз при загрузке любой страницы, снова и снова.
Там примерно 13 проц. Времени считывает и 70 проц. Unserialize. Думаю, если заменить serialize/unserialize на var_export/eval - будет быстрее, но все равно долго.

Пришла идея внедрить демона php, который бы висел постоянно в фоне и выдавал бы всем уже готовые данные, которые сразу можно использовать.

Нашел вот это daemon.io

Что думаете? Можно ли будет от основного процесса передать дочке данные и передать их быстро?

 

[aurora2000]

А что мешает делать по параметрам пользователя cache_id и брать его из памяти или из файла - и не тратить на unserialize кучу времени - а сразу выдавать html? Это явно быстрее.

 

[babahalki]

А что мешает делать по параметрам пользователя cache_id и брать его из памяти или из файла - и не тратить на unserialize кучу времени - а сразу выдавать html? Это явно быстрее.

html кеш совсем статичный. А я хочу кешировать только потенциально долгоиграющие данные. Сейчас попробую php shmop, судя по описанию как раз то, что нужно.
Upd:
Не подходит, может хранить только строковые данные.

APCU не удалось запустить через fastcgi. Осталось попробовать memcached.

 

[shake1]

Осталось попробовать memcached.

Redis?
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

 

[babahalki]

Redis?
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

Редис не подойдет. Он выполняет те же функции, что и мой sql/nosql кеш.
upd: не знал всех его возможностей, спасибо за инфо.
Надо сравнить APCU и REDIS.

Отлично показал себя APCU. Там где было >400мс, стало в пределах 1мс. Только вот включить его в режиме fastcgi не удается.

Может у кого есть опыт?
<-------------- добавлено через 553 сек. -------------->
Нашел интересную статейку, где у людей apc проигрывал в сухую у пары var_export/include
Для просмотра ссылки Войди или Зарегистрируйся

 

[babahalki]

Видимо все зависит от данных, в моем случае это массивы около 100 тыс. элементов с ключами по 32 символа и значениями в виде цифр. Самый быстрый способ оказался serialize, json_encode и var_export примерно на одном уровне, даже json быстрее.

 

[Den1xxx]

Видимо все зависит от данных, в моем случае это массивы около 100 тыс. элементов с ключами по 32 символа и значениями в виде цифр. Самый быстрый способ оказался serialize, json_encode и var_export примерно на одном уровне, даже json быстрее.

При заходе на сервер одновременно 10 пользователей трындец наступает уже при 1000 элементов unserialize, если туда идет запись...

 

[babahalki]

При заходе на сервер одновременно 10 пользователей трындец наступает уже при 1000 элементов unserialize, если туда идет запись...

Это ты про что? что за система?
К примеру фейсбук использует очень успешно связку serialize memcache, судя по кол-ву пользователей, этой конструкции нет предела масштабируемости.

 

[Den1xxx]

Это ты про что? что за система?
К примеру фейсбук использует очень успешно связку serialize memcache, судя по кол-ву пользователей, этой конструкции нет предела масштабируемости.

Я вел проект, который при заходе пользователя производил действия serialize-запись-unserialize-вывод в нескольких местах.
Проблемы начинались, когда в массиве было от 500 элементов и посещаемость от 300 хостов в сутки.
Иногда получается момент, когда 2 и более пользователей ставятся в очередь на запись и получается трындец.
Я решал эту проблему полгода, разными способами и не решил.
Помог вынос перезаписываемых элементов в отдельные сущности, что ставит крест на идее сериализации, т.к. теперь приходится делать выборку из нескольких источников.
Что до Фейсбука, так и Вы можете говорить, что успешно используете связку serialize memcache.
Никто этого не будет знать наверняка, пока не откроют код.
ХЗ, может — там не те сервера, может — не тот язык, может — запись и/или выборка идет редко, а скорее всего кто-то врет, что используют.
Из моего опыта — это очень плохая практика.
Мало того, поиск по данным сильно затруднен.
Единственный плюс — быстрая разработка.
Поэтому я оставил это в конфигах (которые только читаются и редко пишутся) и почти исключил в данных.

Вы не сказали, где храните сериализованные данные — в памяти или базе?

 

[babahalki]

А что мешает делать по параметрам пользователя cache_id и брать его из памяти или из файла - и не тратить на unserialize кучу времени - а сразу выдавать html? Это явно быстрее.

Такой слой кеша наверное тоже придется сделать для самых частотных мест на сайте. Но надо бы придумать какую-то логику, которая позволяла бы самостоятельно определять такие нагруженные места и делать этот кеш там автоматически.

Я вел проект, который при заходе пользователя производил действия serialize-запись-unserialize-вывод в нескольких местах.
...
Вы не сказали, где храните сериализованные данные — в памяти или базе?

Сериализованные данные (массивы и только массивы) хранятся просто в файлах с доступом по ключу md4. Пример: ./cache/0e/0e0b0b9dab3ebe43777ed0143c98b39a.txt
В базе хранятся значения типа integer с доступом опять же по ключу md4. Базу для integer использую потому, что в реальных условиях длительного использования таких записей собирается > 5 млн. и для хранения их на диске используется слишком много места.

По поводу Цукерберга:
Не думаю, что он свистит насчет memcache, я обязательно проверю, потому что serialize сам использую. Сейчас даже подпилил свою cms для работы на hhvm.

Сам memcache в моих крошечных условиях мне не очень подходит, потому что serialize/unserialize на пыхе достаточно длительная процедура, я планирую использовать apcu, который позволяет сразу хранить массивы в памяти и их не придется гонять туда сюда.