Librairie GD et ressources serveur ?

[arnotw]

Bonjour,

Je dois developper une galerie pour un client qui deposerait 60 à 100 photos par semaine.

D'habitude, je fais un formulaire d'upload qui permet de rentrer les photos une par une par http.

Mais la, je voudrais que les photos soient deposées "brutes" en jpg dans un repertoire en FTP (manipulation moins ennuyante et pas de probleme pour les fichiers de + de 1Mo).

Pour cette application, les instructions GD sont :

- la photo source est redimensionnée en 800x600px.

- je créé un png de meme dimension avec des formes et decoupes.

- je fusionne l' image avec le png à 50% alpha.

- je re-fusionne avec un logo en png (pour le copyright)

- je refais la meme chose pour la vignette en 150px (à partir de l'image source, car sinon la vignette est "crade")

- Je detruis l'image source

Ensuite lors de la creation de la nouvelle galerie dans l'admin, le script traiterait toutes les photos du repertoire.

Mes questions sont donc :

Est-ce la bonne méthode ?

En effet je lis beaucoup que GD consomme un max de ressources serveur, mais je ne trouve pas beaucoup d'infos concretes à ce sujet.

J'ai un serveur dédié avec une quarantaine de sites dessus (peu gourmand) et je ne voudrais pas que cela leur nuise.

Merci de vos conseils !

Arno

[Cariboo]

Pas de problème pour le type d'application que tu prévois de faire... C'est à dire générer une nouvelle image une seule fois.

Certains développeurs créent des scripts qui génèrent des images à la volée, GD est donc lancé à chaque appel de page, et même parfois plusieurs fois ! Là, oui, cela met le serveur à genoux.

[arnotw]

Merci Cariboo de ta reponse, mais je pense qu'ici mon application se situe dans le cas d'images à la volée ...

En fait, lors de la creation d'une galerie, le script va traiter toutes images "brutes" du repertoire d'un coup.

Pour un chargement de page, l'application va créer de 800 images (si on inclus les vignettes) pour 100 images dans le repertoire.

... du moins si je ne m'abuse.

Je sais pas si ça tient la charge, alors je me renseigne avant d'attaquer le morceau.

Merci

arno

[destroyedlolo]

Oui, en effet GD est tres consomateur de ressources et j'ai remarque que meme si ton script est bien programmer, Apache ne libere physiquement les ressources que quant il veut (donc tu te retrouve parfois avec des process httpd qui utilisent plusieurs 10ene de Mo de RAM).

Tu as 3 solutions pour que ca se passe bien :

1. Tu traites toutes les images dans le meme script : dans ce cas et si tu libere correctement les ressources, PHP utilisera toujours les memes zones memoire donc le process httpd restera dans la limite du raisonable. Le probleme etant bien evidement de ne pas tomber en timeout.
   
2. si tu es encore sous apache 1.3, tu kill le process fils une fois que le traitement est fini. Je n'ai plus le nom de la fonction sous la main (voir la doc de PHP) mais l'interet est que tu es sur que le process est libere ainsi que la memoire qu'il utilisait.
   
3. tu utilise un script CGI externe pour le traitement des images.
   

Voila

Lolo

[Jeromnimo]

Bonjour,

je rejoins Cariboo dans ma réponse.

Si tu enregistres les miniatures et toutes tes images avec logo une fois générées, il ne devrait pas y avoir de problèmes.

La seule grosse consommation posible reste la toute première génération, si tu as deja beaucoup d'images à traiter (redimensionner, mettre le logo et créer la miniature..)

ENsuite, si tu fais ça à l'upload de chaque photo, ça ne va consommer que peu de ressources à chaque fois ;-)

Un conseil tout de même, pense bien à faire des unset de tes variables inutilisées quand tu as terminé ;-)

[arnotw]

Ok,

Donc, en fait, je peux les traiter en une manip à condition de bien libérer la mémoire.

Pour le moment je n'avais prévu qu'un "imagedestroy()" à la fin de la boucle pour killer l'image en cache, mais je vais aller lire la doc d'apache2 pour libérer la mémoire.

De toutes manières, une seule galerie ne sera générée par semaine, c'est histoire de quelques secondes.

Je ferai tout de même des essais prudents et regarderai le monitoring de la machine.

Merci

arno