Optimiser apache / php / mysql fonctionnant sur VPS pour une charge lourde

Question sur l'optimisation d'un serveur apache / mysql sur un VPS avec 512m de RAM. Sous charge normale, tout fonctionne rapidement, aucun retard de connexion. Cependant, lorsque nous obtenons nos jours de trafic intense (50 000 visites et plus), le site rampe et il faut 30 secondes et plus pour récupérer le contenu d'Apache.

Le site fonctionne sur Expression Engine (CMS) (en PHP) et j'ai suivi leur guide d'optimisation des charges lourdes. J'ai googlé et suivi pas mal de choses avec Apache avec un peu de chance, pour en arriver là où il est maintenant, mais j'ai besoin d'obtenir des temps de réponse constants.

Je suppose que cela est différent de la question `` optimiser pour une faible mémoire '' ici car j'ai suffisamment de RAM (pour ce que j'essaie de faire), j'ai juste besoin que le serveur ne s'étouffe pas sous une lourde charge.

Des recommandations?

Pour PHP, il y a 2 choses importantes qui augmenteront la capacité:

1. PHP Caching avancé (APC) comme cela a été mentionné. C'est ce que nous utilisons chez Yahoo !. Il existe d'autres projets similaires, mais celui-ci est le bébé de Rasmus.
2. FastCGI au lieu de mod_php. Il y a un débat sur cette question car mod_php est généralement le plus rapide. Cependant, je suppose que vous avez un seul serveur Apache fournissant à la fois du contenu PHP dynamique et des actifs statiques (JS, CSS, flash, images, PDF, etc.). Les requêtes pour ces actifs statiques n'ont pas besoin de consommer autant de mémoire, mais parce que PHP est un module, il se trouve dans chaque thread Apache.

Pour Apache:

1. Utiliser MPM de travailleur
2. Activer KeepAlive

Vous pouvez également aller jusqu'à envisager de passer d'Apache à Lighttpd ou Nginx . J'adore Apache. J'utilise le fou de bon nombre de ses fonctionnalités avancées. J'accepte ses frais généraux parce que j'ai besoin de ce qu'il offre. Pour la pile LAMP commune, c'est plus que ce qui est nécessaire et un gaspillage de ressources.

Pour MySQL:

