Annonce

Écrire une réponse

Veuillez écrire votre message et l'envoyer

Cliquez dans la zone sombre de l'image pour envoyer votre message.

Retour

Résumé de la discussion (messages les plus récents en premier)

Ishido
2014-11-05 01:43:28

Bonsoir,

Je ne sais pas si la réponse est pour moi, mais si c'est le cas, petite précision, je suis pas un codeur truc bidule, c'est donc du Chinois la réponse :-) Mais ça sera utile pour ceux qui comprenne ^^

En lisant la fin de ta réponse, j en déduis que tu parles bien de ralentissement pendant la navigation et non pendant l'upload d'images.

Merci :-)

fabricefacorat
2014-11-05 01:38:42

Je vais essayer d'être plus précis dans ce que je dis :

- lorsque MySQL doit faire des GROUP BY/DISTINCT, il doit créer des tables temporaires. Si max_heap_table_size et tmp_table_size sont trop petits, alors il a copier ces tables temporaires de la mémoire vers le disque dans le dossier temporaire de MySQL ( tmpdir ). Tu te doutes bien que si il les mets sur disques, la requête sera bien plus lente : tu es I/O bound et non CPU bound dans ces cas.

http://dev.mysql.com/doc/refman/5.5/en/ … ables.html
http://www.percona.com/blog/2007/08/16/ … ry-tables/

- Si tu as pleins de RAM, tu peux passer /tmp en tmpfs ( ramdisk ) et donc même si tes valeurs de max_heap_table_size et tmp_table_size sont trop petites, il va créer des tables temporaires dzans /tmp qui est ... en RAM :D une ramdisk dont l taille est la moitié de ta RAM au max me semble raisonnable avec 16Go de RAM
http://dba.stackexchange.com/a/29638

Après tout dépend bien sûr du nombre d'albums et de photos, car plus tu as d'albums, plus ta jointure entre piwigo_images et piwigo_image_categories sera consommatrice. De plus les requêtes les plus lourdes ne sont lancées que sur certaines pages spécifiques. Cependant je pense qu'avec suffisamment de RAM et un MySQL correctement configuré, Piwigo scale très très bien avec le nombre de photos, même si des choses pourraient être améliorées.

Après pour les ralentissements quand tu as des uploads, cela peut avoir différentes origines.
En tout cas une synchronisation après upload FTP est super rapide à faire, et surtout cela n'invalide le cache des requêtes de MySQL qu'une fois. à contrario, si tu ajoutes photos par photos, le cache de requête de MySQL doit être invalidé à chaque fois : http://www.taos.com/2013/04/10/understa … ery-cache/

Ishido
2014-11-04 19:52:44

Merci :-)

Et pour la 2 ème question ?

plg
2014-11-04 19:45:30

Ishido a écrit:

@Plg, j ai regardé la Galerie, il y a que 623 photos ?

623 publiques, mais 86k en tout. Mais l'important c'est bien qu'on a des tables avec beaucoup de lignes. C'est cela qui "peut" ralentir. En l'occurence, 86k c'est pas grand chose. Si on parlait de 1 million de photos, là peut-être qu'il y aurait des optimisations à faire, mais c'est un autre ordre de grandeur, rarement atteint dans un Piwigo.

Ishido
2014-11-04 19:41:41

Bonjour,

flop25 a écrit:

on est d'accord que là on ne parle que de synchro comme méthode qui fait laguer ?

Je re up la question, on parle de lenteur pendant la visite de la galerie ou Uniquement pendant les transferts de nouvelles images ?

@Plg, j ai regardé la Galerie, il y a que 623 photos ?

Merci :-)

plg
2014-11-03 15:57:04

Voici un Piwigo de volumétrie similaire (86k photos) http://songsview.piwigo.com

Vous trouvez lent ? Et bien sachez que ça tourne sur un serveur de ce type http://www.ovh.com/fr/serveurs_dedies/s … FS-12T.xml donc un processeur Intel Atom C2750 (très très loin des performances d'un Xeon E3 1220v2). Et bien sûr il y a d'autres Piwigo sur le même serveur !

plg
2014-11-03 15:53:16

Attention, je modère un peu ce que dit fabrice, pour ne pas que les lecteurs se disent qu'avec 90k photos on atteint les limites de Piwigo, hors optimisation.

