( J'ai hâte de voir ça )

Bonjour à tous!

Le 30 Mars 2012, découvrez une mise à jour massive de l'intégralité de la messagerie!

Un peu plus de 200 fichiers mis à jour, une sécurité accrue, des performances démultipliées, une ergonomie fortement améliorée, un design unifié et des interfaces repensées pour être simples à utiliser!

Un premier pas vers la V3.

A bientôt pour communiquer et échanger dans cette nouvelle version

Petit up technique!

1. Google à multiplié par 10 la quantité de donnée explorée quotidiennement sur netdoor.fr.
2. Toujours plus de mise en cache pour réduire les temps
3. Optimisation générale (réduction de taille sans perte de qualité) de tous les fichiers images de la plate-forme
4. Mise en forme intelligente des url de toutes les images: fichier de nom simple
5. Site map vidéo avec miniature envoyé à Google, 5000 vidéos indexées...
6. Refonte plus performante du Rewrite Engine de netdoor et mise en place de 3 serveurs http pour les contenus statiques

En résumé, beaucoup plus de vitesse et de fluidité sur toutes les pages de la plate-forme.

V3 toujours en progression...

Au final tu as mis en place un Cluster MySQL ?

Hello,

non pour l'instant le cluster MySQL n'as pas beaucoup de sens ( il y a en fait beaucoup de contraintes à respecter ). Récemment j'ai déplacé sur un nouveau serveur une des bases de données de NetDoor et j'en ai profité pour partir sur une version plus récente de MySQL. A cette occasion j'ai réfléchi à la configuration réplication Master-Master (+ MySQL proxy) moins contraignante que le cluster et qui permet quand même de faire une bonne répartition de charge. Avant de partir en cluster cette configuration me semble de rapport gain de performance/temps investi très intéressante.

Disons que ce genre de configuration présente un intérêt lorsque les CPU son à toc...ce qui est pas le cas pour l'instant.

Salut,

En allant sur Netdoor, la première réflexion que je me suis faite est que la page d'accueil met quelques secondes à charger. Tu devrais l'optimiser un peu pour qu'elle s'affiche plus rapidement (léger gain de référencement, et moins de visiteurs qui quittent dès la première page). Entre autres :

• Tu as 39 appels de Javascript et 8 de CSS, c'est énorme. Tu gagnerais à combiner tes JS et CSS
• Placer le code Javascript en bas de page (juste avant le </body>) pour que l'affichage ne soit pas perturbé par tes appels externes (qui sont synchrones)
• Les images en noir et blanc dans le bloc du milieu sont plus grandes que nécessaire et tu les réduits en CSS. Tu devrais les redimensionner pour qu'elles fassent la bonne taille.

C'est pas grand chose en termes de travail et le gain est plutôt intéressant !

Coucou,
le javascript met énormément de temps ainsi que le CSS à charger...lorsqu'ils se trouvent déjà dans le cache du navigateur le chargement de la page est immédiat. Ça craint, Google me dit que la page d'accueil met 2,5 secondes, celà met netdoor dans le rouge...et l'impact sur le référencement est énorme puisque en dessous de 1,5 secondes, Google considère un site comme lent. Je vais creuser ce problème merci.

Je comprends pas ce qui peut être si lent sur la page d'accueil. Mise à part quelques images (et 2, 3 recettes magiques qu'on ne voit pas, j'imagine), il n'y a rien de lourd. Pourquoi autant de css et js inutile ?
Si tu découpes bien ton code, en mettant dans un css les styles relatifs à toutes les pages, et ailleurs les trucs pour chaque pages, idem pour le js, ya aucun pb, les pages lourdes mettront du temps à charger, les pages "vides" comme l'accueil, seront rapides.

Je suis en train d'épurer, il y a quelques vieux fichiers css et javascript en cours de migration.
J'en ai déjà retiré 6, je continue de les migrer.

@uaip, en fait si tu utilises ajax dans les pages pour charger dynamiquement du contenu, il y a deux solutions, soit tu charges tout dès le début, soit tu utilises une technique qui charge les fichiers requis au fur et à mesure.

Ainsi si tu utilises des techniques de lazy load on demand du js tu peux assurer que lorsqu'un composant javascript est appelé, le plugin adéquat sera automatiquement chargé, et donc le fichier js relatif.

C'est une technique que j'utilise maintenant pour éviter de tout charger au début.

Sauf que mon vieux code n'est pas compatible avec cette technique et que je dois donc le migrer progressivement. Je te conseille cette technique de "lazy load on demand"

Edit: c'est fait, j'ai minimisé autant que possible le js et css de la page principale.

Bonjour à tous,

j'ai suivi vos conseils:
- j'ai rassemblé et compressé les 12 fichiers JS et CSS en 2 fichiers js_all et css_all uniques (il reste cependant l'ancienne api js qui est encore chargée de manière asynchrone (il me faudra du temps pour réécrire ces fonctions progressivement...)
- j'ai mis juste avant le </body> les appels de script tels que Google Analytics et d'autres scripts asynchrones

Sauf que j'arrive pas à faire descendre les temps, par exemple pour:
http://www.netdoor.fr/article-1514-lin [...] e-gentoo.html

Quand je regarde dans firebug...je vois que le temps de génération de la page est de moins d'une seconde et qu'au final la page met 2 secondes à s'afficher...c'est mal!

Avez-vous encore des idées? Merci

Salut, fais plutot ce genre de tests avec gtmetrix.com

Citation : pacman2

Salut, fais plutot ce genre de tests avec gtmetrix.com

C'est carrément puissant, merci!

Je comprend toujours pas, Google me dit qu'en moyenne une page se charge en 2,5 secondes sur NetDoor.
Malgré tous mes efforts cela reste mauvais. Pourtant tous les indicateurs sont acceptables.

On dirait qu'il y a trop de javascript à parser et que cela ralenti le chargement de la dom.

J'ai plus trop d'idée...il faudrait que mes pages descendent sous la barre des 1,5 secondes...

Tu balances beaucoup trop de JS pour une page qui finalement n'en a absolument pas besoin, tes images pourraient être bien mieux optimisées. <script async> est ton ami autant que faire se peut.

Qu'en est il de ton reverse proxy ? Tu en utilises un ?

Pourquoi un cache si court sur des images complètement statiques ?

Citation : ThePooh

Tu balances beaucoup trop de JS pour une page qui finalement n'en a absolument pas besoin, tes images pourraient être bien mieux optimisées. <script async> est ton ami autant que faire se peut.

Qu'en est il de ton reverse proxy ? Tu en utilises un ?

Pourquoi un cache si court sur des images complètement statiques ?

[OK] Je suis en train d'optimiser avec un job d'arrière plan toutes les images de netdoor depuis plusieurs jours, c'est à 50%...j'ai inclue l'optimisation dans le code pour les prochaines images.

[OK] J'ai écrit une petite fonction js pour différer le chargement car il paraît que l'attribut async n'est pas géré par IE alors que node.async = true l'est.

[OK] En fait je viens de me rendre comte que mes lighttpd servaient sans mod_compress et sans mod_expires, j'ai corrigé merci

[FAILED] Je réfléchi au javascript utile et pas utile mais c'est un vrai [ censuré ] :-(

Edit: j'ai résolu plusieurs autres problèmes:
- pas de configuration de mod expires dans apache et du coup pas d'expiration pour les images et donc de mise en cache!
- déclenchement du chargement différé des fichiers js à partir de $(window).load et pas de $(document).ready ce qui retardait en fait le chargement complet de la page inutilement!

J'ai un bon score maintenant > 80%

Hello à tous,

je poursuis mon optimisation...depuis que j'ai appliqué toutes les recommandations (ou presque) de PageSpeed, je suis passé de 2,5 secondes à 7 secondes de chargement d'après Google.

Je pense que ce temps provient de:
- le fait de ne pas différer le chargement du Javascript (MAIS le SDZ fait pareil et avec des fichiers dont la taille au cumul est assez voisine)
- l'exécution du code javascript inline (un peu comme partout),
- un peu trop de css en migration (un peu comme partout),
- une construction du document html lui-même qui met parfois 5 s.

Alors j'ai voulu comparer avec le SDZ, et j'ai constaté qu'ils mettent <300ms pour répondre.

Sauf que le contenu variable de la page du SDZ semble être chargé dans un second temps (on le vois même à l'oeil nu). Alors, comment? quelle technique? Je préférerais envoyer mon header(=en-tête html du site) en répondant en <300ms et charger le contenu ensuite plutôt que de répondre le tout en 5s (header+ contenu).
Une idée? Ou j'ouvre un post à part?

Le second, toujours par rapport au document html. Actuellement j'ai un pragma no cache dans le header de tous les documents html de netdoor. Alors j'envisage la solution suivante:
1.si connecté: pragma no-cache
2.si NON connecté: pragma cache 15 jours

Et j'ajouterais le module mod_proxy avec cache à apache pour complémenter ceci. Le gain serait il important? Qu'en dites vous?

Merci à vous tous!

Salut, vu qu'il est 1h du mat, que je suis crevé mais que j'ai envie de t'aider je vais être bref, voilà ce que j'avais écrit à un ami qui avait des problèmes de temps de chargement sur son site web:

Salut, pour connaître les temps de chargement de tous les éléments de ta page web (Gantt chart) le lien ci-dessous m'a bien aidé:
http://www.webpagetest.org/

Il y a aussi le Speed Tracer de Google qui mesure la performance mais je ne l'ai jamais utilisé:
http://code.google.com/intl/fr/webtoolkit/speedtracer/

Un autre truc que j'ai pas utilisé:
http://code.google.com/intl/fr/speed/p [...] g_chrome.html

Et une conférence vidéo sur la performance Web qui m'a permis de trouver tous ces outils:
http://braincracking.org/2011/02/03/co [...] ris-web-2010/

Yep, comment gérais-tu le load balancing si mod_proxy n'était pas installé ? (question de curiosité)

@neophtis Merci pour le coup de main, je vais tout lire tranquillement

@uaip J'utilise ob_start() de php comme une mécanique générale dans NetDoor. De ce fait, je peux modifier le code html avant de l'envoyer à Apache.
J'en profite selon les endroits pour:
- minimiser le html,
- réécrire ou compléter certains liens (balise a),
- réécrire les url de certaines images (balise img) et donc load balancer,
- réparer les textes html édités par les utilisateurs avec tidy.

Cela peut-être coûteux en performance si les handler de réecriture sont mal écrits...

Citation : netdoor.fr

@uaip J'utilise ob_start() de php comme une mécanique générale dans NetDoor. De ce fait, je peux modifier le code html avant de l'envoyer à Apache.

Tu n'utilises donc pas de framework (ou alors un perso) sur Netdoor ? Car typiquement comme tu le signales ob_start mal géré et c'est tout ton output buffering qui déguste. Quand sortir son flush() notamment est quelque chose de très périlleux. Tu le gères manuellement ?

Pour cette partie j'utilise en effet mes classes.
Je transite la plupart des éléments par buffer avec la logique suivante http://fr.php.net/manual/fr/function.ob-get-contents.php.
Je n'utilise pas directement de flush, je récupère le contenu du buffer puis je l'affiche via un echo.
Selon l'endroit je retravaille le buffer avec le parser xml le plus rapide pour accéder aux éléments à modifier.

Ca marche bien, je n'ai aucun effet de bord, aucun bogue et la consommation mémoire est bonne à la condition de manipuler les variables php par référence et non par valeur (comme un peu partout, avec un bon appui du garbage collector si activé dans PHP 5.3 la consommation mémoire reste basse).

En revanche, on a vite fait de dégrader les performances à vouloir trop en faire dans un handler mais je trouve la possibilité de pouvoir intervenir à cet endroit très utile.
Même si l'utilisation ultérieure d'un proxy permettra par exemple de soulager cette partie de réécriture pour load balancer les images statiques.

Sinon j'ai fini par mettre en place Varnish...^^

Citation : netdoor.fr

Pour cette partie j'utilise en effet mes classes.
Sinon j'ai fini par mettre en place Varnish...^^

Excellente idée. Je serais toi je jetterais également un petit coup d'oeil à Redis et surtout à Resque (à moins que tu utilises déjà Gearman -il me semblait l'avoir lu ici sans conviction-) mais sur un réseau social la possibilité de différer des jobs me semble indispensable.

J'affine encore Varnish mais je pense redescendre à des temps acceptables d'ici quelques jours le temps que le cache se garnisse.
Disons que sur la page d'accueil je passe de 2,5s à 900ms ^^...En fait comme je gère les sessions php en base de données j'ai juste retouché le gestionnaire pour qu'il dégage le cookie de session php lorsque la session est vide...

J'adore Gearman, je me le suis noté! Pour le key-value store comme j'utilise déjà memcached et que je teste MongoDb, je ne vais pas en introduire un troisième.

Par contre Gearman pourrait étendre mon scheduler interne. En fait j'ai (bien ou pas bien) créer mon propre scheduler en php afin que tout membre dans netdoor puisse gérer ses propres jobs. Un job est une action spécifique proposée par les admins mais paramétrable par le membre, à un horaire choisi par le membre mais exécuté par un agent. Les admins autorisent ou non un membre ou un ensemble d'utilisateurs à utiliser un tel job. Bref...ce qu'il y a de bien c'est qu'une action est faite par un agent en le nom du membre et donc la sécurité de l'environnement d'exécution est cloisonné...

Par contre rien ne m'empêche d'utiliser Gearman pour soulager mon serveur de ces jobs. Cool

J'aurais bientôt jouer toutes mes cartes, me reste encore à différer l'exécution de tout le javascript à la demande et à upgrader innodb...

Hello à tous ^^,

Google semble voir les améliorations de performances grâce au cache.

J'ai fait à ce sujet un petit mémo/tutoriel sur ma configuration que je partage avec vous:
Varnish, PHP 5.3 et Apache 2 sous Gentoo

@uaip J'ai retenu ceci comme solution de lazyload javascript:
ensure - Ensures relevant script and html are loaded before executing code

Mais si vous en avez d'autres à me conseiller je suis preneur!

Merci encore pour vos conseils

Respect... Ca c'est du boulot ! je suis bouche béée

Content d'avoir pu convertir une nouvelle personne à Varnish. Objectif 2, convertir à Redis. Commençons dès maintenant.

Citation : netdoor.fr

J'adore Gearman, je me le suis noté! Pour le key-value store comme j'utilise déjà memcached et que je teste MongoDb, je ne vais pas en introduire un troisième.

Ce n'est absolument pas incompatible, sur neetcafe on utilise Memcached / mongodb et Redis. Il faut juste voir que chaque outil à ses capacités, ses points forts et faibles donc autant tous les utiliser (Redis diffère dans sa gestion de la persistance notamment, bien qu'on puisse la rendre optionnelle je préfère utiliser Memcached pour tout ce qui est pas persistant et Redis pour le reste)

