Long temps d'attente avant la réponse du serveur Apache 2.2 (Gentoo LAMP)

J'ai récemment déplacé le site Web d'un client (en utilisant le CMS concrete5) vers un VPS exécutant Gentoo, Apache 2.2, PHP5 et MySQL 5 et j'ai remarqué que les temps de réponse d'Apache sont assez mauvais (c'était la même chose sur l'ancien serveur) , parfois jusqu'à 8-9 secondes, mais le plus souvent entre 300 ms et 3 secondes (vers 300 ms, cela ne me dérange pas). Je sais que ce n'est pas une latence du réseau, car le serveur a un ping (depuis mon emplacement) d'environ 30 ms.

Voici un exemple des temps (vous pouvez voir que c'est accrocheur après l'attente initiale):

J'utilise APC (bien que je ne sois pas sûr que cela fonctionne correctement ...) et SuExec. Les modules Apache sont:

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

et les modules PHP sont:

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

J'ai gzip activé sur tous les fichiers pertinents.

Apache fonctionne avec prefork et les paramètres de httpd.conf sont les suivants:

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

J'ai remarqué que les pages qui (je pense) sont lourdes de base de données, comme le tableau de bord du CMS, sont généralement plus lentes. J'ai pensé que cela pourrait signifier que MySQL pourrait être optimisé. Je me suis aussi posé des questions sur les modules Apache - je suis confus entre mod_php5, mod_cgi, mod_fastcgi etc etc - il y a des conseils contradictoires partout sur le net quant au meilleur à utiliser.

Voici la sortie de MySQLTuner :

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

J'ai remarqué qu'une page chargée de bases de données était chargée, l'utilisation du processeur a augmenté de 57% (en utilisant le haut) - pour moi, cela suggère qu'il y a des choses MySQL mal optimisées ou que la mise en cache est absolument nécessaire pour accélérer cette configuration.

Toute aide serait très appréciée!

Savez-vous exactement sur quoi les processus de travail d'apache se bloquent? Essayez ceci pour voir:

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

Chargez quelques nouvelles pages (c'est-à-dire non mises en cache localement) dans votre navigateur, CTRL + C pour arrêter strace puis triez les strace.logs en fonction du temps passé sur chaque appel:

for i in `ls /strace/*`; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

Affichez tous les strace.logs avec plus de 1,0 seconde d'appels et effectuez une recherche par heure à partir de la sortie de la commande précédente. Cela vous indiquera l'étape exacte à laquelle ils sont accrochés.

Avez-vous changé de pare-feu comme CSF? J'ai vu ce même problème sur un VPS. Lors du débogage des processus httpd avec strace, cela prenait jusqu'à 5 secondes ou plus lors des appels à gettimeofday. Étrangement, j'ai limité cela à CSF, qui essayait de filtrer l'interface venet0, une interface de bouclage dans des conteneurs OpenVZ ou Virtuozzo. La définition de ce paramètre dans /etc/csf/csf.conf l'a principalement corrigé pour moi:

"ETH_DEVICE_SKIP = "venet0,lo"

Je dis surtout parce que parfois, il y a encore 500-1000 ms d'attente pour que les connexions s'établissent, mais c'est une grande amélioration par rapport à 5000+.

Voici une excellente introduction / procédure pas à pas pour résoudre ces types de problèmes à l'aide de strace.

Maximum possible memory usage: 219.7M (93% of installed RAM)

Ce doit être une boîte VPS bas de gamme?

• Vous voudrez peut-être composer vos paramètres MySQL
• Ajustez Apache pour réduire le nombre de fourches httpd
• Vérifiez si vous pouvez activer l'échange
• APC est-il configuré pour mettre automatiquement en cache les opcodes? Vérifiez en utilisant le script 'apc.php' distribué avec apc.

Vous devez séparer le réseau, apache, mysql et php comme sources de latence.

Si vous pouvez extraire rapidement une image d'Apache (temps très court jusqu'au premier octet), le réseau et Apache sont généralement corrects.

Si vous pouvez tirer une page avec juste une instruction phpinfo (), alors PHP est généralement correct (peut nécessiter quelques ajustements).

Si vous écrivez un test de connexion DB simple et qu'il est rapide, cette couche est généralement correcte également.

Enfin, tirez la page de l'application. S'il est lent, le problème est interne au traitement des applications. Bien que le réglage puisse aider, cela est beaucoup plus difficile à résoudre.

Sans profilage de l'application, il peut être difficile de trouver le problème. Des outils comme NewRelic peuvent aider à résoudre ce problème mais ne sont pas un remède.

Votre application a-t-elle un type de débogage interne pour montrer où le temps est passé?

je suggère d'ajouter une mesure du temps de rendu et de vérifier combien de temps il faut au serveur pour rendre la page HTML pure. Ensuite, vous savez si c'est dans le CMS ou ailleurs. Je parie que mon 2cent n'est pas votre configuration de serveur. / maddin