Je recherche des ressources sur la façon de développer notre configuration de serveur.
Nous avons actuellement un serveur dédié avec Rackspace au Royaume-Uni de la spécification suivante:
HPDL385_G2_PrevGen
HP Single Dual Core Opteron 2214 (2,2 GHz)
4 Go de RAM
2x 10000 disques SCSI en RAID 1
Notre trafic peut atteindre 550 000 UV par mois.
Le site fonctionne avec une configuration PHP et MySQL. La base de données obtient un martèlement absolu, nous avons de nombreuses requêtes complexes joignant des tables multilpe.
Nous utilisons APC pour la mise en cache PHP.
J'arrive au stade où j'ai fait autant d'optimisation des bases de données et des requêtes que possible et je me demande quelle devrait être la prochaine étape ...
J'ai regardé memcache, mais j'ai l'impression que son nécessite une grande quantité de RAM et idéalement une boîte dédiée ....
La prochaine étape est donc d'avoir deux cases; un pour la base de données, un pour Apache? Ou y a-t-il une étape que j'ai négligée.
Notre charge se situe généralement autour de la barre des 2, mais elle est actuellement à 20!
Quelques graphiques de Munin:
la source
Réponses:
Achetez du matériel, mais mettez-le dans votre laboratoire de test et non dans le centre de données. Insistez ensuite votre application sur diverses combinaisons matériel / logiciel jusqu'à ce que vous en trouviez une raisonnable qui fera ce que vous voulez.
Bien sûr, vous devrez concevoir quelque chose qui peut créer un faux trafic sur une base de données de type production exécutant une copie de test de votre application. Mais qui a dit que ce serait facile.
Si vous ne faites pas cela et faites simplement des choses en production, vous ne savez pas si cela va fonctionner ou non, et vous avez peut-être dépensé BEAUCOUP d'efforts d'ingénierie pour implémenter des choses comme les caches (qui viendront avec leur juste part). de bugs!) sur quelque chose qui n'aide pas.
Testez, testez et testez plus. N'effectuez pas de modifications matérielles / logicielles en production tant que vous ne disposez pas de bonnes données de performances montrant qu'elles sont susceptibles d'améliorer considérablement les choses. L'effort d'ingénierie est coûteux, le matériel de test ne l'est pas (en particulier).
Memcached n'est qu'une option, et vous n'aurez probablement pas à l'envisager jusqu'à ce que la mise en cache de la base de données fonctionne de manière optimale. Cela signifie le placer sur une boîte dédiée (64 bits, bien sûr) avec une quantité raisonnable de RAM (pas 4G - les ordinateurs portables en ont de nos jours; la 32G est certainement abordable) et le régler de manière appropriée.
Vous n'avez pas mentionné la taille de votre base de données, mais si cela est possible, vous voudrez essayer de l'obtenir entièrement en RAM (ou au moins les bits chauds). Obtenir votre base de données entièrement dans ram fera complètement disparaître les opérations d'E / S de lecture et cessera donc d'être un goulot d'étranglement.
Profilez vos requêtes de base de données. Il existe des outils pour faire cela - vous devriez pouvoir simuler la charge de production dans votre environnement de test. L'astuce consiste à éviter les requêtes lentes et à garantir que les requêtes fréquemment exécutées sont rapides.
Si vos problèmes de performances sont liés aux synchronisations d'E / S, parce que vous effectuez simplement trop de transactions pour la base de données, assurez-vous que vous utilisez un contrôleur RAID de batterie qui se comporte correctement (parlez-en à votre fournisseur). Ils donnent beaucoup plus d'opérations d'écriture d'E / S que celles qui ne sont pas sauvegardées par la batterie (car les données doivent uniquement être mises en cache avant que le système d'exploitation n'obtienne la confirmation). Sinon, si vos données importent peu, pensez à assouplir les paramètres de durabilité de la base de données (synchronisation innodb lors de la validation).
la source
En recherchant des solutions de mise en cache, comme beaucoup d'autres l'ont suggéré ici, vous pouvez vous attendre à finir avec environ 10% de la charge que vous avez aujourd'hui, peut-être moins.
Cependant, cela dépend du type de services que vous exécutez sur votre machine. Vous pouvez faire beaucoup de choses avec memcached sans beaucoup de RAM.
Vous devez essayer de profiler les requêtes de base de données qui prennent le plus de temps, soit en utilisant le journal des requêtes lentes de MySQL (ou l'équivalent pour votre base de données), soit en utilisant un outil tel que mytop . De plus, la
EXPLAIN SELECTsyntaxe de MySQL peut être utile.La mise en cache des résultats de quelques requêtes MySQL sélectionnées (même pour une courte période) peut vraiment améliorer considérablement vos performances.
la source
Je fais beaucoup de performances et de travail d'évolution et ce que j'ai découvert, c'est que:
Chaque charge d'application est unique
Les réponses génériques comme ajouter plus de RAM, obtenir un autre serveur, faire y, essayer x sont souvent des leçons de frustration et laisser aux configurations alambiquées.
Mesurer les bonnes choses
L'un des plus grands défis consiste à déterminer quels repères sont importants. Cela nécessite souvent un pas en arrière et vous devez vous mettre à la place de votre client. Parfois, la conception simplifiée du site change et signifie d'énormes avantages pour le visiteur Web. C'est pourquoi j'aime les outils comme YSlow! qui se concentrent davantage sur l'expérience de l'utilisateur final plutôt que sur le niveau du serveur. Une fois que vous avez décidé quelle est la bonne référence pour votre site, vous pouvez commencer à l'optimiser. Les repères peuvent être le temps total de chargement de la page, la taille totale de la page, l'efficacité du cache, la latence du site, etc. Vous devez choisir celui qui convient à votre application.
Écrous et boulons
Celui que vous suivez les bons repères, commencez à un niveau très bas. J'aime utiliser sysstat. Vous pouvez obtenir une multitude d'informations de sysstat et vous aider à déterminer quel système peut limiter les performances globales de l'application. Généralement, je résume les problèmes de performances dans:
À l'aide de sysstat et d'autres outils, vous pouvez commencer à diviser les cheveux et trouver le système qui limite les performances.
Par exemple, j'ai vu des serveurs très chargés échouer en raison de la configuration de leur application. Une mauvaise mise en cache, le manque d'en-têtes expirés sur le contenu statique, l'utilisation de HTTP par rapport aux inclusions de fichiers, etc. ont toutes contribué aux mauvaises performances de l'application. La résolution de ces problèmes d'application n'a nécessité aucune modification matérielle. Dans d'autres cas, j'ai vu les disques au maximum malgré des tonnes de mise en cache. Le passage à des disques plus rapides a résolu le problème.
Rincer et répéter
Souvent, lors du réglage des applications, vous déboucherez un goulot d'étranglement pour n'en trouver qu'un autre. C'est pourquoi je recommande d'essayer de surveiller ce que vous syntonisez.
Par exemple, supposons que vous résolviez un problème d'E / S disque mais que votre application soit toujours lente. Vous pensez peut-être que vous avez gaspillé vos efforts, mais ce qui se passe, c'est que vous avez simplement frappé un autre goulot d'étranglement. En surveillant attentivement les E / S de disque, vous pouvez être sûr que vous améliorez les E / S de disque même si vos analyseurs de performances d'application importants ne changent pas.
Obtenez les bons outils
Assurez-vous que vous utilisez les bons outils pour le travail. La surveillance, les tests, l'analyse comparative, le profilage et d'autres techniques d'optimisation disposent tous d'une variété d'outils. Trouvez l'outil qui correspond le mieux à votre situation.
Règles de base
Bien que chaque application soit unique, je trouve certains points de départ standard:
Vos prochaines étapes
Si vous ne trouvez pas votre goulot d'étranglement, l'ajout d'un serveur peut ne pas aider beaucoup. Pour résoudre les E / S sur disque, vous pouvez avoir besoin d'un autre serveur ou SAN. Si vous avez un goulot d'étranglement, un autre serveur résoudra le problème uniquement en ce qu'il ajoute plus de RAM. Déplacement assez coûteux par rapport à l'ajout de plus de RAM à votre serveur existant.
Solution rapide
Plus de déploiement. J'ai dû faire cela quand il semble que la pile d'applications soit le problème. Charge essentiellement le CPU, la RAM et le disque IO (RAID 10, 15K SCSI ou SSD). Allez gros sur le matériel, puis commencez à régler. Cela vous maintient à flot jusqu'à ce que vous résolviez les problèmes.
la source
Je dirais que la prochaine étape devrait être la mise en cache (mise en cache des données et / ou mise en cache des pages en fonction de vos fonctionnalités). Si memcached semble trop complexe, vous pouvez commencer avec des solutions de mise en cache de données simples comme PEAR Cache Lite qui ne nécessitent que quelques lignes de code mais qui pourraient faire une énorme différence. La mise en cache des pages (ou parties de page) est prise en charge par le moteur de modèle Smarty par exemple.
Une fois que la mise en cache ne le coupe plus, vous pouvez augmenter la quantité de serveur car il ne reste plus rien.
la source
Si vous avez suffisamment de RAM libre, memcached vous aidera même sur la même boîte. Essayez de mettre en cache plusieurs requêtes les plus lourdes et de voir ce qui se passera. De plus, Apache est trop lourd, utilisez plutôt nginx ou lighttpd (avec une application PHP fonctionnant via FastCGI, voir php-fpm ).
la source
Commencez la mise en cache, mais ignorez MySQL pour le moment. Sérieusement.
La règle devrait être - arrêtez une demande LE PLUS TÔT POSSIBLE. Ainsi, un proxy inverse ou une mise en cache appropriée au niveau Apache va vous obtenir les meilleurs résultats, puis la mise en cache des résultats au niveau sql DANS l'application, puis la mise en cache au niveau sql;)
Plus vous arrêtez une demande tôt, moins vous avez de frais généraux. Niveau de cache de sortie - même PHP n'a pas besoin de s'exécuter, pour ainsi dire.
la source