Déjà il faut bien comprendre que Redis c'est bien plus qu'un simple key-value store.

La chose la plus intéressante avec Redis (qui font que je trouve cette technologie tellement révolutionnaire ) c'est qu'à l'inverse de Memcached ça va au delà du simple stockage de key. Tu peux stocker des sets, des strings mais également des lists, je te laisse imaginer les possibilités que ça laisse, surtout sur un réseau social, tu peux faire des intersection, des sort de toute sorte, des union à des vitesses folles quand tu sais que tout le dataset reste sur le disque. C'est persistant !

Ca te permet de faire une intersection sur 2 sets et d'avoir un résultat derrière, awesome things are awesome.

Mais outre ça Redis supporte la replication. Ainsi au contraire, Memcached + Redis sont complémentaires dans le sens où tu peux laisser souffler l'un (memcache) en donnant certaine tâche à l'autre.


Et comme il se dit dans la communauté de Redis, Redis is BLAZING FAST !

Bref Redis + Memcached + Mongodb ce n'est pas incompatible !

Redis vaincra !

En effet c'est nettement mieux ! En tant qu'utilisateur lambda, j'avais quitté la première page dès le début vu le temps de chargement, j'ai réessayé aujourd'hui et une fois que les images/css/js ont été mis en cache par le navigateur, la page s'affiche presque instantanément.

