[terminé] Temps de chargement des cartes

[Dominique]

Essai depuis une zone à couverture faible :
Chargement du massif Vercors :

Https:
Chargement de la page html à 5 secondes
Chargement du fond de carte et du contour du massif à 20 secondes (dalles de 43k + contour de 1,2k)
Chargement des points à 50 secondes (pourtant il ne fait que 522k)
Http :
Chargement de la page html à 5 secondes
Chargement du fond de carte et du contour du massif à 10 secondes
Chargement des points à 50 secondes
(j'avais vidé le cache entre deux)

Moralité : https ne ralenti pas par rapport à http à débit constant.
Par contre, le chargement des points est très long (il s'agit bien du chargement car ma nouvelle version d'Openlayer remonte les statuts de connexion)

J'avais constaté, il y a quelques années, de gros blocages (allant jusqu'au refus de charger la page) dans certaines condition de G+ en montagne mais j'ignore s'il y avait un problème particulier où si une évolution technologique a amélioré ce point.

*** Oups : je n'ai pas pris la nouvelle API sur dom ***

[sly]

Https:
Chargement de la page html à 5 secondes
Chargement du fond de carte et du contour du massif à 20 secondes (dalles de 43k + contour de 1,2k)
Chargement des points à 50 secondes (pourtant il ne fait que 522k)
(...)
*** Oups : je n'ai pas pris la nouvelle API sur dom ***

