Какой кешер для php лучше? Как выбрать?

Question

[47911]

Вообщем. Исходное:
- MariaDB(10.5)
- php-fpm 5.6
- php-fpm 7.0
- php-fpm 7.2
- php-fpm 7.3
- Debian 10
- nginx 1.19.2

Как я понял есть:
- APC
- XCache
- OPCache
- eAccelerator (вроде не развивается с 2016)
- memchached (ставится в связке с кем-то из выше изложенных)

Ну для кешеирования php. Собственно извечный вопрос: какой лучше?

Если важно: 2 процессора. Каждый по 32 ядра. 3 Гига Герц. 94 гига оперативы.

Comments

[Максим Федоров]

Попробуйте все на тестах своей реальной нагрузки и своего приложения

[Алексей Уколов]

Ну для кешеирования php.

Давайте сначала вы уточните, что вы под "кешированием php" подразумеваете.

[47911]

Алексей Уколов,
Кешеирование результата выполнения кода: http://сайт.рф/index.php - чтобы 1 раз выполнился и более в базу не лез. При условии что у самого сайта нету кешеирования.

[Алексей Уколов]

Так, а что такое "у самого сайта кеширование"?

[47911]

Алексей Уколов, когда у сайта есть компонент/плагин, который при обращении создаёт файл с данными из базы, чтобы при следующем обращении их сунуть, а не лезть в базу/дёргать "компоненты/плагины" которые требуются для создание страницы, к которой обратились.

[47911]

Выделенный сервер.

Answer 1

[FanatPHP]

Никакой.

Судя по тому, что ты путаешь opcode cache с data cache, кэш тебе вообще никакой не нужен, а вопрос задан от балды.
Учись мудрости у природы: когда коту делать нечего, он не кэш ищет, а гигиену наводит. И это очень правильное занятие в твоей ситуации. Куда меньше вреда принесёт

Comments

[47911]

Эм. Вопрос встал, когда началось посещение в сутки 24 тыс. уникальных ip, которыемогут заходить до 1000 раз в сутки(допустим боты, которых не пошлёшь - по разным причинам. Например: нет гарантии что это бот).

Проблема в том, что яндекс, например, обнаглел. 8-10 IP gj 10 000 заходов в сутки, и 1 бот от него 40 000. на 300 сайтов. Собственно когда глянул: вообще никакое кешер не стоит. Вот и поднялся вопрос.

[FanatPHP]

ПРИ ЧЕМ ЗДЕСЬ КОД? При чем здесь яндекс?
100 тыщ хитов для такого железа - это вообще ни о чем.

Сайт работает? Ничего не тормозит? Зачем тебе тогда кэш?

[47911]

300 сайтов. База сжирает весь процессор. Вроде нормально оно настроено. -> подозрение на количество заходов. - идея об кешере.

[FanatPHP]

База сжирает весь процессор.

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

Вроде нормально оно настроено.

Тебя нагло обманули.

Тебе надо разобраться во-первых, с кривым похапе кодом, который грузит базу,
а во-вторых - с настройками базы.

Для этого надо сначала разобраться, что именно грузит базу

[ThunderCat]

47911, Как всегда - вопрос собственно не отражает сути проблемы вообще.

[47911]

ThunderCat,
В базе начинается нирвана: Sending data SELECT .... Запросы разные. Может быть от Джумал - компонент К2 - выборка статей 50 шт. при таблице в 100000

А может быть и вордпресса - 10 шт - постов. При таблице до 50 000.

Собственно оно начинает длится 300 - 1300 секунд. Т.е. оно постепенно уползает в эту ситуацию. Собственно без нагрузки - всё быстро выполняется.

Конфиг(если важно)

#
# These groups are read by MariaDB server.
# Use it for options that only the server (but not clients) should see

# this is read by the standalone daemon and embedded servers
[server]

# this is only for the mysqld standalone daemon
[mysqld]

#
# * Basic Settings
#

user                    = mysql
pid-file                = /run/mysqld/mysqld.pid
basedir                 = /usr
datadir                 = /var/lib/mysql
tmpdir                  = /tmp
lc-messages-dir         = /usr/share/mysql
lc-messages             = en_US
skip-external-locking

# Broken reverse DNS slows down connections considerably and name resolve is
# safe to skip if there are no "host by domain name" access grants
#skip-name-resolve

# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
bind-address            = 127.0.0.1

#
# * Fine Tuning
#

#key_buffer_size        = 128M
#max_allowed_packet     = 1G
#thread_stack           = 192K
#thread_cache_size      = 8
# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
#myisam_recover_options = BACKUP
#max_connections        = 100
#table_cache            = 64

