Reprise du message précédent :
Salut,
Les générer à la volée (sans mise en cache) n'est pas une bonne solution. Au prix du téra maintenant, t'as intérêt à les mettre en cache sur ton HDD.
Par contre je pense que ce qui a été dit plus haut est vrai : Il faut que tu analyses tes stats d'utilisation et voies comment optimiser ton cache (par exemple en ne gardant que les images qui ont été demandées pendant les dernières 24h).
 
@rufo: Il va avoir des soucis suivant où il affiche ses bandeaux s'il les fait en HTML. Suffi que le site sur lequel il l'affiche applique des règles surprenantes à div, img, ... pour que ça devienne vite la pagaille.

sous firefox, avec la directive !important et en choisissant des ID + class à lui, devrait pas y avoir de pb par rapport au pb que tu évoques

Mais quid des autres browsers?  
Perso je trouve que c'est risqué vu que ce service est le coeur de son site

Je pense aussi que le plus fiable est l'image pour être sur de l'affichage , avec les images gardée en cache disque 24h, mais générée à la demande ( ie : si une image n'est plus utilisée elle e sera jamais regenérée)

sans parler que du html peut ensuite etre modifié par du js ( qui va ajouter des classes ou des styles par défaut)

A voir aussi pour la mise en cache : peut etre qu'il n'est nécessaire de regénérer que les images  dont le contenu à changé

aux pris du téra ? Je ne paie pas ma bande passante j'ai un dédié chez ovh. Optimiser mon cache ? J'ai aucune idée de dire au navigateur de garder l'image en cache.  
 
Et oui ce nombre important est du au fait que les signature sont affichés sur les forums ^^

 
Je pense qu'il parlait du téraoctet d'un HDD

Non mais quand je parlai de générer à la volé pour moi c'était par exemple :  
 
1) Le mec appel http://sign.kevsigns.fr/125458.jpg  
 
( j'ai un url rewriting qui pointe sur img.php?id=125458 )  
 
2) php vas chercher les infos du personnage dans la bdd ( ces infos sont mis à jour régulièrement ).  
 
3) php genere l'image  
Puis imagecopyfromjpg(template.jpg)  
imagestring('les valeur') // on importe les valeurs dans l'image ...  
imagejpg();  
avec le header qui vas bien.  
 
4) php affiche l'image  
 
Du coup la seul chose que je vais stocker en bdd seront les infos du personnage et tout mes templates de signature.

Justement, pas une bonne idée.
L'appel à ces fonctions est très coûteux en terme de ressources, il faut le minimiser.

Rufo créer une signature en html/css n'est pas le but du tout. Le but c'est qu'au final l'utilisateur obtienne un tag/url pour forum du genre [ img ]http://sign.kevsigns.fr/xxxxx.jpg[ /img ].

Du coup vous proposez quoi ?  
 
- Signatures jpg en blob dans la bdd + mise à jour de l'image -> Mais énorme base de données  ( système actuel ) ?
 
- Création à la volé + mise à jours données texte bdd -> Mais beaucoup de ressources à cause de l'utilisation constante des fonctions GD.  ?
 
 
Je vois pas .. niveau ressources j'ignore totalement ce qui pourrait être le mieux.  
 
flo850 tu parles de mise en cache hdd, cela signifi que le navigateur, s'il a déjà afficher l'image ne va pas rappeler le script qui vas régénérer l'image mais seulement afficher l'image qu'il a en cache ? Si oui ça me parait une bonne solution du coup, mais j'ai aucune idée de comment dire au navigateur de mettre l'image en cache ^^  

Non la solution est de stocker l'image générée sur le server, et faire un if(file_exists($tonimage)) -> envoie direct ->sinon tu la regénère

Bah de toute façon elle existera forcément vu qu'elle aura été créer une fois que l'utilisateur l'aura enregistrer sur le site. Donc du coup on reviens au stockage physique de toute les signatures avec toujours un cron derrière pour régénérer les jpg avec les données ressentes du personnage de l'utilisateur.
 
Un truc comme ça ne fonctionnerai pas ?
 
L'idée c'est de mettre l'image en cache navigateur pour qu'il ne recharge pas l'image avant 12h.  
 
