Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v12] Légère dégradation des perfs de lecture sur un article ? #3134

Closed
firm1 opened this issue Oct 30, 2015 · 25 comments
Closed

[v12] Légère dégradation des perfs de lecture sur un article ? #3134

firm1 opened this issue Oct 30, 2015 · 25 comments
Labels
C-Back Concerne le back-end Django S-Régression Corrige un problème sur un composant qui fonctionnait auparavant
Milestone

Comments

@firm1
Copy link
Contributor

firm1 commented Oct 30, 2015

Si j'en crois les courbes munin, un article met plus de temps à charger qu'avant.

On était plutôt en dessous de la seconde pour le chargement, maintenant on est au dessus de la seconde.

capture d ecran de 2015-10-30 08-21-54

Ce n'est pas très grave puisque le nouveau serveur a de bonne perfs, mais quelqu'un aurait une explication à ça ?

@firm1 firm1 added S-Régression Corrige un problème sur un composant qui fonctionnait auparavant C-Back Concerne le back-end Django labels Oct 30, 2015
@pierre-24
Copy link
Member

À raison, @SpaceFox avait fait la même remarque. Le "pourquoi", par contre, je sais pas encore.

Ceci dit "un article" est un article publié ?

@SpaceFox
Copy link
Contributor

Nos confs donnent (dans /etc/munin/plugin-conf.d/wget_page.conf) :

env.url_url1 http://zestedesavoir.com/
env.label_url1 Accueil

env.url_url2 http://zestedesavoir.com/forums/
env.label_url2 Accueil des forums

env.url_url3 http://zestedesavoir.com/forums/communaute/bug-suggestions/
env.label_url3 Categorie de forums

env.url_url4 http://zestedesavoir.com/forums/sujet/273/les-petits-pixels/?page=3
env.label_url4 Un topic

env.url_url5 http://zestedesavoir.com/tutoriels/433/debuter-sur-adobe-photoshop/
env.label_url5 Un big-tuto

env.url_url6 http://zestedesavoir.com/tutoriels/229/la-3d-pour-le-jeu-video-avec-blender/
env.label_url6 Un mini-tuto

env.url_url7 http://zestedesavoir.com/articles/57/ouverture-officielle-de-zeste-de-savoir/
env.label_url7 Un article

On notera aussi qu'on affiche 2x « un topic » mais pas « Un mini-tuto ». C'est étrange.

@pierre-24
Copy link
Member

Ce qui est "marrant", c'est que les performances de l'articles sont plus dégeu que celle du mini ou du big tuto. Donc j'imagine que la différence provient des commentaires.

@SpaceFox
Copy link
Contributor

En revérifiant les URLs, toutes provoquent des 307 (passage en HTTPS, au moins sur navigateur) et certaines provoquent des 301. Je vais mettre les URLs à jour dans Munin pour éviter les redirections.

@SpaceFox
Copy link
Contributor

C'est fait. En attendant je confirme que les articles sont relativement longs à charger. @pierre-24 , @artragis , pour moi charger un article et un mini-tuto ça devrait maintenant être pareil, j'ai loupé un truc ?

@SpaceFox
Copy link
Contributor

Attention il y avait une erreur dans les stats de chargement des pages !

Dans Munin, sur les graphes « wget page », il y a une bizarrerie avec les courbes depuis ~17h aujourd'hui, c'est tout simplement que les courbes précédentes étaient fausses… ou plus exactement chargeaient bien ce qui était affiché jusqu'alors :

Numéro Couleur Avant Maintenant
1 Vert Accueil Accueil
2 Bleu Accueil des forums Accueil des forums
3 Orange foncé Catégorie de forums Catégorie de forums
4 Orange pâle Un topic Un topic
5 Violet Un topic Un big-tuto
6 Fuchsia Un big-tuto Un mini-tuto
7 Vert-jaune fluo Un article Un article

PS : vues les courbes annuelles, l'erreur date du jour de la réinstallation de la nouvelle prod.

@pierre-24
Copy link
Member

C'est fait. En attendant je confirme que les articles sont relativement longs à charger. @pierre-24 , @artragis , pour moi charger un article et un mini-tuto ça devrait maintenant être pareil, j'ai loupé un truc ?

Oui, logiquement.

En local, je me prend 46 requêtes SQL (utilisateur normal, pas de MP) quand je visite un article (quelque soit le nombre de commentaires), contre 44 dans le cas d'un tuto. Je doute que le problème provienne de là, ceci dit, mais il faudrait comparer ligne par ligne les appels (il y a au moins un appel de plus dans le cas des articles pour récupérer précédent/suivant, je sais plus quel est le deuxième). C'est clairement pas catastrophique.

