Bonjour à tous,  
 
Voila, il y a 2 ans j'ai créer ce site http://www.kevsigns.fr pour apprendre à utiliser jquery.  
 
C'est donc adressé pour le moment aux joueurs de World of Warcraft. Le concept est de générer une bannière dynamique jpg via php en intégrant les informations du personnages ( parsé depuis wow-europe.com ) et en les mettant à jours. Une fois la signature créer elle est donc stocké en base de donnée et remis à jours 1 fois par jour.  
 
En gros :  
 
1) On indique le pseudo  
2) Je parse l'armury de world of warcraft avec curl pour récupérer les infos  
3) je génère l'image en intégrant les infos avec la librairie gd
4) L'image est stocké directement dans la base de donnée dans un champ blob  
 
Seulement voila, le site a eu plus de succès de prévu, je me retrouve avec une base de données de 5go et plus de 150 000 affichages par jours
 
Ma question est donc, comment auriez vous fait pour stocker les images ? Je ne sais pas pourquoi mais je suis certain que ma façon de procéder n'est pas la bonne  
 
Je suis en train de refondre le site en convertissant le code en POO et en utilisant MVC je voudrais repartir sur de bonnes bases ! Donc votre avis m'intéresse !  
 

Salut.
Tu stockes actuellement tes images dans la bdd? Perso, je stockerais leur path dans la BDD, et mettrais les images dans des répertoires.. ça t'aideras pas mal à avoir une base de données plus raisonnable.
 
À part ça, pour le reste du site tout marche comme il faut? Pourquoi le refondre dans ce cas (et surtout, pourquoi le faire en PHP) ?
 
En tous cas, félicitations à toi pour ton succès

Encore toi Esox_ch ! Décidément, je vais bientôt devoir te faire un virement paypal pour ton aide  
 
Pourquoi PHP ? Que proposes tu lol ?  
 
Tout marche ? J'ai pas touché le site il  y a plus d'un an et j'ai vraiment codé ça comme un bourrin j'ai des choses qui ne marchent plus et je voudrai ajouter un tas de fonctionnalités pendant que j'ai le temps.
 
Et puis ce sera aussi l'occasion pour moi de tester cakephp.

Franchement, moi je conseille PHP lorsque le site est tellement simple qu'il ne demande même pas forcément une connexion à une BDD autre que SQLite.. Ou alors pour des sites pour lesquels on veut uniquement changer quelques fonctions, mais sans les reprendre à 0.
 
Sinon, si tu veux vraiment retravailler ton site en profondeur pour ajouter de grosses fonctions, implémenter une gestion de mise en cache sérieuse, etc, je conseille des langages plus récents et solides.
En plus ça te permet de t'auto-former dans quelque chose d'autre
 
Ceci étant dit, il existe plusieurs alternatives plus solides (J2EE, Python-Django, Ruby-Rails,... ). Personnellement je ne travaille actuellement qu'avec Ruby on Rails. Il n'a certes pas la prétention d'être aussi solide et complet que J2EE, mais c'est aussi beaucoup plus léger à mettre en place, administrer et à coder.. Après comme toujours c'est des querelles de chapelle (surtout entre les fans de Python et ceux de Ruby).
 
Bref : Si tu veux refaire vite fait ton site sans trop changer les choses => Part sur PHP
Sinon => Par sur un nouveau langage. En plus, implémenter une structure MVC et écrire bien en POO en PHP faut vraiment avoir du courage, parce que le langage te mets continuellement (et stupidement) des bâtons dans les roues... Suffi de regarder leur gestion des erreurs&exceptions qui est d'une stupidité sans limites.
 
P.S: Pour tout versement sur mon compte Paypal, n'hésite pas à m'envoyer un MP (    )

tu génères une clé unique pour chaque image ( oit un id, soit un ode alphanumérique)
tu stocke ce code en bdd
tu stockes l'image dans un repertoire non accessible depuis le web
tu fais un script ( en php ou en Ror comme va te propsoer esox ) qui prend en paramètre le code de l'image , qui va la chercher et l'affiche.
en php ça donne un truc comme ça

//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);

et tu l'appelles comme ca

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

