Quelques optimisations
A la suite d’Imagine US et des technical tracks ainsi que de plusieurs lectures récentes, je vous propose quelques informations ou techniques que j’ai trouvé intéressantes.
J’allais également oublier, les slides de ma conférence à Imagine sont disponibles ici et la vidéo a été mise en ligne ici.
Zend asynchronous
Lors des tech tracks d’Imagine, j’ai aussi pu voir le passionnant papier de Kevin de Zend. Le principe est de faire des requêtes qui seront servies de manière Asynchrone, ni plus ni moins qu’un Job manager en fait. actuellement je recommandais l’usage de Gearman pour la plupart de gestions de Queue mais quand on a pas besoin d’un fonctionnalité aussi avancé, Zend Asynchronous peut être une ressource à la fois simple et efficace.
Le papier de Kevin est disponible ici.
Mysql, ca ne se scale pas…
On commence de plus en plus a avoir des sites énormes en hébergement. Que ce soit du Ecommerce ou des médias, un gros site va très clairement faire chauffer la base de données. Le soucis avec Mysql, largement reporté déjà mais visible entre autre dans ce thread sur le forum Mysql, c’est que InnoDB et MyISAM se scale très très mal.
Quand on a un serveur qui a plus de 4 processeurs (plus de 4 cores pour être précis), Mysql ne sait pas en tirer partie. Pire, c’est même parfois un handicape. Alors en attendant la version 5.4 qui nous promet une refonte massive de l’architecture multi thread de Mysql, on va devoir faire avec. En plus, depuis le rachat de Sun par Oracle et la politique mené par ce dernier, doublé du mouvement NoSQL, il n’est pas certain qu’on voit un jour cette version.
Pire, avec Oracle derrière, le principe de limitation de Mysql pourrait même faire les affaires du titan qui aurait un intérêt évident à ne pas corriger ce point afin de vendre de l’Oracle.
Alors il reste le moyen de chainer les serveurs à 4 cores… Master/Master/Master etc. Ou de séparer les Read et Write et on fait un Master / Slave. Mais rien de bien brillant pour des sites qui consomment de plus en plus de ressources.
La conception, encore et toujours
Shawan mon amour
On a eu un problème assez original il y a quelques semaines à NBS System. Un client a eu des soucis délirant de charge de sa base de données. Tout le monde s’est posé la question, Moooo gento ou problème plus technique ?
Une première réponse au problème a été une découverte (faite par la web agency), d’un soucis atypique… Quand on fait un mailing pour une vente privée ou des clients existants, il est possible de les authentifier automatiquement quand ils suivent le lien. C’est très confortable pour eux et plusieurs systèmes existent qui facilitent la vie des intégrateurs.
Oui mais…
Quand on fait ca sur une très large clientèle, selon la façon de le faire, cela peut avoir des incidences très sensibles. L’exemple ici c’est que la base de données se retrouvait à décoder des centaines de Shawan (Hash SHA1) à la secondes au moment du pic d’ouverture des mailings. Résultat, à chaque clic, la DB devait décoder le SHA1 et vérifier son authenticité et … ca la cassait en deux.
Ce travail doublé du travail normal de DB la mettait totalement à genoux. Une analyse des logs, des slow queries, des paramètres vitaux de serveurs et une collaboration entre l’infogérant (nous) et la web agency a permis de mettre un nom sur le problème et de le corriger. Vicieux celui-ci.
Conception de Home
Bien concevoir sa home reste une clef du succès d’un site. La charge imposé par la Home sur l’ensemble de la charge serveur dépasse souvent les 40%, il est donc important de concevoir de manière optimale cette page qui est le premier accueil qu’un client reçoit.
Pleinnnnn de produits
Eh oui ma bonne dame, plus y’en a, mieux c’est.
Faux. Lisez ce qu’en penses mes amis les pros comme Capitaine Commerce, François Ziserman ou Catherine Barba, assommer les clients sous 200 produits en homepage, ca n’apporte rien sinon un client perdu. Et plus on charge de produits, plus on fait travailler la base de données et les CPU pour interpréter le PHP et plus… ca rame.
Donc on a des clients perdus sur un site qui rame. Êtes vous bien persuadé que c’est ce que vous voulez ???
(Press Y to continue if you are sure)
Dynamique, non mieux, random !
Bien tiens… J’ai une ligne de conduite précise, je sais ce que je vend et à qui. Aucun doute à ce sujet, j’ai profiler ma clientèle alors pour optimiser mes ventes, je charge mes produits en random…
Alors je veux bien que dans certains cas cela puisse avoir, à l’occasion, du sens mais clairement pas en home et pas tout le temps. Amazon, notre maitre à tous, ils envoient pas des produits en random à leurs clients. Ce qui a boosté leurs ventes et surtout le panier moyen de chaque acheteurs, c’est tout l’inverse, c’est l’envoie de produits ciblés.
Alors charger dynamiquement oui, dans certain cas pour s’adapter au client mais en random… ?
Car oui, le random et le dynamique sont des ennemis des caches, ces fameux caches (reverse proxy, celui de votre system de e-commerce, memcached, le Full Page Cache et dans une moindre mesure celui des processeurs et des opcode cache de PHP) sont assez allergiques au hasard.
Et le statique ?
Vous y avez pensé ? Une landing statique bien faite, qui a la calculer chaque nuit en Cron, ca peut faire la différence. Sincèrement, afficher moins et mieux pour fournir à tout le monde une expérience utilisateur plus fluide, efficace et rapide, c’est une stratégie payante.
Plus votre site est véloce, plus et mieux il vend, c’est plus que démontré.
Inline URI
Alors celui-ci de tricks, il est soooo sexy.
Il faudrait tester en live la chose et étudier si c’est rentable mais le principe est marrant. En gros, dans votre CSS, plutot que de mettre la référence à une image externe, vous allez mettre en place une chaine de caractère encodée en base64 :
url(data:image/gif;base64,R0lGODlhEAAQAMQAAORHHOVSKudfOulrSOp3WOyDZu6QdvCchPGolfO0o/XBs/fNwfjZ0frl3/zy7)
Ca donne un texte certe un peu chargé mais… Le Gzip est là pour nous aider. En gros le CSS va grossir, certes mais en contrepartie on peut le compresser en mod_gzip ou mod_deflate et finalement on n’a qu’une légère augmentation. Par contre, on économise autant de GET HTTP, ce qui n’est pas négligeable.
A vue de nez, je pense qu’il est valable de le faire pour les petites images, icones ou petits thumbnails. Il est possible aussi de faire un Sprite bien sûr, mais cette technique alternative peut aussi avoir ses cotés sympas. Je dois avouer que c’est tout neuf pour moi alors je n’ai pas penssé à tous les points qui pourraient profiter des ces Data URIs.
(Beaucoup) plus d’infos sur cette technique ici : http://css-tricks.com/data-uris/
Commentaires récents