HELP! Lenteur suite à un grand volume de facture (ticket POS)

Utiliser mon Dolibarr
, ,
21

@eldy @FHenry

Bon, nous avons fait un clone et fait un update en V18 les listes des factures bingo, c’est plus rapide !

Par contre, j’ai cette requête qui est toujours lente quand on clique sur le menu facture avant les listes :

SELECT f.rowid, f.ref, f.fk_statut as status, f.type, f.total_ht, f.total_tva, f.total_ttc, f.paye, f.tms, f.date_lim_reglement as datelimite, s.nom as name, s.rowid as socid, s.code_client, s.code_compta, s.email, cc.rowid as country_id, cc.code as country_code, sum(pf.amount) as am FROM llx_societe as s LEFT JOIN llx_c_country as cc ON cc.rowid = s.fk_pays, llx_facture as f LEFT JOIN llx_paiement_facture as pf on f.rowid=pf.fk_facture WHERE s.rowid = f.fk_soc AND f.entity IN (1) GROUP BY f.rowid, f.ref, f.fk_statut, f.type, f.total_ht, f.total_tva, f.total_ttc, f.paye, f.tms, f.date_lim_reglement, s.nom, s.rowid, s.code_client, s.code_compta, s.email, cc.rowid, cc.code ORDER BY f.tms DESC LIMIT 3;

Si quelqu’un comprend ?

22

Bonjour,

Que dit le plan d’exécution ?

Est ce qu’il est différent avec cette version ?

SELECT f.rowid,
f.ref,
f.fk_statut as status,
f.type,
f.total_ht,
f.total_tva,
f.total_ttc,
f.paye,
f.tms,
f.date_lim_reglement as datelimite,
s.nom as name,
s.rowid as socid,
s.code_client,
s.code_compta,
s.email,
cc.rowid as country_id,
cc.code as country_code,
sum(pf.amount) as am
FROM llx_societe as s
INNER JOIN llx_facture as f ON s.rowid = f.fk_soc
LEFT JOIN llx_c_country as cc ON cc.rowid = s.fk_pays
LEFT JOIN llx_paiement_facture as pf on f.rowid = pf.fk_facture
WHERE f.entity IN (1)
GROUP BY f.rowid, f.ref, f.fk_statut, f.type, f.total_ht, f.total_tva, f.total_ttc, f.paye, f.tms, f.date_lim_reglement,
s.nom, s.rowid, s.code_client, s.code_compta, s.email, cc.rowid, cc.code
ORDER BY f.tms DESC
LIMIT 3;

23

Bon a priori, c’était qu’un problème de cache, on a augmenté le cache dans le SQL.

La V18 a corrigé les problèmes de listes
Et l’augmentation du cache a amélioré quelque petite lenteur de menu.

Pour info modification de cache fait :

max_connections=100
innodb_buffer_pool_size=8G
query_cache_size=2G
key_buffer_size=2G
innodb_flush_log_at_trx_commit=0
innodb_flush_method=O_DIRECT
query_cache_type=1
query_cache_limit=20M
table_cache=1024
join_buffer_size=40M
thread_cache_size=128
tmp_table_size=256M
max_heap_table_size=256MB

24

Après niveau hardware (CPU / Ram / Sata) tu n’es pas non plus sur une fusée intergalactique
J’image SSD en sata sans stripping

J’ai vu que vous avez solutionné. Top !
Peut-être dans la « to do list » en fonction de l’importance des données / impacte d’une non dispo) d’observer la charge IOPS / Ram / CPU pour anticiper toute saturation avant l’heure

Belle journée

25

A la vue de la requête, la réponse de cette dernière devrait être instantanée, et ce, quelque soit la taille de la base… Sauf si il n’y a pas d’index sur le champ llx_facture.tms. Ce qui semble un manque de Dolibarr par défaut.
Peux tu vérifier si tu as un index sur cette colonne et si non créer un index dessus et nous tenir au courant ?

ALTER TABLE llx_facture ADD INDEX idx_facture_tms(tms);

Si cela ne donne rien, essayez d’ajouter dans la requête, la chaine
USE INDEX (idx_facture_tms)
juste après le
… llx_facture as f
et avant le
LEFT JOIN llx_paiement_facture as pf…

26

@eldy2
Dès qu’on a un peu de temps je check ça !