Page auteur, récupération des posts partagés, lenteur systématique

[biggrizzly]

Hello,

Je fais un petit peu d'étude des lenteurs que je trouve en augmentation sur SeenThis, sur le serveur de remplacement, en cours de préparation.

J'ai un point qui m'interroge. En regardant les slow queries, la boucle BOUCLE_messages génère des lignes avec des clauses IN à répétition, contenant parfois plusieurs milliers d'ID.

J'ai remplacé dans seenthissq_fonctions.php, pour tester :

return '(id_auteur='.$me.' OR '.sql_in('id_me', array_map('array_pop', sql_allfetsel('id_me', 'spip_me_share', 'id_auteur='.$me))).')';

Par :

return '(id_auteur='.$me.' OR id_me IN (select id_me from spip_me_share where id_auteur='.$me.'))';

Et c'est plus rapide.

Mais est-ce que c'est souhaitable ?

Je constate que des appels à sql_in, il y en a d'autres.

N'est-il pas souhaitable de tous les remplacer de cette façon ? Cela laisse à priori l'opportunité à l'optimiseur de travailler à ce qu'il sait faire.

J'ai le même genre d'interrogation sur les auteurs bloqués, qui génèrent là aussi parfois des requêtes lentes, exemple ci-dessous. OK, c'est une seule seconde, mais s'il y a plus performant, autant l'utiliser.

# User@Host: stprod[stprod] @ localhost []
# Thread_id: 393  Schema: stprod  QC_hit: No
# Query_time: 1.005543  Lock_time: 0.000183  Rows_sent: 300  Rows_examined: 644183
# Rows_affected: 0  Bytes_sent: 7009
SET timestamp=1714224947;
SELECT id_me,UNIX_TIMESTAMP(date) as date
FROM `stprod`.spip_me
WHERE 1=1 AND ((id_auteur NOT IN (4737,3300,3141,5023,30,2713,2816,3743,2390,1771,3191,3298,2865,1325,2692,6994,3749,4248,5007,4202,4250,4312,4095,4034,4363,4555
,4757,4760,4781,4484,4833,4750,4860,3722,4900,4938,5006,5078,5018,5080,5097,5038,4935,5145,5151,5150,5155,5205,5206,5149,5281,5189,5435,5437,5416,4357,5499,5553,
5748,5605,5327,5735,5737,5738,4719,5749,655,5754,5811,5791,5704,5894,5931,553,6017,6103,6109,6121,5429,6122,6123,6138,6145,6148,6193,6001,6218,6212,5444,5820,628
1,2555,6196,6381,6420,6427,4934,6462,6472,7769,5898,6521,8074,6692,6678,4861,2925,6741,6747,6755,6785,6798,6815,6377,6503,6905,6992,6995,7007,6993,7036,6575,7081
,7093,7100,7105,7099,7098,7027,7040,7097,6309,7119,7688,10580,7332,7363,7371,7373,7376,12002,7443,8193,6982,7516,7542,4227,7439,6634,3026,7593,7470,7625,9614,763
1,7618,7663,7657,7591,7671,7678,7687,7707,7745,7722,7787,7751,7825,7827,7710,7837,7660,7885,6719,6760,3851,7879,7906,7921,7911,7937,7918,7963,5100,7964,7927,7991
,7453,7084,7993,7996,7887,7997,7643,8036,8044,10118,5421,8079,8090,8410,8103,8096,7833,8167,8189,8195,7823,8217,8588,8314,8320,8342,8349,8374,8373,8338,8387,8394
,8398,8399,8393,8426,8436,8439,8441,8442,8453,8285,8486,8519,824,8524,8339,8527,8477,3671,8558,8579,8484,8581,8583,8591,8595,8616,8620,8624,8625,8630,8632,8637,8
533,8645,8672,8703))
AND (id_auteur NOT IN (8704,8712,8719,8725,8753,8765,8780,8781,8784,8787,8790,8803,8824,8747,8893,8827,8909,8999,9014,9048,9070,9073,9082,9083,9095,9104,9120,918
4,9195,9212,9219,9228,9240,9244,9177,9367,9381,9383,9410,9424,9509,9512,9517,9516,9515,9578,9511,1274,9723,9770,9804,9816,9838,9853,9876,9930,9932,9938,9936,9942
,9943,9954,9973,10037,10054,10061,10084,10097,10112,10115,10139,10140,10142,10147,10153,10158,10162,10167,10170,10169,10174,10177,10180,10181,10186,10190,1820,10
200,10203,10212,10217,10246,10257,10258,10263,10281,10285,10313,10322,10345,10036,10368,10389,10399,10412,10418,10424,10426,10430,10436,10438,10440,10451,10456,1
0466,10488,10468,10499,10525,10530,10547,10550,10612,10621,10629,10647,10650,2813,10692,10720,10724,10729,10745,10752,10756,10766,10781,10787,10786,10794,10736,1
1234,692,10823,10824,10828,10576,10899,10903,10905,10882,10922,10925,10931,10906,10943,10949,10950,10951,11031,11032,11030,11082,11087,11106,7436,7187,11117,1112
6,11130,11146,11148,11201,11214,11205,11228,11244,11274,3351,11283,11282,11288,11290,11289,12020,11344,11345,11243,11350,11367,8503,11375,11376,11348,11393,11396
,11404,11425,5926,11451,11490,7289,11491,11499,11507,11506,11515,11514,11517,11521,11556,11578,11608,11613,11180,11307,11322,11610,11625,11633,11635,11640,11641,
3069,11648,11650,11661,11667,11669,11670,11699,11705,11706,11686,11709,11719,10325,11730,11743,11745,11749,11733,11758,8355,11762,11769,11777,11793,11794,11800,1
1818,11812,11822,11823,11828))
AND (id_auteur NOT IN (11829,11832,11835,11839,11844,11850,11852,11872,11877,11899,11901,11897,11905,11906,11878,10362,6195,11928,11941,11923,11935,7574,11969,11
970,12005,6569,11849,11605,11747,12047,12053,12061,12064,12089,1952,12099,12093,12044,11936,12125,12123,12138,12140,11960,12143,12146,12152,12162,12165,12166,121
69,12171,12176,12182,12185,789,12201,12204,12205,12207,12210,12216,12218,12219,12222,12225,12241,12246))) AND id_parent=0 AND statut="publi"
ORDER BY date DESC
LIMIT 300 /* /all + 178.33.21.166 */;