Sans compter qu'en Rails par exemple, t'as une gestion de mise en cache de tout ce genre de process qui poutre grave

Disons qu'avant de passer à un autre langage j'aimerai bien finir d'approfondir php mais c'est vrai que j'entends beaucoup parler de J2EE.  
 
Donc ! Je pars sur un stockage physique du jpg dans un dossier alors !  
aïe aïe aïe 30 000 fichiers dans un dossier ... J'ai jamais vu ça ^^

si tu as tant de fichier que ça , tu fait une arborescences avec des étages :  
exemple si ton code image ( qui peut etre le md5 de l'image par exemple)  est AB242350F , tu peux la stocker dans  
$basePath/A/B/2  
 
comme ça , tu as des repertoires qui contiennent 36 sous repertoires  
le dernier étage ne contienra plus grand chose pour le coup

Rien ne t'empêche de faire plusieurs dossiers hein, genre 1 pour chaque "1ère lettre" du nom du fichier.
J2EE c'est bien mais faut vraiment se dire que c'est une centrale nucléaire: C'est long à construire, c'est compliqué à utiliser, si qqch va de travers ça peut être la cata, mais t'es sûr que ça sera toujours assez solide pour ce que tu veux faire. Donc partir sur du J2EE pour ton site, perso je trouve que c'est vraiment over-kill ..
P.S: Faire un site comme le tien (à ce que je vois), c'est fait en 2 jours en Rails (4 si tu parts avec 0 connaissances en Ruby)

Et niveau hebergeur , ça donne quoi ror ( c'est une vraie question, pas un troll)

Oui javai pensé à cette éventuel possibilité.  
 
Par contre je n'ai jamais vu ce genre de ligne.  
 
$code= $_GET['code'] ? $_GET['code'] : 'default' ;
 
Que veut dire le ? et :  

c'est une version compacte de if($_GET['code']) { $code = $_GET['code'] ; } else{ $code='default',; }
 
ça s'appelle l'opérateur ternaire

2 jours ! Ca me prendra plus que ça lol ..  
 
Tiens si tu veux voir ce que ça donne. tappes "KEVLN" ( avec un L ) dans le champ pseudo ici http://www.kevsigns.fr/create.php  
 

Gratuit, j'en connais pas. En même temps, je trouve qu'un site web sur un hébergeur gratuit c'est déjà limite pour mettre des photos de vacances tellement la bande passante est pourrie en général.
Sinon dans les trucs payants, il y en a pas mal pas trop cher. On en trouve plusieurs conseillés directement sur le site Rails, ou alors sur le topic rails de ce forum.

Edit : Je persiste, 2jours. Tout ce que tu fais avec du JS, il y a des helpers qui le font pour toi en Rails

Au moins j'ai pas de problèmes du coté hébergement, les petits sites à la con que j'ai me permettent de pouvoir avoir un dédié chez ovh.

d'un autre côté un dédié/VPS, c'est  plus de liberté, mais aussi plus d''administration

A noter que je n'ai pas parlé de gratuit non plus, mais les prix des hébergeurs  trouvés sur le site de Ror sont quand meme vachement plus élevé que l'équivalent php/mysql

Si tu compares RoR, ne le compare pas  à php, mais plutôt à symfony,non?

Bof l'entrée de gamme c'est dans les 40€ / année
C'est clair qu'à ce prix là, t'as pas de quoi faire énormément, mais dès que tu commences à avoir un site un minimum sérieux, tu vas prendre un VPS et donc le prix sera le même quelque soit la techno

+1 pour les images hors de la BD. Et au passage, beaucoup sous-estiment les impacts que peut avoir un bon tuning de Mysql. En augmentant la valeur de certaines variables de Mysql (tout ce qui touche aux tables temporaires, taille du cache...), on peut améliorer grave les perfs par rapport à la conf de base livrée par mysql. En faisant quelques modifications, j'avais amélioré de 30% les perfs de mon appli Astres (cf ma signature)
 
Et puis pour les grosses requêtes, un petit coup de EXPLAIN peut révéler un mauvais choix d'index pour les jointures. Ca aussi, ça peut faire gagner pas mal de temps.

J'suis d'accord parce sinon, juste acec ruby, on ne fait que des plugins sketchup

 
Boy you are so wrong

Je ne demande pas mieux qu'on me montre la lumière

Même si Ruby s'est largement démocratisé à travers Rails, il reste tout de même un langage à part entière.
Suffi de voir le nombre de gems utiles qui n'ont rien à voir avec Rails (par exemple tous les packages pour faire des GUIs).
En ce qui me concerne, le seul gros défaut qu'à Ruby en ce moment c'est que les devs n'ont pas encore trouvé une manière efficace de gérer proprement les CPUs multi-cores, et que donc quoi que tu fasses, tu te retrouves tout ton programme sur le même coeur
Pour une appli Rails, c'est pas vraiment une limitation, mais pour une appli métier là tu as mal. C'est d'ailleurs la raison principale ayant poussé Twitter à cesser d'utiliser Ruby pour leurs opérations "serveur" au profit de Scala

 

php commence à se démocratiser face à j2ee, alors ruby a encore un peu de route a faire

Si tu penses ça, ça montre bien que t'as absolument rien compris à la question

Ror est dans une niche alors dire que Ruby s'est largement démocratisé au travers de RoR, c'est un peu optimiste quand même  

- Relit ma phrase. Ruby s'est fait connaître grâce à Rails. J'ai pas dit que Rails était largement répandu
- Comparer PHP à J2EE est une aberration à tous les niveaux possibles. Suffi d'avoir utilisé les 2 technos pour se rendre compte que c'est comme comparer une calculatrice solaire à un BlueGene
- Parler de niche pour RoR n'a aucun sens. C'est une techno qui n'est pas encore autant (re)connue que PHP car beaucoup plus jeune, ce n'est pas pour autant qu'elle est dans une niche. Une niche signifiant un "marché" particulier différent de l'environnement "général".

- Ruby se fait connaitre grade a Ror (donc ruby seul est moins connu que RoR) , Ror est peu connu , donc Ruby est très peu connu. CQFD.

-tu compares bien RoR (le framework qui va bien) a php (le langage) , pourquoi ne pas comparer php a j2ee ?

-je ne suis pas gros , j'ai de gros os. Tu peux jouer sur les mots tant que tu veux, RoR est petit à l'échelle du développement web . Peut être qu'un jour ce sera un des langages majeurs, mais aujourd'hui, ça ne l'est pas. A noter que php avec des acteurs comme FB  pour ne citer que lui, assure une certaine pérennité.

Salut, pourquoi tu ne crées pas les images dynamiquement ? avec une gestion de cache quotidien ça serait bcp plus économique en place, en rapidité...

- Tout à fait d'accord, j'ai jamais dit le contraire.
- Abus de langage de ma part. Reste que sans framework Web, avec Ruby tu peux pas faire de page web facilement. Donc comparer Ruby et PHP n'a pas beaucoup de sens non plus. Par contre comparer PHP à J2EE ça n'a tout de même aucun sens parce que tu ne vas pas les utiliser dans le même contexte (à part si tu as des tendances profondément maso)
- Je joue pas sur les mots . Cobol est dans une niche : C'est un langage totalement dépassé mais qui survit parce qu'il y a une telle quantité de lib métiers (notamment de traitement bancaire) en Cobol qu'aucun langage ne peut le remplacer. Mais Rails n'est dans aucune niche, c'est juste pas très connu

@Rengzehn: C'est plus ou moins ce qu'il fait à ce que j'ai compris. La question étant :Qu'utilises-tu comme cache. Lui utilise des répertoires sur le disque. Tu pourrais le mettre dans la ram, mais bonne chance avec 30'000 images. Selon moi son système tient la route..

bhen non justement, est ce utile de générer toutes les images tous les jours ? en ça je trouve qu'il se trompe en disant qu'il "crée dynamiquement des signs"

pour le cache, un cache sur disque suffit

après c'est lui qui connait sa bdd mais j'imagine que tous les users n'appellent pas leur sign tous les jours...

pour moi dynamique ça veut dire : un user appelle sa sign, le prog la génère si elle n'existe pas, la met en cache et à 4h du mat tu vides ton cache.

amha il génère un gros volume de données pour rien : les fonds sont redondants etc etc

par exemple je viens de créer une sign dans sa base et je ne l'utiliserais jamais, est ce utile de la générer tous les jours ?

Oui t'as raison. Il devrait probablement faire des tests pour voir les stats d'utilisation et en déduire la meilleure solution

d'accord avec, dynamiquement = fais à la demande (pour moi)
 

la aussi c'est vrai, ça pourra lui faire gagné de la place et surtout pas d'actualisation pour rien et aussi de la bande passante,...
 
mais avant tous, Anycee, excellente idée et très bonne réalisation

ensuite refaire le site en ror, s'il part d'auncune connaissance dans ce langage, je ne crois pas que ce soit une bonne idée.
Il va faire comment pour traiter les erreurs de dev, ou autre problème, il va passer plus de temps à rechercher pourquoi ça marche pas qu' autre chose.
Ensuite j2ee pour un site web je ne suis pas convaincu...

j2ee pour ce genre de site web ça n'a aucun sens  
Il faut sortir l'artillerie lourde quand c'est nécessaire, pas pour descendre les moineaux.
 
J'ai commencé Rails un jour où j'en avais marre de me battre contre PHP pour un gros site que je développais pour une boîte. Je me suis dit "Voyons combien de temps ça me prend en Rails pour refaire ce que j'ai fait en 1 mois et demi en PHP ". ça m'a pris 1 semaine et demi, avec aucune connaissance en Rails alors que ça faisait 3-4 ans que je faisais du PHP tous les jours
Après, peut-être qu'avec Symphony on peut faire le même genre de truc.. Reste que quand je compare la puissance de la syntaxe de Ruby (dont la ultra-grande majorité vient du fait qu'il supporte la meta-programmation) à celle de PHP... C'est juste une évidence..

Mince je n'avais pas vu toutes vos réponses !
 
alors j'utilise le terme dynamique car en fait le but premier de mon site est de créer une signature avec les statistiques d'un personnage world of warcraft. La signature a donc besoin d'être mis à jour de temps en temps pour que les infos sur la signature ne soient pas obsolète ! Pour cela j'ai un cron qui se lance toutes les 10 minutes. Dans ma bdd j'ai un champ "cachetime" & "displaycount" et ce cron vas d'abord mettre les signatures les plus vieille à jour. J'ai aussi un facteur nombre d'affichage qui entre en jeu, plus la signature est affiché plus elle sera mise à jours régulièrement.  
 
Pourquoi pas les créer à la volée ? Car je parse les données du site armory.wow-europe.com et que celui-ci me bloque lorsque je fais plus de X requêtes en moins de X secondes ( d'ailleurs ça me pourri la vie je suis obligé d'y aller à coup de sleep(3) entre chaque mise à jours).

c'est ce que je ne comprends pas, si la bdd est bien foutue, tu ne devrais meme pas avoir à stocker d'images. Pourquoi ne les génères tu pas à la volée ?

Une fois que la personne a choisis le design, l'image est enregistré en blob et disponible via une url http://sign.kevsigns.fr/123456.jpg et chaque jour elle est mise à jours avec les donnés du personnage.  
 
Mais en fait je me rend compte que je suis totalement débile. En effet, pourquoi pas garder uniquement dans la base de données les données du personnage et générer les images à la volé.  
 
Mais du coup pour un gros traffic @ 100k 500k affichages par jour ca va pas bouffer énormément de ressources le imagecopyfromjpg() ... imagejpg() ?

Question bête : t'a pas moyen de créer la signature juste avec du html/css en jouant avec les positionnements et les z-index?

spour ça que je proposais un daily cache ^^ ce qui serait intéressant, spas tant le nombre de requetes total mais le nombre de requetes quotidien sur les memes images.

ce nombre imposant (100-500k affichages) doit être du au fait que les signs sont en général sur des forums et qu'a chaque appel d'un topic sur un forum ça tappe chez toi mais au fnal ce sont pour la plus part les memes images.

pour la vitesse de génération, le montage des signs dans gd n'a pas l'air très compliqué, ça doit aller vite

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.