Sur Piwigo.com, il y a des Piwigo avec 300k+ photos sur des serveurs moins véloces que celui de fabrice et il n'y a pas le moindre problème. En plus il y a des centaines (voire milliers) d'autres Piwigo qui tournent en même temps sur le même serveur. Et pas d'optimisation particulière sur MySQL.

En revanche, sur Piwigo.com toutes les photos sont ajoutées une par une, contrairement au processus de synchronisation.

flop25
2014-11-03 15:28:21

on est d'accord que là on ne parle que de synchro comme méthode qui fait laguer ?

oliverfr
2014-11-03 13:58:13

S'il te plaît Fabrice, est-ce que tu pourrais "développer" cette partie ?

définir une taille suffisante pour max_heap_table_size et tmp_table_size pour éviter qu'ils ne crée ses tables temporaires sur disques

J'ai pu tester un problème voisin (plus de 100k images, pour nombre de visiteurs suffisamment élevé, et apparemment apache+php en fastCGI, contrairement à Nginx-php-FPM (je n'ai trouvé personne pour tester Apache+php-FPM ^^) ça se met à faire ramer à mort le serveur au moindre upload, avec les mêmes conséquences, tables temporaires et tout.

Si tu peux partager ta méthode pour décider d'optimisations là-dedans afin que Piwigo marche mieux, pour éviter les tables temporaires (j'ai 16 GO de RAM inutilisés, je ne demande qu'à les voir aspirés !), je suis preneur, merci beaucoup :)

fabricefacorat
2014-11-03 13:14:38

Il y avait un gros problème du serveur MySQL précédent que les équipes d'OVH n'ont détecté que très tardivement => donc préférer un serveur dédié plutôt qu'une plateforme mutualisée qui lorsqu'il y a des problèmes est plus difficile à débugger.

Parmi mes observations pour un gros volume de photos concernant Piwigo :
- Pas de problèmes côté code de Piwigo, par contre le problème vient plus côté BD
- Piwigo fait pas mal de SELECT DISTINCT/GROUP BY avec des jointure notamment entre piwigo_images et piwigo_image_categories sans clause LIMIT qui provoquent la création de table temporaires => définir une taille suffisante pour max_heap_table_size et tmp_table_size pour éviter qu'ils ne crée ses tables temporaires sur disques
- RAM RAM RAM, et encore RAM : il faut suffisamment de RAM et une taille confortable de key_buffer_size
- Si trop de requêtes passent en "on disk temporary table", mettre /tmp en tmpfs en RAM :D

Donc une fois le tuning DB fait, tout devrait rouler. Et surveiller de temps en temps au fur et à mesure que le nombre de photos augmente.

Ishido
2014-11-03 02:20:41

Merci pour le lien

Depuis le changement, plus de ralentissements ?

Je suis pas un expert, donc votre serveur c est un dédié ? Quand je regarde la puissance du serveur c est la même pour le serveur Sql ?

Pour la quantité  de photos que vous avez, il faut un dédié obligatoirement ou un mutualisé" amélioré " suffit ?

Merci pour vos réponses car j ai peut-être un projet où la galerie aura je pense 200 ou 300 000 photos.

( d ailleurs Piwigo a une limite ? )

Merci

fabricefacorat
2014-11-03 00:02:48

l'URL du site a change, voici la nouvelle URL : http://photos.websalsazur.com/

Pour le serveur, c'est une dedibox classique 2014 v2 ( Intel® Xeon® E3 1220 v2, 16Go RAM, RAID 1 SATA, Ubuntu 14.04 LTS, MySQL 5.5 tuné avec mysqltuner et autre ) :
http://www.online.net/fr/serveur-dedie/ … ssic2k14v2

Ishido
2014-11-02 19:21:43

Bonjour,

Si j'ai bien compris, le ralentissement était dû aux performances du serveur de votre hébergeur

Pourrez vous indiquer les performances du nouveau serveur ? Et savoir si ces ralentissements sont toujours présents ?

Je ne sais pas si votre galerie est publique, si c'est le cas ça m intéresse d avoir un lien, pour me rendre compte de ce que ça donne en terme de fluidité un site avec autant de photos.

Merci :-)

P.S : Je viens de voir l url du site en page 1 :-)