Je ne sais pas si ça reste d'actualité, mais vu que ça ne semble pas en rapport avec https, je re-bascule sur le sujet qui traite de la carte. Et sinon, 50s pour charger les points c'est énorme ! même avec l'ancienne API.
Bon, mais à survoler rapidement l'état actuel, on en est plus à ce point là.
Toutefois je tourne plutôt autour des ~4s quand on est dé-zoomé (~1.6s pour executer l'appel API, ~1s pour recevoir le résultat et ~1s pour que OL fasse son affichage), ça reste un peu lourd à attendre. Ça vient sans doute des 500 points qui sont maintenant demandés ?
A comparer au résultat sur www.refuges.info qui est de l'ordre de ~800ms (450ms pour l'execution, 150ms pour recevoir et imperceptible pour l'affichage par Leaflet)

De fait, à l'usage (FF+ADSL) c'est un peu frustrant de réaction, dit autrement ça rame !
Un rapide test sur smartphone (de 2015) + FF + 4G m'indique que ça rame tout autant voire pire.

Bon, j'ai pas énormément de temps entre les fêtes,mais rien ne presse il me semble ? je ferais un compte rendu plus détaillé plus tard...

[Claude Mauguier]

De fait, à l'usage (FF+ADSL) c'est un peu frustrant de réaction, dit autrement ça rame !
Un rapide test sur smartphone (de 2015) + FF + 4G m'indique que ça rame tout autant voire pire.

Je confirme et vu la taille de l'écran, j'ai renoncé au smartphone en montagne

Bon, j'ai pas énormément de temps entre les fêtes,mais rien ne presse il me semble ? je ferais un compte rendu plus détaillé plus tard...

Bonne idée...devant un feu de bois et une fondue...

[Dominique]

50s pour charger les points c'est énorme ! même avec l'ancienne API

J’ai fait des tests en 2G/Edge pour pousser le bouchon au max
(PC connecté en point WiFi sur un smartphone forcé en 2G en région parisienne)

Ce qui est curieux c'est que :
Charger Openlayers optimisé (661Ko) prend 28,5 s
Charger l’API/simple des 283 points du Vercors (127 Ko) prend 33,4 s.

Fragmentation ?
On a un output_buffering de 4096 octets.
En enlevant la fragmentation avec ob_start(); … ob_end_flush(); on obtient un temps à peine un peu plus lent (), dû à l’attente de la fin de la boucle PHP pour commencer à envoyer les datas.
En réglant le tampon à des multiples ou sous-multiples de 4096, on voit que 4096 est optimum.
Donc ce n’est pas la fragmentation.

Autre ?
- Le temps PHP et SQL est globalement à 6 s quelle que soit la perf de la liaison, ce qui est logique
- A priori, c’est de l’ASCII pour les 2 (javascript / geoJson)
- Pas de différence de temps de download entre http et https
- Je n'ai pas vu de différence en simulant une latence à 100ms (via la console Chrome)
Je ne vois pas ce qui fait la différence.

Peut-être une piste d’amélioration ?
Les librairies .js et les json en XHR se chargent l’un après l’autre, c’est normal puisque c’est le programme js qui envoie les requêtes XHR.
Peut-être peut-on paralléliser en appelant la même requête XHR au début du chargement de la page (quelque chose dans le HTML) ?
Quoi que, si c'est le débit qui bloque, ça n’arrangera rien

NOTE :
Il s'agit de temps obtenus en neutralisant les caches.
Dans le cas normal, avec un max-age=7200, les .js ne sont chargés qu'une fois toutes les 2 heures, même si on regarde un autre massif ou une autre page avec une carte.
Il ne resterait que le temps du chargement de la page et de l'API

[sly]

Pour info, si c'est plus simple à mettre en oeuvre, sous FF il y a ça dans le moniteur réseau (par défaut) :
https://developer.mozilla.org/en-US/doc ... Throttling

Sinon, ça y est, je comprends mieux d'où viennent les 50s d'attente dont tu parlais : tu as simulé une connexion depuis l'Ariège profond

Supposons que EDGE soit le minimum requis pour espérer voir un bout de carte sur wri, ça parle de 400kbit/s sur wikipedia, j'en déduis que la lib OL de 600ko, qui se compresse (gzip compression) d'un facteur environ 5 devrait prendre (600/5)/(400/8) = 2s à se télécharger. Pas 30 secondes ! Y'a un truc quelque part.

Première trouvaille : il n'y a aucune compression effective, sgruuuunt !
Depuis ma mise à jour du système, mes (très vielles) directives sur la compression que j'avais exprès mis bien comme il faut ont tout désactivé ce qui est maintenant standard depuis des lustres. Je vire ça, ce qui active maintenant la compression de partout sur le serveur. Je comprends pas comment j'ai loupé ça à force de regarder tous ces octets qui passent.

Bon, même sans compression 600/(400/8) ~= 12s y'a quand même un facteur 2 qui se ballade dans ton essai. Je vais laisser ça à la différence entre débit théorique et débit réél.

Cette trouvaille compresse alors maintenant aussi le json qui semble se compresser assez régulièrement avec un facteur 10.... haaaaa, bien, là y'a vraiment du gain sur les connexions lentes. Cette fois, sur une connexion EDGE, c'est le temps de génération coté serveur qui est maintenant le plus lent : 85% de l'attente est coté serveur, 5% le temps de téléchargement ! (ADSL ça donne quelque chose de similaire tant le flux json compressé est faible)
Avant, sur 500points c'était plutôt 50% / 50%

Bien, tout ça va me motiver à regarder plus en détail la génération du json coté API (et sûrement en amont coté modèle aussi) pour essayer de gratter un peu.

- Le temps PHP et SQL est globalement à 6 s quelle que soit la perf de la liaison, ce qui est logique

6s ?? tu as un exemple de requête qui arrive à être si long ? On parle bien de l'API là ?
Si j'en prend un, qui renvoi 500 points par exemple lui :
https://dom.refuges.info/api/bbox?nb_po ... 28,46.6218
J'arrive à ~700ms de génération coté serveur.
A noter que les autres formats (gpx, xml font encore pire)

Pour réduire un peu ses désagréments lors de la mise en prod, je suggère comme solution très simple, au moins temporairement, de baisser le nombre de points maximum renvoyés de 500 à 350 (ou revenir à 250 ?)

D'ailleurs, pourquoi ce choix de pousser à 500 ? Ou même, mais le débat sera plus long, pourquoi ce choix d'un nombre arbitrairement fixé indépendant de la taille de la vue qu'on regarde ?
Sur un smartphone a écran de taille réduite, 500 points qui s’agglutinent c'est tout simplement inutilisable il me semble, je viens d'essayer, ça fait une grosse masse informe de points, impossible de cliquer celui choisi, ça fait une jolie guirlande colorée certes, qui montre à quel point wri est riche de points, mais fonctionnement, je ne vois pas. Je concède toutefois, que sur www avec 250 points, ça n'est guère mieux. Tant qu'on a pas zoomé, point de salut, tous ces points ne font que ralentir mon téléphone jusqu'a ce que j'arrive à quelque chose d'exploitable autour de ~30 points.
Mais comme je le disais pas le passé, mon usage de la carte sur smartphone, sur le terrain, est plutôt réduite (souvent, je pars de la fiche et me contente de la vignette carte indiquant ce qui se passe aux alentours, et ça ne va rarement chercher à plus de 30 points)

Sur ordi, à l'instant, avec un 61cm (24"), 500 points, c'est un poil mieux. Pour les massifs périphériques, ok, sur des cabanes isolées j'arrive à cliquer et me dire que je me suis évité de zoomer, mais pour les alpes du N, il me faut encore quelques coup de molettes pour envisager de choisir mon point.
Alors ? l'idée dernière ça ?
Montrer la richesse de wri ?
Espérer que le hasard du limit 500; montre au moins quelques points dans un massif X histoire d'inviter à zoomer en disant : si si, y'a quelque chose ! ?

[Dominique]

Pour info, si c'est plus simple à mettre en oeuvre, sous FF il y a ça dans le moniteur réseau (par défaut) :
https://developer.mozilla.org/en-US/doc ... Throttling

Bien sûr : il y a les mêmes dans Chrome.
Mais ce ne sont que des simulations très théoriques dont le comportement n'a rien à voir avec la réalité. Rien ne vaut de passer par un vrai réseau.
Les mesures que j'ai donné ne sont que les meilleures de 5 mesures dont les résultats varient dans un rapport 1 à 4 (et quelquefois n'aboutissent même pas au chargement de la page).
Et encore, j'ai une position fixe, en hauteur, juste en face de l'antenne. Je n'ose imaginer ce que ça donne au fond d'une forêt...
Le seul paramètre que j'ai simulé avec l'explo est la latence et je trouve suspect que ça n'aie aucun impact.

