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

enlève une requête lente car elle récupérait trop de données. #3275

Merged
merged 2 commits into from Jan 8, 2016

Conversation

@artragis
Copy link
Member

commented Jan 4, 2016

Q R
Correction de bugs ? [oui]
Nouvelle Fonctionnalité ? [non]
Tickets (issues) concernés [IRC, #3134]

enlève une requête lente car elle récupérait trop de données.

il faut vérifier que les +/- fonctionnent encore (le cas typique c'est qu'il ne sont pas pris en compte à la regenération de la page ou que le pouce n'apparait jamais vert)

@artragis artragis force-pushed the artragis:one_slow_query branch from e7f1c23 to 668af96 Jan 5, 2016

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2016

QA can start. Faudrait juste que spacefox rappelle la requête associée pour vérifier qu'elle n'apparait plus dans les logs.

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 5, 2016

Je m'en charge ce soir, ce sera encore le plus simple :)

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2016

Mon dernier commit allège la commande sql envoyée (sans pour autant la décoreler des templates, ça demanderait plus de boulot, là c'est pour qu'on ait une amélioration rapidement.)

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 7, 2016

Je crains que ce ne soit un échec :-( Je vois les modifs Python mais ça n'influe pas sur les requêtes générées.

Sur un article :

/home/spacefox/dev/django/zds-site/zds/tutorialv2/mixins.py in get(414)
  context = self.get_context_data(object=self.object)
/home/spacefox/dev/django/zds-site/zds/tutorialv2/views/views_published.py in get_context_data(117)
  reaction_ids = list(set([reaction.pk for reaction in context['reactions']]))

Me donne (reformatée) :

SELECT 
    `utils_commentlike`.`id`,
    `utils_commentlike`.`comments_id`,
    `utils_commentlike`.`user_id`
FROM
    `utils_commentlike`
WHERE
    `utils_commentlike`.`user_id` IN (73 , 2494,
        138,
        1432,
        313,
        255,
        1097,
        1705,
        2312,
        542,
        645,
        429,
        144,
        747,
        2876,
        1097,
        2885,
        82,
        987,
        748,
        312,
        997,
        4323,
        313,
        1097)

Ce qui renvoie fatalement des milliers de lignes (environ 13000).

Dans le même genre je trouve aussi sur la même page sa petite sœur avec dislike et :

/home/spacefox/dev/django/zds-site/zds/utils/templatetags/topbar.py in top_categories(44)
  for key, group in itertools.groupby(tgs, lambda item: item["tags"]):

Qui donne

SELECT DISTINCT
    `forum_topic_tags`.`tag_id`, `forum_topic`.`id`
FROM
    `forum_topic`
        LEFT OUTER JOIN
    `forum_topic_tags` ON (`forum_topic`.`id` = `forum_topic_tags`.`topic_id`)
        INNER JOIN
    `forum_topic_tags` T5 ON (`forum_topic`.`id` = T5.`topic_id`)
WHERE
    (`forum_topic`.`forum_id` IN (1 , 16, 2, 17, 3, 18, 19, 20, 23, 21, 22, 24)
        AND T5.`tag_id` IS NOT NULL)

(environ 5000 lignes)

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

je ne comprends pas comment c'est possible !

Le 07/01/2016 23:51, SpaceFox a écrit :

Je crains que ce ne soit un échec :-( Je vois les modifs Python mais
ça n'influe pas sur les requêtes générées.

Sur un article :

|/home/spacefox/dev/django/zds-site/zds/tutorialv2/mixins.py in
get(414) context = self.get_context_data(object=self.object)
/home/spacefox/dev/django/zds-site/zds/tutorialv2/views/views_published.py
in get_context_data(117) reaction_ids = list(set([reaction.pk for
reaction in context['reactions']])) |

Me donne (reformatée) :

SELECT
utils_commentlike.id,
utils_commentlike.comments_id,
utils_commentlike.user_id
FROM
utils_commentlike
WHERE
utils_commentlike.user_id IN (73 ,2494,
138,
1432,
313,
255,
1097,
1705,
2312,
542,
645,
429,
144,
747,
2876,
1097,
2885,
82,
987,
748,
312,
997,
4323,
313,
1097)

Ce qui renvoie fatalement des milliers de lignes (environ 13000).

Dans le même genre je trouve aussi sur la même page sa petite sœur
avec dislike et :

|/home/spacefox/dev/django/zds-site/zds/utils/templatetags/topbar.py in
top_categories(44) for key, group in itertools.groupby(tgs, lambda
item: item["tags"]): |

Qui donne

SELECT DISTINCT
forum_topic_tags.tag_id,forum_topic.id
FROM
forum_topic
LEFT OUTER JOIN
forum_topic_tags ON (forum_topic.id = forum_topic_tags.topic_id)
INNER JOIN
forum_topic_tags T5ON (forum_topic.id = T5.topic_id)
WHERE
(forum_topic.forum_id IN (1 ,16,2,17,3,18,19,20,23,21,22,24)
AND T5.tag_id IS NOT NULL)

(environ 5000 lignes)


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

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

Chez moi je n'ai désormais plus que cette requête :

 SELECT "utils_commentlike"."comments_id" FROM "utils_commentlike" 
WHERE (
    "utils_commentlike"."user_id" = %s AND 
    "utils_commentlike"."comments_id" IN 
        (SELECT U0."comment_ptr_id" 
         FROM "tutorialv2_contentreaction" U0 
         INNER JOIN "utils_comment" ON ( U0."comment_ptr_id" = "utils_comment"."id" ) 
         WHERE U0."related_content_id" = %s ORDER BY "utils_comment"."pubdate" ASC LIMIT 17)
)' - PARAMS = (u'1', u'16')

que je peux, si besoin faire remplacer par :

utils_commentlike"."comments_id" FROM "utils_commentlike" WHERE ("utils_commentlike"."user_id" = %s AND "utils_commentlike"."comments_id" IN (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s, %s))

Bref, au plus on aura 25 lignes par requêtes.

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

Je confirme que les requêtes sur like/dislike ont disparu, je QA plus profondément après le miam.

Il reste la dernière de mon post :

/home/spacefox/dev/django/zds-site/zds/utils/templatetags/topbar.py in top_categories(44)
  for key, group in itertools.groupby(tgs, lambda item: item["tags"]):

Lancée dans /home/spacefox/dev/django/zds-site/templates/base.html : {% with top=user|top_categories %}

SELECT DISTINCT
    `forum_topic_tags`.`tag_id`, `forum_topic`.`id`
FROM
    `forum_topic`
        LEFT OUTER JOIN
    `forum_topic_tags` ON (`forum_topic`.`id` = `forum_topic_tags`.`topic_id`)
        INNER JOIN
    `forum_topic_tags` T5 ON (`forum_topic`.`id` = T5.`topic_id`)
WHERE
    (`forum_topic`.`forum_id` IN (1 , 16, 2, 17, 3, 18, 19, 20, 23, 21, 22, 24)
        AND T5.`tag_id` IS NOT NULL)
@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

je vais regarder pour les top_categories, mais j'avoue que c'est un code
que je ne maîtrise pas trop.

Le 08/01/2016 20:48, SpaceFox a écrit :

Je confirme que les requêtes sur like/dislike ont disparu, je QA plus
profondément après le miam.

Il reste la dernière de mon post :

|/home/spacefox/dev/django/zds-site/zds/utils/templatetags/topbar.py in
top_categories(44) for key, group in itertools.groupby(tgs, lambda
item: item["tags"]): |

Lancée dans /home/spacefox/dev/django/zds-site/templates/base.html :
|{% with top=user|top_categories %}|

SELECT DISTINCT
forum_topic_tags.tag_id,forum_topic.id
FROM
forum_topic
LEFT OUTER JOIN
forum_topic_tags ON (forum_topic.id = forum_topic_tags.topic_id)
INNER JOIN
forum_topic_tags T5ON (forum_topic.id = T5.topic_id)
WHERE
(forum_topic.forum_id IN (1 ,16,2,17,3,18,19,20,23,21,22,24)
AND T5.tag_id IS NOT NULL)


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

@gustavi

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

Bon courage, ce code est dégueulasse.

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

Si on arrive à l'optimiser, ce serait massif, parce qu'apparemment on retrouve cette requête partout.

@gustavi

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

C'est l'affichage du menu.

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

Ha oui, si on fait cracher > 5000 lignes à MySQL juste pour afficher le menu…

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

J'ai une piste, mais j'aimerai la mettre dans une autre PR tellement ça
risque de tout casser au début.

Le 08/01/2016 20:54, SpaceFox a écrit :

Ha oui, si on fait cracher > 5000 lignes à MySQL juste pour afficher
le menu…


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

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

OK pour une autre PR

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

QA OK, par contre je ne serais pas contre un petit squash avant de merger.

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

je m'en occupe

Le 08/01/2016 22:15, SpaceFox a écrit :

QA OK, par contre je ne serais pas contre un petit squash avant de merger.


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

@artragis artragis force-pushed the artragis:one_slow_query branch from ff3dd1a to b747de4 Jan 8, 2016

@artragis

This comment has been minimized.

Copy link
Member Author

commented Jan 8, 2016

squashed

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 8, 2016

C'est nickel, merci !

SpaceFox added a commit that referenced this pull request Jan 8, 2016
Merge pull request #3275 from artragis/one_slow_query
enlève une requête lente car elle récupérait trop de données.

@SpaceFox SpaceFox merged commit 8f716e3 into zestedesavoir:dev Jan 8, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@SpaceFox SpaceFox added this to the Version de développement milestone Jan 8, 2016

@gustavi gustavi added the S-BUG label Jan 9, 2016

@SpaceFox

This comment has been minimized.

Copy link
Member

commented Jan 9, 2016

Je lie #3134 qui semblait correspondre au probleme corrigé ici.

@artragis artragis deleted the artragis:one_slow_query branch Apr 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.