#
# * Logging and Replication
#

# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
# Recommend only changing this at runtime for short testing periods if needed!
#general_log_file       = /var/log/mysql/mysql.log
#general_log            = 1

# When running under systemd, error logging goes via stdout/stderr to journald
# and when running legacy init error logging goes to syslog due to
# /etc/mysql/conf.d/mariadb.conf.d/50-mysqld_safe.cnf
# Enable this if you want to have error logging into a separate file
#log_error = /var/log/mysql/error.log
# Enable the slow query log to see queries with especially long duration
#slow_query_log_file    = /var/log/mysql/mariadb-slow.log
#long_query_time        = 10
#log_slow_verbosity     = query_plan,explain
#log-queries-not-using-indexes
#min_examined_row_limit = 1000

# The following can be used as easy to replay backup logs or for replication.
# note: if you are setting up a replication slave, see README.Debian about
#       other settings you may need to change.
#server-id              = 1
#log_bin                = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
#max_binlog_size        = 100M

#
# * SSL/TLS
#

# For documentation, please read
# https://mariadb.com/kb/en/securing-connections-for-client-and-server/
#ssl-ca = /etc/mysql/cacert.pem
#ssl-cert = /etc/mysql/server-cert.pem
#ssl-key = /etc/mysql/server-key.pem

#
# * Character sets
#

# MySQL/MariaDB default is Latin1, but in Debian we rather default to the full
# utf8 4-byte character set. See also client.cnf
character-set-server  = utf8mb4
collation-server      = utf8mb4_general_ci

#
# * InnoDB
#

# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
# Most important is to give InnoDB 80 % of the system RAM for buffer use:
# https://mariadb.com/kb/en/innodb-system-variables/#innodb_buffer_pool_size
#innodb_buffer_pool_size = 8G

# this is only for embedded server

############################################################## KOLDOBCTBO
#max_allowed_packet     = 4M
#max_connections        = 300
#read_buffer_size = 1M
#key_buffer_size        = 128M
#sort_buffer_size = 2M
##read_rnd_buffer_size = 1M
##thread_stack		= 192K
#query_cache_limit	= 4M
#join_buffer_size = 8M;
wait_timeout = 5
interactive_timeout = 5

[embedded]

# This group is only read by MariaDB servers, not by MySQL.
# If you use the same .cnf file for MySQL and MariaDB,
# you can put MariaDB-only options here
[mariadb]

# This group is only read by MariaDB-10.5 servers.
# If you use the same .cnf file for MariaDB of different versions,
# use this group for options that older servers don't understand
[mariadb-10.5]

[FanatPHP]

может быть что угодно
начинать надо с индексов

[47911]

Эм. Сайты: wordpress, joomla 3 - собственно самими разработчиками должно всё стоять.

[47911]

ThunderCat, проблема, после рассмотрения, была клалифицированна в "слишком много обращений". Я думал что база настроено нормально. И когда она потихоньку начинает улетать в нирвану - собственно подумал что дело в количестве обращений - поднимается вопрос про кешер.

[FanatPHP]

проблема только в том, что "кэшер" - это не то что ты думаешь.
Это не волшебная палочка, которую воткнул в код и бумц - всё залетало

[47911]

FanatPHP, знаю.

[FanatPHP]

Если совсем методом тыка, то попробуй увеличить innodb_buffer_pool_size

Но вообще надо конкретно разбираться. И это тоже не так что спросил на форуме, сказали какую кнопку нажать, и всё залетало

[47911]

Ну. там много таблиц с MyISAM типом, т.к. оба типы были доступны для использования, и по умолчанию создаётся MyISAM. Так они и накопились. Просто это никто не трогал

И да. Я пробовал.

[ThunderCat]

47911, Вордпресс мягко говоря далек от оптимальности как в плане построения структуры, так и в плане архитектуры приложения в целом. То есть если вам надо достать из 10 таблиц 50 связанных столбцов - будьте уверены, у вас будут в лучшем случае 10 отдельных запросов. В худшем - 10^50. То есть все что можно сделать неоптимально - будет сделано неоптимально. И это не баг, это фича. В чистом виде вп - движок блогов, который весьма простая структура, все что вы вешаете сверху - обычно сделано с расчетом - "ну, от еще десятка запросов на наш плагин сильно нагрузка не поднимется"... Вооот... И когда таких плагинов 10... Ну вы поняли...

[ThunderCat]

47911,

300 сайтов. База сжирает весь процессор. Вроде нормально оно настроено. -> подозрение на количество заходов. - идея об кешере.

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

