Cela dépend vraiment de votre charge de travail.
pour la partie L
- avoir beaucoup de mémoire,
- si vous pouvez dépasser 4 Go, optez pour 64 bits.
- pour les partitions où votre contenu, journaux et données MySQL sont des options de montage: noatime, nodiratime.
- utiliser des disques physiques / ensembles de raid distincts, idéalement conserver les données SQL, les journaux, le contenu que vous servez - chacun sur une broche distincte.
pour la partie A de votre pile - vous pouvez peut-être le remplacer complètement par nginx ou lighthttpd , ou peut-être simplement laisser Apache pour le contenu dynamique et avoir un serveur séparé (comme ces deux ou mathopd ) pour le contenu statique. Jetez un œil ici pour plus d'options. Si vous allez exécuter à la fois Apache et un autre serveur dans la même boîte, une deuxième adresse IP sera utile. Pour diminuer la latence pour l'utilisateur final, utilisez http / 1.1 avec keep-alive. Pensez à utiliser un CDN pour le contenu statique.
pour la partie M de votre lampe - jetez un oeil sur mysqlperformanceblog . du haut de ma tête:
- consigner les requêtes lentes,
- donner assez de mémoire,
- pensez à utiliser innodb.
- si vous avez beaucoup de texte à rechercher - utilisez sphinx et disposez d'un travail par lots qui reconstruit l'index.
- envisagez de supprimer les requêtes qui durent plus de XYZ secondes. Il vaut mieux bouleverser 1% des utilisateurs que de mettre l'ensemble du site hors service aux heures de pointe. Mais cela dépend vraiment si vous traitez des transactions en espèces ou montrez de belles photos.
- utilisez memcached si vous le pouvez, pour mettre en cache le résultat de requêtes SQL plus «coûteuses». N'oubliez pas d'invalider le cache lorsque vous modifiez le contenu de SQL. D'un autre côté, j'ai assez peu de sites où toutes les données tiennent confortablement en mémoire et pour cela MySQL est rapide et il n'y a pas besoin de cache supplémentaire.
pour P
- définir le délai d'exécution pour les scripts.
- pensez à utiliser un cache d' accélérateur / opcode PHP . J'étais assez satisfait de xcache , mais je ne l'utilise pas maintenant.
- si vous avez un traitement intensif du processeur - cachez les résultats et stockez-les dans SQL ou memcached
Pas vraiment une astuce de performance, mais prenez des sauvegardes hors site. Vraiment.
Je suggère vraiment de séparer MySQL et Apache / PHP sur deux machines différentes.
Par exemple, j'avais une machine (C2D E6600) qui atteignait toujours 2,0 et au-dessus de la moyenne de charge. J'ai installé MySQL sur une deuxième machine (P4C 3Ghz) et après cela, les deux moyennes de charge ne sont pas passées au-dessus de 0,2-0,3. Je suis donc passé d'un site très lent à un site rapide avec deux serveurs ayant beaucoup de marge de performance.
la source
Pour la partie P, vous pouvez envisager la mise en cache d'opcode avec ie APC . On pourrait également considérer mod_fastcgi avec php au lieu du mod_php par défaut.
la source