Как масштабировать php5 + MySQL выше 200 запросов / секунду?

Я настраиваю свою домашнюю страницу для повышения производительности, в настоящее время она обрабатывает около 200 запросов в секунду на 3.14.by, который использует 6 запросов SQL, и 20 запросов / секунду на 3.14.by/forum, который является форумом phpBB.

Как ни странно, цифры примерно одинаковы на некоторых VPS и выделенном сервере Atom 330.

Программное обеспечение сервера следующее: Apache2 + mod_php prefork 4 дочерних (здесь пробовали разные числа), php5, APC, nginx, memcached для хранения сессий PHP.

MySQL настроен на потребление около 30% доступной оперативной памяти (~ 150 МБ на VPS, 700 МБ на выделенном сервере)

Похоже, что где-то есть узкое место, не позволяющее мне подняться выше, какие-либо предложения? (то есть я знаю, что выполнение менее 6 SQL-запросов сделает это быстрее, но это не выглядит ограничивающим фактором, так как sqld потребляет не более нескольких% из-за кэшированных запросов)

Кто-нибудь проверял, что пинать preforked apache2 и оставлять просто nginx + php намного быстрее?

Еще несколько тестов

Small 40-byte static file: 1484 r/s via nginx+apache2, 2452 if we talk to apache2 directly. 
Small "Hello world" php script: 458 r/s via ngin+apache2.

Обновление: кажется, узким местом является производительность MySQL на кэшированных данных. Страница с одним SQL показывает 354 req / sec, с 6 SQL - 180 req / sec. Как вы думаете, я могу настроить здесь? (Я могу раскошелиться на 100-200Mb для MySQL)

[client]
port        = 3306
socket      = /var/run/mysqld/mysqld.sock

[mysqld_safe]
socket      = /var/run/mysqld/mysqld.sock
nice        = 0

[mysqld]
default-character-set=cp1251
collation-server=cp1251_general_cs

skip-character-set-client-handshake

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
skip-external-locking

bind-address        = 127.0.0.1

key_buffer      = 16M
max_allowed_packet  = 8M
thread_stack        = 64K
thread_cache_size   = 16
sort_buffer_size    = 8M
read_buffer_size    = 1M

myisam-recover      = BACKUP
max_connections        = 650
table_cache            = 256
thread_concurrency     = 10

query_cache_limit       = 1M
query_cache_size        = 16M

expire_logs_days    = 10
max_binlog_size         = 100M

[mysqldump]
quick
quote-names
max_allowed_packet  = 8M

[mysql]
[isamchk]
key_buffer      = 8M

!includedir /etc/mysql/conf.d/

Очевидно, что вы можете попробовать многое. Лучше всего преследовать ваши журналы для запросов, которые не используют индексы (включите журналы для них) и других неоптимизированных запросов. За эти годы я собрал огромный список параметров, связанных с производительностью, поэтому я включил здесь небольшое подмножество для вашей информации - надеюсь, это поможет. Вот некоторые общие замечания о том, что вы можете попробовать (если вы еще этого не сделали):

MySQL

• query_cache_type = 1 - кеш запросов SQL включен. Если задано значение 2, запросы кэшируются только в том случае, если им передается подсказка SQL_CACHE. Аналогично с типом 1 вы можете отключить кеш для конкретного запроса с помощью подсказки SQL_NO_CACHE
• key_buffer_size = 128M (по умолчанию: 8M) - буфер памяти для индексов таблиц MyISAM. На выделенных серверах установите для параметра key_buffer_size не менее четверти, но не более половины общего объема памяти на сервере.
• query_cache_size = 64M (по умолчанию: 0) - размер кеша запросов
• back_log = 100 (по умолчанию: 50, макс .: 65535) - очередь ожидающих запросов на подключение. Имеет значение только тогда, когда есть много соединений в короткие сроки
• join_buffer_size = 1M (по умолчанию: 131072) - буфер, который используется при полном сканировании таблицы (без индексов)
• table_cache = 2048 (по умолчанию: 256) - должно быть max_user_connections умножено на максимальное количество JOIN, которое содержит ваш самый тяжелый SQL-запрос. Используйте переменную open_tables в часы пик в качестве руководства. Также посмотрите на переменную "open_tables" - она ​​должна быть близка к "open_tables"
• query_prealloc_size = 32K (по умолчанию: 8K) - постоянная память для разбора и выполнения операторов. Увеличение при наличии сложных запросов
• sort_buffer_size = 16M (по умолчанию: 2M) - помогает в сортировке (операции ORDER BY и GROUP BY)
• read_buffer_size = 2M (по умолчанию: 128K) - Помогает при последовательном сканировании. Увеличьте, если есть много последовательных сканирований.
• read_rnd_buffer_size = 4M - помогает ускорить чтение таблицы MyISAM после сортировки
• max_length_for_sort_data - размер строки для хранения вместо указателя строки в файле сортировки. Можно избежать случайного чтения таблицы
• key_cache_age_threshold = 3000 (по умолчанию: 300) - время для хранения кеша ключей в горячей зоне (до того, как она разогреется)
• key_cache_division_limit = 50 (по умолчанию: 100) - включает более сложный механизм удаления кеша (два уровня). Обозначает процент для нижнего уровня. delay_key_write = ALL - буфер ключа не очищается для таблицы при каждом обновлении индекса, а только при закрытии таблицы. Это значительно ускоряет запись на ключи, но если вы используете эту функцию, вы должны добавить автоматическую проверку всех таблиц MyISAM, запустив сервер с параметром --myisam-recovery = BACKUP, FORCE
• memlock = 1 - блокировка процесса в памяти (для уменьшения подкачки / выгрузки)

