jeudi 11 octobre 2012

Chronique d'un audit technique #2

Voici donc le deuxième épisode de ces chroniques relatives à l'audit technique que j'ai mené avec mon équipe suite à la baisse de performance très importante constatée sur la solution de e-commerce de l'un de nos clients suite à une montée en version.

Pour ceux qui prenne le train (de 13 h 37 évidement) en route, le début de l'histoire est ici, et pour les autres, nous nous étions quittés la tête remplie de questions (au vu des commentaires) suite à l'audit effectué sur le serveur MySQL.

En effet, ce dernier n'avait rien révélé de significatif, même s'il avait donné lieu à quelques ajustements, puisque les valeurs des variables relatives au moteur innoDb étaient correctes et le cache de requêtes était correctement dimensionné.

De plus, le journal des requêtes lentes ne contenait rien de relatif au problème constaté, tout comme celui des requêtes exécutées sans index, activé pour l'occasion.

Lire la suite

lundi 6 août 2012

Client FastCGI en PHP

La plupart du temps, PHP est utilisé en conjonction avec un serveur HTTP.

Dans ce cas, lorsque le serveur HTTP reçoit d'un client une requête nécessitant l'exécution d'un script PHP, il demande l'exécution du fichier en question à PHP et retourne son résultat au client.

Or, il existe plusieurs façon d'associer PHP à un serveur HTTP, via différentes SAPI.

Ainsi, PHP est par exemple la plupart du temps lié à apache via le module correspondant, tandis que des serveurs plus récents tel que nginx font appel à PHP via le protocole FastCGI.

Dans ce dernier cas, le script PHP est exécuté par un processus indépendant de celui du serveur HTTP et faisant office de serveur.

En tant que tel, il délègue donc l'exécution du script à l'un de ses processus fils et en retourne le résultat au serveur .

Afin d'optimiser les performances, ce serveur peut créer à l'avance lors de son démarrage un certain nombre de processus fils, afin de pouvoir répondre aux requêtes du serveur HTTP le plus rapidement possible.

De plus, il est tout à fait capable de créer des sous-processus supplémentaires en fonction de sa configuration et de la charge qu'il a à supporter.

Cette architecture est donc très efficace et offre de très bonnes performances, mais ce n'est pas son seul atout.

Lire la suite

mardi 5 juillet 2011

Test du serveur http intégré à PHP 5.4

Pour ceux qui ne le sauraient pas encore, PHP 5.4 intégrera nativement un serveur HTTP.

Au premier abord, l'idée peut paraître saugrenue, puisque dans la majorité des cas, PHP est installé via un package binaire qui intègre un serveur HTTP externe tel que apache ou nginx.

Cependant, en y regardant de plus près, le concept est séduisant, car l'installation et surtout la configuration d'un serveur HTTP de ce type peut être longue, fastidieuse et complètement hors de propos dans le cadre du développement d'un projet en PHP.

Il peut donc être intéressant de disposer d'un serveur HTTP intégré au langage et donc capable de s'interfacer directement avec lui sans configuration particulière, afin de gagner du temps.

La version alpha 1, disponible depuis quelques jours, ne dispose pas encore de cet outil, mais je n'ai pas pu résister à la tentation de le tester afin d'en savoir un peu plus à son sujet.

J'ai donc récupéré le code de PHP 5.4 à partir de son dépôt subversion, et quelques minutes de compilation plus tard, je pouvais lancer le serveur HTTP de PHP.

Lire la suite