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/
la source
Réponses:
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
Apache
PHP
Tweaks OS
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.
la source
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.
la source
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?).
la source