Php apcu etc

Тема в разделе "PHP", создана пользователем babahalki, 19 ноя 2017.

Метки:
Модераторы: latteo
  1. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    246
    Симпатии:
    98
    Привет коллеги!

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

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

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

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

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

    aurora2000 Постоялец

    Регистр.:
    24 авг 2014
    Сообщения:
    122
    Симпатии:
    42
    А что мешает делать по параметрам пользователя cache_id и брать его из памяти или из файла - и не тратить на unserialize кучу времени - а сразу выдавать html? Это явно быстрее.
     
  3. babahalki

    babahalki

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

    APCU не удалось запустить через fastcgi. Осталось попробовать memcached.
     
    Последнее редактирование модератором: 19 ноя 2017
  4. shake1

    shake1

    Регистр.:
    16 янв 2013
    Сообщения:
    520
    Симпатии:
    559
  5. babahalki

    babahalki

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

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

    Может у кого есть опыт?
    <-------------- добавлено через 553 сек. -------------->
    Нашел интересную статейку, где у людей apc проигрывал в сухую у пары var_export/include
    https://blog.graphiq.com/500x-faster-caching-than-redis-memcache-apc-in-php-hhvm-dcd26e8447ad
     
  6. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    246
    Симпатии:
    98
    Видимо все зависит от данных, в моем случае это массивы около 100 тыс. элементов с ключами по 32 символа и значениями в виде цифр. Самый быстрый способ оказался serialize, json_encode и var_export примерно на одном уровне, даже json быстрее.
     
    romas_s нравится это.
  7. Den1xxx

    Den1xxx

    Moderator
    Регистр.:
    15 янв 2014
    Сообщения:
    279
    Симпатии:
    152
    При заходе на сервер одновременно 10 пользователей трындец наступает уже при 1000 элементов unserialize, если туда идет запись...
     
  8. babahalki

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    246
    Симпатии:
    98
    Это ты про что? что за система?
    К примеру фейсбук использует очень успешно связку serialize memcache, судя по кол-ву пользователей, этой конструкции нет предела масштабируемости.
     
  9. Den1xxx

    Den1xxx

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

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

    babahalki

    Регистр.:
    6 май 2016
    Сообщения:
    246
    Симпатии:
    98

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


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

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

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