Ca serait intéressant de voir l'évolution de ton taux de rebond, je suis prêt à parier qu'il a nettement diminué !

@ThePooh : Tes remarques sont très instructives. A quand un tuto sur "Optimisez votre site web" ?

@ThePooh Je me suis noté Redis, quand j'aurais un peu de temps j'approfondirais. Merci

@Jack River Le taux de rebond à littéralement chuté, j'ai pas les chiffres en tête mais la courbe à brutalement plongé dans Google Analytics.

J'ai encore amaigri les fichiers javascript en différant leur chargement dans les pages où ils sont utilisés uniquement...

Sinon, depuis aujourd'hui je charge à la place des images dynamiques un pixel blanc ce qui allège considérablement toutes les pages. Puis plus tard de manière différée je charge la véritable image. De cette manière la trame de la page arrive plus vite et le chargement de la page également.

J'ai plus trop d'idées à part load balancer sur plusieurs apache ou nginx...

Résultat final, t'es au norme ?

Je sais pas trop:

Votre avis sur ceci? Je ne sais pas trop comment l'interpréter...est ce que le chargement de la page Web s'est vraiment terminé avant que ne démarre le chargement différé des images "imgfile-xxx"?

2.8s ça va ! M'enfin il y a quand meme beaucoup de requetes après c'est juste mon avis