[brunob]

Merci pour le rapport, peut-être en lien avec #159 mais c'est un gros chantier. On pourrait déjà tester les modifications que tu proposes pour avancer par petites touches.

[brunob]

Ça ne serait pas les array_map/array_pop qui plombent comme on en causait dans #187 ?

D'ailleurs j'ai modifié ce code dans la branche pour SPIP 4 cf 92bc463

[biggrizzly]

Là, je fais du profiling à la sauvage, en étudiant ce que le slow log de mariadb sort.

La façon dont les posts sont filtrés, à coup de sql_in, nécessite :

• une requête pour ramener les id d'auteurs, de partages, ..., selon le contexte
• une boucle pour les convertir en (IN (...) OR IN (...) OR...)
• une seconde requête pour ramener les id de posts

Le faire en une seule requête c'est mécaniquement mieux. Et comme déjà dit, ça donne l'opportunité à l'optimiseur d'intervenir quand on lui met une sous-requête dans le IN.

Ce qui serait encore mieux, parfois, à mon avis, ce serait de faire des join, directement, plutôt que des IN, on pourrait bénéficier de meilleurs plans d'exécution.

Pour mémoire, sur la page /all, on a une requête qui nécessite de traiter les bloqués et ce sql_in pourrait lui aussi être raccourci. Ça se passe là : plugins\seenthis\inc\seenthis_data.php

[brunob]

Il y a certainement des choses à améliorer de ce côté, mais je ne pense pas être le plus à même d'avoir un avis sur la question (du moins rapidement). Mais, reste-t-il encore d'autres personnes pour avoir un avis, là je pense est la question ^^

PS : je pense qu'il faudrait avant tout analyser le comportement sur une version à jour en SPIP 4, effectuer la mise à jour sur une instance de dev, ça c'est dans mes cordes :)

[biggrizzly]

Je souris, ce jour, après ma tentative de généraliser de remplacer les sql_in. Je constate que là où je croyais que ça avait un intéret, en définitive, ça n'en a pas tant que ça. Le souci était ailleurs, dans l'emploi d'une fonction de conversion de date mal placée. Bref, je vais maintenant travailler sur la lenteur d'enregistrement des nouveaux posts en espérant y trouver qq chose...