1. Vos efforts d'optimisation porteront leurs fruits 10 fois lorsqu'ils seront analysés et corrigés, au lieu de modifier vos valeurs my.cnf. Je ne dis pas qu'il n'est pas important que votre cache, vos connexions, etc. soient corrects ... mais pour la plupart des gens, ce n'est que 9% du problème.
2. Pendant votre QA, activez le journal général des requêtes sur votre mysqld de transfert / dev pour capturer toutes les requêtes envoyées. (Ne faites pas ça sur votre serveur mysql de production!)
3. Utilisez EXPLAIN pour analyser les requêtes. Surtout si vous utilisez un framework avec un ORM (résume la base de données et vous empêche d'écrire votre propre SQL), vous devrez nettoyer les JOIN superflus, les SELECTs sans clause WHERE, les ORDER BY qui induisent `` l'utilisation du tri de fichiers '' et les requêtes qui n'utilisent aucun index.
4. Si vous utilisez MySQL 5.1, profitez du profileur de requêtes .

Les autres outils à considérer sont mk-visual-expliquer

J'ai cité 10 grandes références. Ces choses devraient vous faire fredonner. Veuillez nous faire savoir comment cela se passe.

Déplacez vos fichiers de session PHP vers un tmpfs , utilisez APC (ou autre) et supprimez tous les modules PHP dont vous n'avez pas besoin. Supprimez tous les modules Apache dont vous n'avez pas besoin / que vous n'utilisez pas.

Pour créer un tmpfs (un répertoire en RAM!)

mkdir /tmpfs; chmod 777 /tmpfs
mount -t tmpfs -o size=256M tmpfs /tmpfs

Dans / etc / fstab, ajoutez la ligne ci-dessous pour la créer au redémarrage!

tmpfs     /tmpfs    tmpfs   size=256m,mode=0777    0       0

Dans /etc/apache2/php.ini ajustez pour stocker vos sessions en RAM (tmpfs)!

session.save_handler = files
session.save_path = "/tmpfs"

Remarque: Avec vos fichiers PHP ET vos fichiers de session en RAM, vous touchez à peine le disque!

Utilisez expires_module dans apache pour que les navigateurs mettent en cache la plupart des choses.

ExpiresActive On
ExpiresDefault "access plus 90 days"
ExpiresByType image/gif "access plus 90 days"
ExpiresByType image/ico "access plus 90 days"
ExpiresByType image/png "access plus 90 days"
ExpiresByType image/jpeg "access plus 90 days"
ExpiresByType image/x-icon "access plus 90 days"
ExpiresByType text/css "Access plus 90 days"
ExpiresByType text/html "Access plus 90 days"
ExpiresByType application/x-shockwave-flash "Access plus 90 days"
ExpiresByType application/x-javascript "Access plus 90 days"

N'utilisez pas de fichiers .htaccess ! Au lieu de cela, codez-les en dur dans le fichier de configuration vhost! Éliminera / réduira considérablement les vérifications de disque pour toutes les requêtes http ... cela s'ajoute vraiment.

Options FollowSymLinks 
AllowOverride None

Exemple de .htaccess utilisé dans votre fichier vhost.conf ...

<Directory /home/user/www/site.com/secure>
    Order Allow,Deny
    Deny from All
</Directory>

Quelques choses me viennent à l'esprit.

Le cache Opcode est toujours une bonne idée. Je préfère http://eaccelerator.net/ à APC. Si vous n'avez pas développé avec APC en cours de route, essayer de l'ajouter est presque toujours douloureux. L'accélérateur tout en n'étant pas aussi sophistiqué semble fonctionner.

Un proxy inverse est également une bonne idée, mais vous devez surveiller l'utilisation de la RAM. Je trouve qu'Apache 2.2 avec mpm-worker prend lui-même une bonne quantité de RAM. Dans votre cas, je recommanderais quelque chose de plus léger comme Nginx et exécuterais Apache avec PHP en tant que FASTCGI ou le laisserais simplement selon le processus. L'idée d'utiliser Varnish, Squid, Nginx, etc. est de leur faire servir du contenu statique, gérer les connexions des utilisateurs et ne transmettre que les requêtes PHP à Apache que vous traitez comme un serveur d'applications.

Si vous utilisez une version assez récente de Mysql 5.1, comme au moins 5.1.24, vous avez maintenant accès à des journaux lents d'une seconde. Je commencerais long_query_time à 1 ou 2, puis le ramènerais à 0,5 lorsque vous aurez une idée des très longues. Il y a aussi beaucoup d'informations de réglage générales sur le net pour Mysql, mais vous n'avez pas la RAM pour faire beaucoup. Avez-vous augmenté l'un des paramètres par défaut? La plupart des fichiers my.cnf par défaut sont configurés pour utiliser environ 64 Mo de RAM. C'est à tout le moins que je ferais passer le key_buffer de 16 Mo à 64 Mo.

De plus, utilisez-vous des tables Myisam ou Innodb? Si vous gardez la session dans la base de données, vous voudrez changer la table de session en Innodb (ou en faire un cookie à la place) plutôt que de lui laisser une table Mysiam qui fait un verrouillage au niveau de la table plutôt qu'un verrouillage au niveau des lignes. Fondamentalement, toute table contenant plus de 20% d'écriture et 80% de lecture est susceptible de passer à Innodb. N'oubliez pas que vous devrez équilibrer la quantité de RAM entre les tables Myisam et les tables Innodb car les tampons de chacune sont configurés séparément.

Et enfin, 512 Mo de RAM supplémentaires iraient un long chemin dans votre configuration ou même un autre VPS de 512 Mo pour exécuter Mysql si c'est moins cher ou à peu près le même prix. Je pencherais en fait vers une deuxième instance, car cela doublera les E / S de disque disponibles. L'un des problèmes avec les serveurs VPS est que votre IO n'est pas protégé contre les autres personnes sur le même serveur physique.

Hmmm mon post est un peu éparpillé, mais vous donne beaucoup d'endroits à regarder. Bonne chance.

• Utilisez un cache d'opcode pour php comme apc.
• Utilisez un accélérateur http comme le calmar ou le vernis.

Dans une situation de faible mémoire (512 Mo est faible, pour un serveur à fort trafic), il convient de considérer votre choix de serveur Web et de moteur de base de données.

Lighttp est plus léger hors de la boîte qu'Apache peut généralement être fabriqué après de nombreux ajustements, et il existe même des options plus légères. Ce n'est bien sûr pas possible s'il existe des fonctionnalités Apache dont vous dépendez et qui ne sont pas prises en charge sur d'autres serveurs.

sqlite est beaucoup plus serré que mySQL, et plus rapide dans de nombreuses conditions également. Vérifiez si le moteur que vous utilisez le supporte aussi bien et s'il essaie.

L'autre option, l'option facile, consiste à obtenir plus de RAM dans la machine virtuelle si vous pouvez vous le permettre.

Au-delà des grandes suggestions ici, il convient de noter que tous les VPS ne sont pas créés égaux. D'après mon expérience, PHP s'est avéré être un processeur lourd.

Un Wordpress AB Benchmark (ab -n 500 -c 25 http://domain.com/index.php ) de nginx / apc / phpfpm / mysql (local) sur EC2 a généré ~ 2 requêtes / seconde sur leur niveau d'entrée "2GB RAM / 1 Compute Unit Server ".

Le même Benchmark exécuté sur la même pile exacte (déployée par script sur un système d'exploitation identique) sur un Rackspace Cloudserver de 512 Mo renvoie ~ 80 req / seconde. Donc 4x moins de RAM, 40x de performances dans cette expérience rudimentaire.

En regardant en haut pendant l'AB, vous voyez que EC2 ne pouvait tout simplement pas gérer la concurrence, et atteindrait immédiatement 100% de charge CPU et se bloquerait. Affichage supérieur sur le serveur de 512 Mo (processeur quadricœur virtualisé) pendant le même benchmark, les cœurs atteindraient ~ 60% de charge et géreraient en douceur le benchmark.

Les VPS sont extrêmement faciles à tourner et à éteindre sans engagement, cela ne fait pas de mal de mettre à l'essai l'infrastructure dans laquelle votre VM / VPS réside!

EDIT 1: De plus, la petite instance "High CPU" d'EC2 n'a pu produire que 10 / seconde de requête, le CPU étant toujours le goulot d'étranglement. Ma conclusion était que vous sacrifiez les performances pour la stabilité / robustesse avec EC2, et il y a bien sûr de nombreux cas d'utilisation qui nécessitent un tel environnement.