fabricefacorat
2014-10-17 18:39:35

Ok,

j'ai procédé à des tests sur mon serveur dédié en synchronisant les dossiers, puis en synchronisant les photos mois par mois ( ~ 9 000 photos chaque mois ). Je n'ai eut aucun problème pour charger les photos, et je suis allé jusqu'à 2 ans, soit 232 836 photos.

Au bout de 200 000 photos, en consultant mes slowqueries, j'ai remarqué que je commençais à avoir seulement quelques requêtes > 1 secondes :


root@sd-48702:/var/www/websalsazur/galleries/2012/2013# grep Query
/var/log/mysql/slowqueries.log | cut -f3 -d" " | sort | tail -n 10
0.549440
0.579074
0.648145
0.654104
0.681259
0.736319
0.741843
0.766754
2.310792
2.796499

# Query_time: 2.310792  Lock_time: 0.000089 Rows_sent: 0  Rows_examined: 386406
SET timestamp=1413411009;
SELECT DISTINCT(id)
  FROM piwigo_images INNER JOIN piwigo_image_category ON id=image_id
  WHERE category_id NOT IN (0)
    AND level>8;


# Query_time: 2.796499  Lock_time: 0.000072 Rows_sent: 232836
Rows_examined: 931344
SET timestamp=1413411269;
SELECT DISTINCT(id)
  FROM piwigo_images
    INNER JOIN piwigo_image_category AS ic ON id = ic.image_id
  WHERE date_available>=LEAST(SUBDATE(CURRENT_DATE,INTERVAL 7
DAY),SUBDATE('2014-10-16 00:13:38',INTERVAL 1 DAY))
  ORDER BY date_available DESC,date_available DESC, file ASC, id ASC;


Par conséquent le problème vient vraiment de la BD côté OVH.

Cependant, mes investigations m'ont montré quelques axes d'améliorations possibles côtés Piwigo :
- race condition dans mass upload si ajout de photos en parallèle car on gère manuellement les id des images,
- quelques requêtes SELECT avec des DISTINCT et/ou des JOINS qui pourraient être optimisées ou mis en cache,

Par exemple cette requête sans la jointure sur piwigo_image_category voit son temps d'exécution divisé par 2 :
SELECT DISTINCT(id)
  FROM piwigo_images
    INNER JOIN piwigo_image_category AS ic ON id = ic.image_id
  WHERE date_available>=LEAST(SUBDATE(CURRENT_DATE,INTERVAL 7
DAY),SUBDATE('2014-10-16 00:13:38',INTERVAL 1 DAY))
  ORDER BY date_available DESC,date_available DESC, file ASC, id ASC;


- Piwigo affiche TOUTES les nouvelles photos uploadées sans limites hors celle des 7 derniers jours mais si on upload 100 000 photos dans la journées, Piwigo affiche les 100 000 photos dans la gallerie "Nouvelles photos"

Si j'ai le temps, j'essaierai de proposer des patchs.

En tout cas merci pour votre attention. De notre côté on va voir pour changer d'hébergement, mais aussi évaluer piwigo ou plusieurs instances de piwigo ou une autre solution pour héberger et afficher au moins 5 années de photos ( ~ 5 * 100 000 photos )

rvelices
2014-10-16 10:01:09

Bonjour,
Peut-etre les requetes piwigo peuvent etre optimisées, mais je pense qu'ici il s'agit d'un pb. de config de serveur MySql car:
a) en regardant les requetes lentes: 12 à 50 secondes (moyenne à 20) sans lock time, sans aucune ligne a enovyer et analyse de 194k lignes c'est vraiment pas normal. Par ailleurs dans ce cas temp table ou pas temp table / DISTINCT ou pas DISTINCT le resultat est le meme car aucune ligne ne matche

b) Les corruptions des tables ne peuvent pas venir de piwigo. Piwigo peut inserer peut etre des donnees incoherentes mais jamais corrompre les tables. En general les corruptions apparaissent si le demon MySql ou la machine l'hebergeant crashent intempestivement. Ou encore si le disque utilisé pour les bases crashes.

J'espere que le disque qui heberge physiquement les bases est bien local ou serveur mysql ...

Pied de page des forums

Propulsé par FluxBB

github twitter newsletter Faire un don Piwigo.org © 2002-2024 · Contact