Comment faire évoluer php5 + MySQL au-dessus de 200 requêtes / seconde?

Je modifie ma page d'accueil pour les performances, actuellement elle gère environ 200 requêtes / seconde sur 3.14.by qui mange 6 requêtes SQL, et 20 req / seconde sur 3.14.by/forum qui est le forum phpBB.

Curieusement, les chiffres sont à peu près les mêmes sur certains VPS et sur un serveur Atom 330 dédié.

Le logiciel serveur est le suivant: Apache2 + mod_php prefork 4 enfants (essayé différents nombres ici), php5, APC, nginx, memcached pour le stockage des sessions PHP.

MySQL est configuré pour consommer environ 30% de la RAM disponible (~ 150 Mo sur VPS, 700 Mo sur serveur dédié)

On dirait qu'il y a un goulot d'étranglement quelque part qui ne me permet pas d'aller plus haut, des suggestions? (c'est-à-dire que je sais que faire moins de 6 SQL le rendrait plus rapide, mais cela ne ressemble pas à un facteur limitant, car sqld ne mange pas plus de quelques% en haut en raison des requêtes mises en cache)

Quelqu'un a-t-il testé que lancer Apache2 pré-forké et laisser juste nginx + php est beaucoup plus rapide?

Quelques repères supplémentaires

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.

Mise à jour: Il semble que le goulot d'étranglement concerne les performances de MySQL sur les données mises en cache. La page avec un seul SQL affiche 354 req / sec, avec 6 SQL - 180 req / sec. Que pensez-vous que je puisse modifier ici? (Je peux débourser 100-200 Mo pour 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/

De toute évidence, il y a beaucoup de choses que vous pouvez essayer. Votre meilleur pari est de chasser vos journaux pour les requêtes qui n'utilisent pas d'index (activer les journaux pour ceux-ci) et d'autres requêtes non optimisées. J'ai compilé une énorme liste d'options liées aux performances au fil des ans, j'ai donc inclus un petit sous-ensemble ici pour votre information - j'espère que cela aide. Voici quelques notes générales sur les choses que vous pouvez essayer (si vous ne l'avez pas déjà fait):

MySQL

• query_cache_type = 1 - le cache des requêtes SQL est activé. S'il est défini sur 2, les requêtes ne sont mises en cache que si l'indication SQL_CACHE leur est transmise. De même avec le type 1, vous pouvez désactiver le cache pour une requête particulière avec l'indicateur SQL_NO_CACHE
• key_buffer_size = 128M (par défaut: 8M) - mémoire tampon pour les index de table MyISAM. Sur les serveurs dédiés, visez à définir key_buffer_size sur au moins un quart, mais pas plus de la moitié, de la quantité totale de mémoire sur le serveur
• query_cache_size = 64M (par défaut: 0) - taille du cache de requête
• back_log = 100 (par défaut: 50, max: 65535) - La file d'attente des demandes de connexion en attente. N'importe que lorsqu'il y a beaucoup de connexions en peu de temps
• join_buffer_size = 1M (par défaut: 131072) - un tampon utilisé lors de l'analyse complète des tables (pas d'index)
• table_cache = 2048 (par défaut: 256) - devrait être max_user_connections multiplié par le nombre maximal de JOIN que contient votre requête SQL la plus lourde. Utilisez la variable "open_tables" aux heures de pointe comme guide. Regardez aussi la variable "open_tables" - elle devrait être proche de "open_tables"
• query_prealloc_size = 32K (par défaut: 8K) - mémoire persistante pour l'analyse et l'exécution des instructions. Augmenter si vous avez des requêtes complexes
• sort_buffer_size = 16M (par défaut: 2M) - aide au tri (opérations ORDER BY et GROUP BY)
• read_buffer_size = 2M (par défaut: 128K) - Aide avec les analyses séquentielles. Augmentez s'il existe de nombreux scans séquentiels.
• read_rnd_buffer_size = 4M - aide la table MyISAM à accélérer la lecture après le tri
• max_length_for_sort_data - taille de ligne à stocker au lieu du pointeur de ligne dans le fichier de tri. Peut éviter les lectures de table aléatoires
• key_cache_age_threshold = 3000 (par défaut: 300) - temps pour garder le cache des clés dans la zone chaude (avant qu'il ne soit rétrogradé pour se réchauffer)
• key_cache_division_limit = 50 (par défaut: 100) - active un mécanisme d'éviction de cache plus sophistiqué (deux niveaux). Indique le pourcentage à conserver pour le niveau inférieur. delay_key_write = ALL - le tampon de clé n'est pas vidé pour la table à chaque mise à jour d'index, mais uniquement lorsque la table est fermée. Cela accélère beaucoup les écritures sur les clés, mais si vous utilisez cette fonctionnalité, vous devez ajouter une vérification automatique de toutes les tables MyISAM en démarrant le serveur avec l'option --myisam-recover = BACKUP, FORCE
• memlock = 1 - processus de verrouillage en mémoire (pour réduire le swapping in / out)

Apache

• changer la méthode de frai (en mpm par exemple)
• désactiver les journaux si possible
• AllowOverride None - dans la mesure du possible, désactivez .htaccess. Il arrête Apache pour rechercher des fichiers .htaccess s'ils ne sont pas utilisés afin d'enregistrer une demande de recherche de fichier
• SendBufferSize - Défini sur le système d'exploitation par défaut. Sur les réseaux encombrés, vous devez définir ce paramètre près de la taille du plus gros fichier normalement téléchargé
• KeepAlive Off (par défaut On) - et installez lingerd pour fermer correctement les connexions réseau et c'est plus rapide
• DirectoryIndex index.php - Gardez la liste des fichiers aussi courte et absolue que possible.
• Options FollowSymLinks - pour simplifier le processus d'accès aux fichiers dans Apache
• Évitez d'utiliser mod_rewrite ou au moins des expressions rationnelles complexes
• ServerToken = prod

PHP

• variables_order = "GPCS" (si vous n'avez pas besoin de variables d'environnement)
• register_globals = Off - en plus d'être un risque pour la sécurité, il a également un impact sur les performances
• Gardez include_path aussi minimal que possible (évite les recherches de système de fichiers supplémentaires)
• display_errors = Off - Désactive l'affichage des erreurs. Fortement recommandé pour tous les serveurs de production (n'affiche pas de vilains messages d'erreur en cas de problème).
• magic_quotes_gpc = Off
• magic_quotes _ * = Off
• output_buffering = On
• Si possible, désactivez la journalisation
• expose_php = Off
• register_argc_argv = Off
• always_populate_raw_post_data = Désactivé
• placez le fichier php.ini où php le recherchera en premier.
• session.gc_divisor = 1000 ou 10000
• session.save_path = "N; / path" - Pour les grands sites, envisagez de l'utiliser. Divise les fichiers de session en sous-répertoires

Tweaks OS

• Montez les disques durs utilisés avec l'option -o noatime (pas de temps d'accès). Ajoutez également cette option au fichier / etc / fstab.
• Ajustez / proc / sys / vm / swappiness (de 0 à 100) pour voir ce qui a les meilleurs résultats
• Utiliser des disques RAM - mount --bind -ttmpfs / tmp / tmp

