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 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.

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 !

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

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.

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

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 )