[47911]

ThunderCat,
ну. Там 90% от вордпресовских - списки статей(т.е. блоги). + до 5 плагинов. В основном до 3.

[47911]

Притом возникло после обновления. Подозрение щас пало на ядро.
Linux 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64
До обновления небыло такой проблемы. Но статистики нагрузки нету до обновления. Т.е. щас 2 подозреваемых.

[47911]

Вообщем. Проблема была в оперативе(одна из 16-и плашек глючила).

https://debianforum.ru/index.php/topic,16064.0.htm...

edac-util -v

И немного подробнее: в IPMI есть логи, в которых подобная инфа вылезает, если что не так. Собственно - вынули и всё в порядке.

[FanatPHP]

47911, напиши в виде ответа

Answer 2

[nokimaro]

1. OPCache для кеширования байт-кода PHP. Удивительно если оно не включено.
Для использования не требуется менять скрипты.

2. Redis или memcache для кеширования данных, в частности результатов запросов из БД. Естественно разработчики должны написать нужный код чтобы кеширование имело эффект.

3. Для сайтов под wordpress обязательно подключить и настроить любой популярный кеш-плагин. Например https://ru.wordpress.org/plugins/wp-super-cache/

4. Почитать что-то для понимания что такое кеширование и как оно может ускорить приложение https://ruhighload.com/search?q=Кэширование

p.s. никакое кеширование не победит кривизну рук разработчиков которые делают запросы к БД с fullscan без использования индексов.

Answer 3

[ThunderCat]

Как я понял есть:
- APC
- XCache
- OPCache
- eAccelerator (вроде не развивается с 2016)

Из них только OPCache более-менее актуален, а в 7 ветке это уже излишне в принципе.

- memchached (ставится в связке с кем-то из выше изложенных)

*memcached не относится к кэшированию кода, это хранилище. Если нужно - лучше использовать редис или какие-то альтернативы посовременнее.

Comments

[47911]

редис ?
Можно поподробнее?
И какие альтернативы?(чтобы почитать)

а в 7 ветке это уже излишне в принципе.

эм. Там вроде сказано про 7.4 А у меня стоит несколько версий php, подключаются для разных сайтов

[ThunderCat]

https://www.google.ru/search?q=redis+%D0%B0%D0%BB%...

[ThunderCat]

47911,

ам вроде сказано про 7.4

Учитесь пользоваться гуглом, это же не сложно, буквами написать вопрос... В седьмой ветке он по умолчанию идет в комплекте и включен. можно проверить что работает конкретно у вас:
var_dump(opcache_get_status());

[47911]

ThunderCat, Спасибо за пояснение.

Answer 4

[47911]

Вообщем. Проблема была в оперативе(одна из 16-и плашек глючила).

тынц

edac-util -v

И немного подробнее: в IPMI есть логи, в которых подобная инфа вылезает, если что не так. Собственно - вынули и всё в порядке.

Comments

[Everything_is_not_so_bad]

вопрос: какой лучше?

Вообщем. Проблема была в оперативе(одна из 16-и плашек глючила).

Не понял связи между вопросом и ответом.

[47911]

Капитан Пронин, грешили на "неоптимизацию". А оказалось: в железе дело было. И что "ту нагрузку, которую видели" - это не к коду вопрос.

[Everything_is_not_so_bad]

47911,
В заготовке:

Какой кешер для php лучше? Как выбрать?

Так при чём тогда проблема с оперативкой? Если глючит, то при чём тогда выбор инструмента для кеширования?

[47911]

Капитан Пронин, притом, что она, из-за своей неисправности, давала нагрузку на сервер. Мы думали: не оптимизированно на сервере. Сайты однотипные(3-5 разновидностей), и не был установлен кешер. Вот поэтому и вопрос про кешер. После замены повреждённого - загрузка спала. Значит дело было не в коде. Но Кешер всёже поставили.

[Everything_is_not_so_bad]

47911, правильный ответ - когда он по теме. А так, получается, решали проблему молотка.

[Everything_is_not_so_bad]

Так что FanatPHP был прав.

[47911]

Капитан Пронин, И да. Проблема была найдена спустя некоторых попыток понять: что происходит. Вот почему: вопрос про одно, а ответ про другое. Ты между этими вещами не читал сообщения. Если кратко: Сначала был спор: "ты ничего не понимаешь, задаёшь тупые вопросы, надо смотреть сам сайт(ы), вордпресс = не оптимизирован", а привело к тому, что "сайт не виноват, и кешер не помог бы(и не помог по факту)" а "виновата одна плашка оперативки из 16 - вынул и всё в порядке."