Supposons que EDGE soit le minimum requis pour espérer voir un bout de carte sur wri, ça parle de 400kbit/s sur wikipedia, j'en déduis que la lib OL de 600ko, qui se compresse (gzip compression) d'un facteur environ 5 devrait prendre (600/5)/(400/8) = 2s à se télécharger. Pas 30 secondes ! Y'a un truc quelque part.

Là aussi, on est sur un débit théorique max, au pied de l'antenne, sans effet dopler ni écho, avec les 8 timeslots de la cellule réservés pour soi car il n'y a pas d'autres utilisateurs ni réémission de trame bruitée...

Première trouvaille : il n'y a aucune compression effective

Bingo. je n'avais pas pensé à vérifier mais ça sert toujours de grater un peu partout... ça va améliorer.

- Le temps PHP et SQL est globalement à 6 s quelle que soit la perf de la liaison, ce qui est logique

6s ?? tu as un exemple de requête qui arrive à être si long ? On parle bien de l'API là ?

Non. c'est ce que Chrome appelle le "Time to first byte" et qui doit comprendre beaucoup de choses (d'ailleurs, il dépend du débit).
Je n'ai pas mis de traces dans le serveur.

Pour réduire un peu ses désagréments lors de la mise en prod, je suggère comme solution très simple, au moins temporairement, de baisser le nombre de points maximum renvoyés de 500 à 350 (ou revenir à 250 ?)
Mais comme je le disais pas le passé, mon usage de la carte sur smartphone, sur le terrain, est plutôt réduite (souvent, je pars de la fiche et me contente de la vignette carte indiquant ce qui se passe aux alentours, et ça ne va rarement chercher à plus de 30 points)

j'avais anticipé, c'est corrigé depuis mon test sur la version DOM.
En fait, j'avais mis 500 au moment des tests unitaires pour tester la réaction de l'affichage sur différents PC et mobiles. Il se trouve que le JS actuel traite très bien 500 points.
Mais les tests montrent que ça ne passe pas au niveau trans et que, tu as raison, ça n'apporte rien au niveau fonctionnel.
J'ai enlevé le paramètre de limite d'OL puisque ce n'est pas OL qui limite et laissé à chaque source le soin de réguler son nombre de point