Forum

Hello,



histoire d'optimiser les performances de mon site sous PHPBoost pour les visiteurs, j'ai pensé à la mise en place d'un CDN tant recommandé par YSlow et PageSpeed.

J'ai alors découvert cirruxcache qui se met en place sur Google App Engine, je vous invite à lire l'article de mon blog (PUB !)



Seulement voilà, comment replacer tous les liens qui pointent vers des objets statiques (css, js, images, ...) par l'adresse de mon CDN (qui les mettra en cache, et les desservira) ?

J'ai pensé au PATH_TO_ROOT, mais c'est une mauvaise idée ...

J'ai vu ensuite quelques astuces avec ob_start, mais j'ai rien compris ...



Si vous avez des idées je suis prenant



See ya.

D'après ce que je comprends sur l'article de blog dont tu parles, l'objectif est de placer l'appli App Engine en reverse proxy sur le contenu dynamique du site, de façon à ce que les pages dynamiques soient tout de même services par PHPBoost.

Je ne sais pas comment se configure l'application GAE en question, mais si tu peux lui dire de faire reverse proxy sur les pages qui matchent un pattern, on peut t'aider à mettre en place le pattern en question. Mais je ne sais pas du tout si c'est comme ça que fonctionne l'application.



Sinon, en mettant en place une telle architecture, je ne pense pas que tu augmenteras les performances mais au contraire, je pense qu'elles seront dégradées. En fait, tu vas probablement améliorer les performances sur le contenu statique mais les massacrer sur le contenu dynamique à cause du proxy (chaque requête va faire deux allers-retours au lieu d'un).

Pour ce qui me concerne, je travaille sur une architecture comparable à celle que j'ai décrite au boulot, tout simplement à cause de la Same origin policy, mais je pense qu'il faut éviter si il n'y a pas d'autre solution.



Sinon, ce que tu peux peut-être faire c'est bidouiller la valeur de la variable template TPL_PATH_TO_ROOT qui est l'équivalent de PATH_TO_ROOT mais côté client (c'est à dire par rapport au domaine) et pas côté serveur (c'est à dire par rapport à la racine de PHPBoost dans le file system). Avec un peu de chance, ça peut marchotter, sauf que je sais d'avance qu'il y aura des problèmes dans les requêtes AJAX qui ne doivent pas être envoyées sur le CDN mais sur le serveur dynamique.



J'ai peu d'expérience sur cette optimisation par l'architecture réseau, mais je doute que dans le cas de PHPBoost tu arrives à gagner quelque chose de significatif. Par contre, dans tous les cas, ça ne sera pas trivial à mettre en œuvre.

En fait le gain de rapidité est sur le fait que le serveur se contente de balancer le contenu dynamique, tandis que le reverse proxy se contente de balancer le contenu statique (avec l'infra de google). C'est un gain en terme de ressources réseau. Le client récupérant la page via le serveur apache/php, et les images, css, js via l'infra google.



Il y a effectivement la possibilité de matcher le contenu à mettre en cache. Pour l'instant je match tout. Toute requête allant sur http://animesost.appspot.com/www/ est en fait un cache de http://www.animesost.info/



Donc moi j'avais pensé à changer le PATH_TO_ROOT mais celui-ci comme tu l'indique est aussi utilisé pour le dynamique tel que l'AJAX. L'idéal serait donc de la remplacer que si le chemin qui suit le {PATH_TO_ROOT} pointe vers un contenu statique.

Dans ce que tu veux faire, tu veux que l'URL de ton site tombe chez toi ou chez Google ? Dans quel sens fonctionnerait le revrerse proxy ?

Les visiteurs vont sur le domaine classique : http://www.animesost.info

Cependant les liens vers les contenus statiques pointeraient sur http://animesost.appspot.com/www

Ainsi par exemple, l'url http://www.animesost.info/templates/animesost/theme/design.css serait remplacé par http://animesost.appspot.com/www/templates/animesost/theme/design.css, cirruxcache lui, accède à (si pas en cache) http://www.animesost.info/templates/animesost/theme/design.css et le met en cache (c'est bien le principe de reverse proxy, on accède au proxy qui transmet via son cache).