Si le goulot d'étranglement n'est pas le CPU, alors son IO - soit le réseau ou le disque. Donc .. vous devez voir combien d'E / S se passe. Je n'aurais pas pensé que c'était le réseau (sauf si vous êtes sur une liaison semi-duplex à 10 Mbps, mais cela vaut la peine de vérifier le commutateur au cas où la détection automatique ne ferait pas son travail correctement).

Cela laisse le disque IO, ce qui peut être un gros facteur en particulier sur les VPS. Utilisez sar ou iostat pour jeter un œil aux disques, puis google comment trouver plus de détails si votre disque est utilisé intensivement.

J'examinerais la mise en cache avec Nginx ( memcached ) ou Varnish .

À tout le moins, vous devez serveur des fichiers statiques avec Nginx comme SaveTheRbtz dit.

Comme le serveur ne semble pas poser de problème, le générateur de charge l'est peut-être. Essayez de l'exécuter sur plusieurs machines.

Il me semble que vous atteignez le nombre maximum de connexions qu'Apache permet. Jetez un œil à votre configuration Apache. L'augmentation de la limite du serveur et des clients max devrait aider si vous n'êtes pas déjà lié par une autre limite comme les E / S ou la mémoire. Regardez les valeurs présentes pour mpm_prefork_module ou mpm_worker_module et ajustez en conséquence pour répondre à vos besoins.

ServerLimit 512
MaxClients 512

Cette charge est-elle générée par un outil ou des charges réelles?

Vous voudrez peut-être vérifier memcached. J'ai vu des problèmes à des taux de connexion élevés provoquant une latence dans l'application.

Si vous utilisez un générateur de charge, qu'obtenez-vous en frappant une petite page statique?

Pendant les chargements, vous souhaiterez peut-être vérifier la pile réseau pour les conditions TIME_WAIT. Vous remplissez peut-être votre file d'attente de connexion.

Il y a environ 100 autres raisons et éléments que vous pouvez consulter, mais sans plus d'informations, je lance juste des suppositions à ce stade.

99% des problèmes de temps comme celui-ci remontent à la base de données. Assurez-vous que vos indices de frappe d'abord. Si cela ne fonctionne pas, commencez à mettre en cache tout ce que vous pouvez.

Je vous recommande d'utiliser (si possible) un pool de connexion pour garder la base de données connectée à vos applications Web (pas besoin de se reconnecter à chaque demande). Cela peut faire une énorme différence de vitesse.

Essayez également d'analyser toutes vos requêtes avec EXPLAIN (et pourquoi ne pas profiler vos requêtes avec SHOW PROFILE?).