par sly » 29 déc. 2019, 23:06
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.
Dominique a écrit : ↑28 déc. 2019, 22:13
- 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 ! ?
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/docs/Tools/Network_Monitor/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.
[quote=Dominique post_id=32031 time=1577567631 user_id=216]
- Le temps PHP et SQL est globalement à 6 s quelle que soit la perf de la liaison, ce qui est logique
[/quote]
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_points=500&type_points=7,10,9,28&bbox=4.3991,45.6483,10.428,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 ! ?