апаш

• изменить метод порождения (например, в mpm)
• отключить журналы, если это возможно
• AllowOverride None - по возможности отключайте .htaccess. Он останавливает apache для поиска файлов .htaccess, если они не используются, поэтому сохраняет запрос поиска файла
• SendBufferSize - установить в ОС по умолчанию. В перегруженных сетях вы должны установить этот параметр близко к размеру самого большого файла, обычно загружаемого
• KeepAlive Off (по умолчанию включен) - и установите lingerd для правильного закрытия сетевых подключений и работает быстрее
• DirectoryIndex index.php - сохранить список файлов как можно более коротким и абсолютным.
• Опции FollowSymLinks - для упрощения процесса доступа к файлам в Apache
• Избегайте использования mod_rewrite или хотя бы сложных регулярных выражений
• ServerToken = прод

PHP

• variable_order = "GPCS" (если вам не нужны переменные окружения)
• register_globals = Off - помимо угрозы безопасности, он также влияет на производительность
• Держите include_path как можно меньше (избегая дополнительных поисков файловой системы)
• display_errors = Off - отключить отображение ошибок. Настоятельно рекомендуется для всех производственных серверов (не отображает ужасные сообщения об ошибках в случае возникновения проблем).
• magic_quotes_gpc = Off
• magic_quotes _ * = Off
• output_buffering = On
• Отключите ведение журнала, если это возможно
• expose_php = Off
• register_argc_argv = Off
• always_populate_raw_post_data = Off
• Поместите файл php.ini, где php будет искать его в первую очередь.
• session.gc_divisor = 1000 или 10000
• session.save_path = "N; / path" - для больших сайтов рассмотрите возможность его использования. Разбивает файлы сессий на подкаталоги

ОС твики

• Монтируйте используемые жесткие диски с опцией -o noatime (без времени доступа). Также добавьте эту опцию в файл / etc / fstab.
• Настройте / proc / sys / vm / swappiness (от 0 до 100), чтобы увидеть, что дает лучшие результаты
• Использовать диски RAM - монтировать --bind -ttmpfs / tmp / tmp

Если узким местом является не процессор, то его IO - либо сеть, либо диск. Итак ... вам нужно посмотреть, сколько IO происходит. Я бы не подумал, что это сеть (если вы не используете полудуплексный канал 10 Мбит / с, но стоит проверить коммутатор на случай, если функция автоопределения не выполняет свою работу правильно).

Это оставляет дисковый ввод-вывод, который может быть важным фактором, особенно на VPS. Используйте sar или iostat, чтобы взглянуть на диски, а затем Google, как найти более подробную информацию, если ваш диск интенсивно используется.

Я хотел бы изучить кеширование с помощью Nginx ( memcached ) или Varnish .

По крайней мере, вы должны сервер статических файлов с Nginx, как сказал SaveTheRbtz.

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

Для меня это звучит так, как будто вы подключаетесь к максимальному количеству соединений, которые пропускает Apache. Посмотрите на вашу конфигурацию Apache. Увеличение лимита сервера и максимальное количество клиентов должно помочь, если вы еще не связаны каким-либо другим ограничением, таким как ввод-вывод или память. Посмотрите на значения, присутствующие для mpm_prefork_module или mpm_worker_module и скорректируйте в соответствии с вашими потребностями.

ServerLimit 512
MaxClients 512

Эта нагрузка создается инструментом или реальными нагрузками?

Вы можете проверить memcached. Я видел проблемы с высокой скоростью соединения, что приводило к задержке в приложении.

Если вы используете генератор нагрузки, что вы получаете, когда нажимаете на небольшую статическую страницу?

Во время загрузки вы можете проверить сетевой стек на наличие условий TIME_WAIT. Возможно, вы заполняете свою очередь соединения.

Есть еще около 100 причин и пунктов, на которые вы можете посмотреть, но без дополнительной информации, я просто выбрасываю догадки на данный момент.

В 99% случаев подобные проблемы будут отслеживаться в базе данных. Убедитесь, что ваши индексы попадания в первую очередь. Если это не сработает, начните кэшировать все, что можете.

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

Кроме того, попробуйте проанализировать все ваши запросы с помощью EXPLAIN (и почему бы не профилировать ваши запросы с помощью SHOW PROFILE?).