Édité par benpro Le 05/02/2011 à 15h47

Ok j'ai compris comment tu voulais architecturer ton réseau. Le reverse proxy est bien chez Google pour aller chercher une fois les ressources statiques et ensuite les mettre en cache, et pas dans l'autre sens, ce que j'avais compris au début et qui n'aurait pas de sens.

Pour distinguer les requêtes AJAX des liens vers les ressources statiques, je n'ai aucune solution à te proposer à part de les chercher une à une.

Mais tu penses vraiment que tu vas gagner quelque chose en faisant ça ? Ca ne serait pas mieux de tenter de mieux configurer Apache (et encore si ça se trouve il est déjà bien configuré pour les ressources statiques) ?

J'ai déjà optimiser mysql (avec mysqltuner) pour optimiser les requêtes, j'ai placé un cache APC (gain de fou), par contre je ne me suis pas encore penché sur apache, je me demande si c'est le coupable. (Je tourne autour de 200ms pour l'exécution du contenu dynamique, alors que par exemple, ici je vois 79ms ... et je dispose d'un serveur dédié, un kimsufi modeste, mais quand même).



Mais là c'est surtout pour augmenter la vitesse de téléchargement, connexion simultanées (2 connexions, puisque mon serveur pour le dynamique et GAE pour le statique), et puis c'est histoire de voir ce que ça donne, c'est tellement d'actualité les CDN

Le temps de chargement sans cache dans le navigateur est quand même de 7-9s sur mon site, avec une connexion 10M.



Où se trouve la variable TPL_PATH_TO_ROOT ?

EDIT : Mince c'est pas une variable globale... c'est un peu dans chaque module :/

EDIT2 : Ah non ça serait dans le begin.php. Je vais bidouiller ça.

EDIT3 : Bon j'ai fait quelques essais et ça semble pas miraculeux ' Je passage de 5s à charger tout les éléments de la page à 8s en fait, je sais pas si c'est parce que GAE balance moins vite que mon serveur.

Édité par benpro Le 05/02/2011 à 21h33

Ici on a aussi APC qui est activé. A noter que dans la prochaine version, si APC est activé, le cache sera stocké en mémoire partagée APC de manière à ne plus avoir à lire des fichiers php pour récupérer les données en cache, ça devrait encore améliorer les performances.

Pour ce qui nous concerne on tourne sur un serveur dédié qui est bien plus puissant que ce dont on a besoin, peut-être que ceci joue explique qu'on exécute les pages plus vite.

Mais tu parles de deux problématiques différentes (je pense que tu sais qu'elles sont différentes) : le temps de chargement et le temps d'exécution des pages.

Pour moi, le seul avantage niveau performance que tu peux avoir avec un CDN c'est de taper sur un serveur géographiquement proche de toi. Ca a aussi d'autres avantages qui concernent plus la qualité de service, c'est important aussi mais ce n'est pas la même problématique. Ca ne m'étonne donc pas que tu n'aies pas de sensible amélioration, surtout si ton serveur a une charge relativement faible et une bonne connexion Internet (ça devrait être aussi le cas du cloud de Google).

Tout à fait, mais c'était vraiment histoire de voir un peu ce que pouvait apporter un CDN.

Est-ce que la nouvelle version tiendra en compte des recommandations Yslow et PageSpeed ? Tel que par exemple, regrouper les js et css dans un seul même fichier ou bien encore utiliser les sprites CSS.

Merci des infos en tout cas

Pour l'instant on n'a rien fait sur ce point-là, et je ne crois pas qu'on fera plus car on est déjà énormément à la bourre.

De plus, ce genre d'optimisation n'est pas forcément appréciable pour ceux qui vont aller modifier leurs thèmes pour les personnaliser, il faudrait qu'on fasse une étude plus approfondie à ce sujet.