header('Pragma: public');
header('Cache-Control: public');
header('Expires: ' . gmdate('D, d M Y H:i:s T, time() + (12 * 3600)));

 
Non plus.
 
La solution c'est: Mettre les images dans un rép où Apache puisse les trouver, sans passer par PHP. Ensuite, si l'image existe pas, alors on la régénère.
De plus, toutes les nuits à 1h du mat, on vide le rép de cache.
 
C'est fou, ça a pourtant pas l'air compliqué  

dans le test du file_exists, tu peux rajouter aussi la condition sur la date de création du fichier. Si < date_validité, alors envoi direct.
 
Edit : avec la solution du cron, t'es pas non plu obligé de tout générer d'un coup. Tu peux très bien toutes les heures (ou autre périodicité), regénérer qu'un sous-ensemble des signatures. A chaque lancement du script de régénération, tu travailles sur un sous-ensemble différent de manière à ce qu'en 1j, tu aies fait toutes les signatures qui le nécessitait Et dans le script de regénération, tu peux très bien inclure le test du file_exists + date de validité, histoire de pas regénérer une signature inutilement.

 
Oui bon l'idée est la hein

Ok donc :  
 
- Pour afficher une signature on vérifi si le cache est créer, s'il ne l'est pas on le créer et on affiche l'image.
 
- Tout les jours a 1h du matt on supprime tout les fichiers cache.  
 
- Tout au long de la journée un cron mets les infos personnage des signatures les plus affichés à jours.  
( J'ai bien pensé à mettre à jours les infos du personnage dans la bdd au moment de la génération de l'image sauf que je me ferai bloqué par wow-europe.com au niveau des requêtes par seconde quand on va arriver vers l'heure de pointe à 18h )  
 
That's it ?

ou alors le faire sur un sous-ensemble de signatures périodiquement dans la journée pour qu'à la fin de la journée, toutes signatures soient à jour.

 
yes, après à toi de placer les curseurs avec la connaissance que tu as de l'utilisation de ta base.
 
je joue pas à wow mais EVE online mais pour info, tu peux peut etre contacter les gars de battleclinic sur leur forum. Ils proposent le meme genre de service que toi :
http://eve.battleclinic.com/killbo [...] wizard.php
EVE a aussi un systeme d'API et battleclinic a dev pas mal de bonnes applications, je pense qu'au niveau code ils sont au taquet

en faite quand veux mettre à jour un profil tu :
1 - te connecte sur : armory.wow-europe.com
2 - recherche le pseudo du gars,
3 - la page qui est retourné peux comporter plusieurs ligne, je suppose que tu prend celui qui a la pertinence 100%
4 - tu récupère la page avec les infos du perso.
 
si tu fais comme ça, pourquoi ne pas stocker en BDD directement le lien vers perso : http://eu.wowarmory.com/character- [...] s&cn=Kevln
cela pourrait te permettre de ne plus avoir le délais d'attente ou un max de requete

Faut arrêter de faire de la désinformation, on ne choisi pas J2EE ou RoR juste comme ça parce que c'est plus in.
Je bosse sur une application Web en PHP qui utilise un cluster de serveur Oracle quoi...
 
Les accès BDD c'est un pb, le langage un autre.
 
Là s'il passe d'un script basique à du MVC le coup RAM et surtout CPU de chaque session concurrente va en prendre un coup c'est sur, cependant, s'il fait ça bien (avec du context switch dans son framework MVC) le path récupération d'image bypassera une grande partie du process, et avec des bon en-tête HTTP, le cache web du client sera suffisamment long dans le futur pour que personne ne demande plus d'une fois la même image chaque jour.
 
Après il y a toujours un moment où il faut savoir si on privilégie la maintenabilité ou les perfs pure.
Et également un moment où il faut avoir une volumétrie exacte.
 
Car si 95% de son trafic c'est les requête d'affichage de signature, finalement c'est 95% du trafic qui peut être géré 100% en direct par Apache si on veut optimisé au maximum.

//image.php
$basePath ='chemin/vers/mon/stockage/';
$code= $_GET['code'] ? $_GET['code'] : 'default' ;
//ici tu peux vérifier d'eventuels droits d'acces par exemple 
// tu DOIS vérifier que ton code à une bonne tete : eviter d'avoir des .. qui permettent de remonter dans l'arborescence 
 
// tu envoies les bonnes entetes
header('Content-Type: image/jpeg');
//puis l'image en elle meme
readfile($basePath.$code);

<img src="image.php?code=ZERGZEQ5749" title="signature de truc">

 
Faut faire un context switch pour zapper la couche MVC alors, sinon y'a pas plus pourri. Avec Zend Framework sans context switch, c'était ~400ms via PHP, et ~50ms via Apache quoi...
 
Avec context switch on est encore dans les ~100ms, mais bon c'est pas flagrant pour le coup.
 
Autant servir les images en utilisant Apache si c'est pour ne pas les stocker en BDD et ne pas avoir besoin d'authentification pour les récupérer.

 
Tu as vu ça où que je conseille de faire du J2EE parce que je trouve ça in?
Je dis pas que PH ne peux pas faire de gros sites, je dit juste qu'après avoir travaillé sur un site J2EE de plusieurs milions de lignes de code, et avoir travaillé sur des sites PHP (beaucoup plus petits). Je trouve qu'il y a pas photo : On voit que J2EE à été taillé justement pour faire des sites d'entreprise, avec des appli métiers derrière & co  alors qu'on voit encore que PHP signifiait (au début) Personal HomePages.
 
Ensuite, comme tu l'as dit très bien, la bdd c'est une chose, le langage c'est une autre. Donc que tu me dises que tu attaques un cluster Oracle avec du PHP, du bash ou du Java, on s'en cogne (et ta BDD aussi d'ailleurs).
 
Encore une fois, je dis pas qu'on ne puisse pas faire du code propre et fonctionnel avec PHP ( si tu bosses sur une grande structure, j'imagine que vous avez mis en place des batteries de tests de qualité vous obligeant justement à le faire). Ce que je dis par contre c'est que si on veut faire les choses proprement en PHP, on passe la moitié du temps à wraper le langage.  
Suffit de voir que la notion d'objet est implémentée à la vas-y comme je te pousse (bloquée entre un langage de typage fort et un langage de typage faible). Une gestion des exceptions totalement loufoque. La moitié des fonctions qui retournent "false" quand elles plantes et l'autre moitié que retournent "null" (avec 2-3 qui retournent 0), histoire de bien clarifier le tout. Des opérateurs genre === qui foutent dedans tout le monde,... Et pour finir, suffit d'aller voir les Changelog de PHP6 pour attraper un fou rire (merci le retour de GOTO, ça manquait décidément pour la clarté du code).
 
Donc voilà, personnellement si on me demande de dév un gros système, je vais essayer de trouver un langage qui n'essaie pas de me faire des croche-patte à chaque fois que j'essaie d'écrire qqch de rigoureux.    

l'interet de passer par un script comme celui ci est qu'il est facile d'ajouter une condition : "si le fichier n'existe pas , alors le générer", impossible en cas d'accès direct par apache