Après ... Est ce que le temps de chargement d'un mini/big tuto a lui aussi augmenté ? Parce que si c'est le cas, c'est que le système de fichier est plus sollicité que prévu. Si c'est pas le cas, c'est qu'on fait quelque chose de spécial sur les articles qu'on ne devrait pas. Vu que le temps de chargement d'un article est supérieur à la seconde chez moi (ce qui ne m'avais pas frappé la dernière fois que j'avais essayé) alors que celui d'un big tuto est clairement inférieur à la seconde, je me dirigerais par là. Même si à priori, il y a très peu d'endroit ou le code des articles diffère de celui des tutos (c'était le but).

@SpaceFox
Copy link
Contributor

Une différence majeure est qu'en général un article a pas mal de
commentaires, et un tuto assez peu. Peut-être est-ce là qu'il faut chercher.

Le 31 octobre 2015 18:34, Pierre Beaujean notifications@github.com a
écrit :

C'est fait. En attendant je confirme que les articles sont relativement
longs à charger. @pierre-24 https://github.com/pierre-24 , @artragis
https://github.com/artragis , pour moi charger un article et un
mini-tuto ça devrait maintenant être pareil, j'ai loupé un truc ?

Oui, logiquement.

En local, je me prend 46 requêtes SQL (utilisateur normal, pas de MP)
quand je visite un article (quelque soit le nombre de commentaires), contre
44 dans le cas d'un tuto. Je doute que le problème provienne de là, ceci
dit, mais il faudrait comparer ligne par ligne les appels (il y a au moins
un appel de plus dans le cas des articles pour récupérer précédent/suivant,
je sais plus quel est le deuxième). C'est clairement pas catastrophique.

Après ... Est ce que le temps de chargement d'un mini/big tuto a lui aussi
augmenté ? Parce que si c'est le cas, c'est que le système de fichier est
plus sollicité que prévu. Si c'est pas le cas, c'est qu'on fait quelque
chose de spécial sur les articles qu'on ne devrait pas. Vu que le temps de
chargement d'un article est supérieur à la seconde chez moi (ce qui ne
m'avais pas frappé la dernière fois que j'avais essayé) alors que celui
d'un big tuto est clairement inférieur à la seconde, je me dirigerais par
là. Même si à priori, il y a très peu d'endroit ou le code des articles
diffère de celui des tutos (c'était le but).


Reply to this email directly or view it on GitHub
#3134 (comment)
.

@pierre-24
Copy link
Member

Ben pour mes tests, j'ai fait exprès de prendre le même nombre de commentaires dans les deux cas, et y'a une différence assez nette quand même.

@SpaceFox
Copy link
Contributor

Bizarre…

@pierre-24
Copy link
Member

D'ailleurs, le graphe le dit lui même :

Nom Current Min Avg
article 1.19 0.50 1.62
mini-tuto 0.56 0.20 0.75
big-tuto 0.24 0.22 1.04

Y'a clairement un truc qui va pas sur les articles.

@artragis
Copy link
Member

  • les badge
  • les +/- 1 très nombreux
  • on est passé de 21 à 25 commentaires (pas fait gaffe, pardon pas tapper

Il faut aussi se souvenir que la bdd avait été "chauffée" avec 2 tables,
maintenant on n'en a qu'une seule. La moindre requête passe donc par
deux fois plus de lignes.

Le 31/10/2015 18:50, Pierre Beaujean a écrit :

D'ailleurs, le graphe le dit lui même
http://munin.kisai.info/static/dynazoom.html?plugin_name=zestedesavoir.com%2Fwww.zestedesavoir.com%2Fwget_page&start_iso8601=2015-10-29T19%3A24%3A27%2B0100&stop_iso8601=2015-10-31T20%3A36%3A27%2B0100&start_epoch=1446143067&stop_epoch=1446320187&lower_limit=&upper_limit=&size_x=800&size_y=400&cgiurl_graph=%2Fcgi-bin%2Fmunin-cgi-graph
:

Nom Current Min Avg
article 1.19 0.50 1.62
mini-tuto 0.56 0.20 0.75
big-tuto 0.24 0.22 1.04

Y'a clairement un truc qui va pas sur les articles.


Reply to this email directly or view it on GitHub
#3134 (comment).

@SpaceFox
Copy link
Contributor

La moindre requête passe donc par deux fois plus de lignes.

Ce qui n'a normalement presque aucun effet visible, puisqu'on est sensés avoir des index pertinents, et que normalement le temps passé ne l'est pas dans MySQL lui-même.

@artragis
Copy link
Member

a-t-on les munin du serveur de prod pour les iops?

Le 31/10/2015 18:59, SpaceFox a écrit :

La moindre requête passe donc par deux fois plus de lignes.

Ce qui n'a normalement presque aucun effet visible, puisqu'on est
sensés avoir des index pertinents, et que normalement le temps passé
ne l'est pas dans MySQL lui-même.


Reply to this email directly or view it on GitHub
#3134 (comment).

@pierre-24
Copy link
Member

Puis de toute façon, le même contenu publié en tant qu'article ou en tant que tuto change complètement le temps, je viens de tester.

@SpaceFox
Copy link
Contributor

a-t-on les munin du serveur de prod pour les iops?

Oui depuis le nouveau serveur. C'est le tout premier graphe de la liste. En cliquant dessus on a des détails en plus (la taille moyenne des paquets).

@SpaceFox
Copy link
Contributor

Y'a aussi le pourcentage d'utilisation du disque, et on est très loin de la saturation.

@artragis
Copy link
Member

c'est surtout que je voulais voir si la mep de la zep avait fait varié
cet indicateur.

Le 31/10/2015 19:32, SpaceFox a écrit :

Y'a aussi le pourcentage d'utilisation du disque, et on est /très/
loin de la saturation.


Reply to this email directly or view it on GitHub
#3134 (comment).

@artragis
Copy link
Member

Je pense avoir trouvé le potentiel coupable :

SELECT ••• FROM `tutorialv2_publishedcontent` WHERE (`tutorialv2_publishedcontent`.`content_type` = 'ARTICLE' AND `tutorialv2_publishedcontent`.`must_redirect` = 0) ORDER BY `tutorialv2_publishedcontent`.`publication_date` DESC

qui est lancé ici :

/home/francois/zds-site/zds/tutorialv2/mixins.py in get(402)
  context = self.get_context_data(object=self.object)
/home/francois/zds-site/zds/tutorialv2/views/views_published.py in get_context_data(85)
  .order_by('-publication_date')

Pourquoi dégradation uniquement sur les articles? Car il me semble que contrairement aux tutos qui avaient subi pas mal de traitement pour éviter des bugs bien chients dans l'ancien module, les articles ne faisaient pas une aussi grosse requête. Surtout, la requête était limitée (il y avait un LIMIT quoi) car comme on n'avait pas de pagination, seul les x premiers articles étaient affichés.

@pierre-24
Copy link
Member

À tester, mais il me semblait avoir viré la ligne et pas avoir vu de différences. M'enfin tu peux rajouter un LIMIT, ça fait jamais de tord :)

@SpaceFox
Copy link
Contributor

SpaceFox commented Jan 9, 2016

À priori la PR #3275 corrige ce problème.

@SpaceFox SpaceFox closed this as completed Jan 9, 2016
@SpaceFox SpaceFox added this to the Version de développement milestone Jan 9, 2016
@pierre-24
Copy link
Member

J'espère, parce que je ne m'explique toujours pas pourquoi sur les articles et pas les tutos. Mais j'espère que je me trompe :)

@artragis
Copy link
Member

Tu te souviens de l'article qu'on avait fait sur le pourquoi de la zep-12?

Bah la raison est tout simplement là : le code pour afficher les +/-
dans les articles était optimisé (par rapport à ce qu'il se faisait à
l'époque) mais pas dans les tutos. Du coup quand on est passé à la
zep-12 (en plus du fait que les tutos ont traditionnellement moins de
+/-) bah les articles ont été touchés et pas les tutos.

Le 10/01/2016 09:25, Pierre Beaujean a écrit :

J'espère, parce que je ne m'explique toujours pas pourquoi sur les
articles et pas les tutos. Mais j'espère que je me trompe :)


Reply to this email directly or view it on GitHub
#3134 (comment).

@pierre-24
Copy link
Member

Aaaah, ok, c'est pour ça. Bon, ben espérons que ça aie le but annoncé ;)

@artragis
Copy link
Member

je n'en suis pas sûr mais ça a des chances.

Le 10/01/2016 10:48, Pierre Beaujean a écrit :

Aaaah, ok, c'est pour ça. Bon, ben espérons que ça aie le but annoncé ;)


Reply to this email directly or view it on GitHub
#3134 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-Back Concerne le back-end Django S-Régression Corrige un problème sur un composant qui fonctionnait auparavant
Projects
None yet
Development

No branches or pull requests

4 participants