Gestion Des Objets/accessoires, Comment gérer un grand nombre d'obj ?

Salut all !! Ca fait un bout de temps que je ne suis pas repasser par ici alors comme j'avais besoin de l'avis de pros...Voila j'ai fini (enfin pour moi y'aura tjs des trucs à refaire mais tout de meme) le noyau de mon jeu. J'ai donc entamer une petite opération d'optimisation du code ce qui, a mon grand étonnement, malgré les 700Ko du jeu représente une masse de travail. Avant de continuer le développement j'aimerai optimiser ce qui concerne la gestion des objets...

J'ai pour l'instant mis que quatre objets en circulation mais les idées fusent et quand je vois a quoi ressemble le script des objets, je me dis que ca va vite devenir un vrai bordel. Je ne parle meme pas des accessoires (pour moi les accessoires c'est un peu différent des objets, ca s'achète comme des objets, mais on ne peut en avoir qu'un et ca permet de découvrir des lieux, débloquer des situations, transformer des objets, les améliorer ). En ce moment grossomodo mon script d'objet est un gros fichier de 8Ko qui est divisé en deux parties. La premiere c'est l'affichage des objets que possède le joueur, cette partie on la retrouve directement sur l'index du joueur. La seconde partie c'est lorsque le joueur clique sur un objet sur sa page d'index pour l'utiliser, elle contient donc la description de tout les objets, leurs effets, les messages a afficher... C'est cette deuxieme partie que je souhaiterais optimiser...car si j'augmente le nombre d'objets je sent que ca va vite faire un script boulet. Alors je voulais savoir comment vous vous gérer vos objets... Sachant que je ne pense pas que l'utilisation de Sql puisse etre un atout ici...

La solution qui m'est venue à l'esprit ( et j'attend votre avis ) serait de créer un petit répertoire objets...et dedans on met un fichier par objet. Ce fichier serait donc assez léger et permettrait de ne pas charger toutes les descriptions d'objet alors qu'on a besoin que d'une. De cette facon avec un petit include on arriverai à gerer un grand nombre d'objet/accessoire.

J'attends vos idées...disons qu'étant donné que les objets/Accessoires sont un peu les seules choses ( ou presque ) avec lesquels le joueur va interférer je pense que ca vaut le coup de se pencher deçu...
Merci d'avance @ciao byebye

AMHA ce n'est pas une tres bonne idee... en effet, dans tous les langages, le plus couteux est l'acces a des fichiers.

D'apres ce que tu decris, cela me semble pourtant la meilleure solution. J'aimerais bien savoir comment tu es arrive a cette conclusion !?!

Je n'ai pas lu à fond le post, si je dis une bêtise ne m'en veut pas.

Effectivement, si tu ne fais que lire des données je ne vois pas pourquoi tu devrais utiliser une DB. Ouvrir un fichier n'est pas plus couteux que de faire un select d'une grosse masse de texte, loin de là. La DB a l'avantage de gérer les accès concurent, mais quand tu ne fais que lire du texte c'est plutôt un inconvénient.

Donc à mon sens oui, découper tes fichiers avec une certaine logique pour pouvoir y accéder et les charger en mémoire directement semble être une bonne solution.

Maintenant tout dépend de ce que tu compte faire avec ça. Si tu dois souvent mettre ces objets à jour. Si les joueurs doivent pouvoir modifier ces objets, voir en créer de nouveau. Si tu dois gérer une quantité disponible de chaque objet, etc. En fonction de tout ça il se peut qu'un accès à ta DB soit plus utile.

Désolé, c'était moi au dessus.

Juste une dernière chose, il faut tordre le coup aux idées préconcues. MySQL n'est pas forcemment plus rapide qu'un accès à un fichier dans tous les cas.

C'est tout bêtement logique : MySQL (et c'est valable pour tous les SGBD) se base sur un système de fichier lui aussi, auquel il ajoute un système de cache et de gestion des accès concurents, etc... ajoutons la dessus un petit interpreteur de queries, un zeste de gestion de droit d'accès et éventuellement un poil de gestion transactionelle, et là, paf, on comprend bien qu'il n'est pas toujours aussi couteux que ça de faire un bête accès disque, tout dépend des besoins et du cas

Je n'ai pas de chiffres pour appuyer mes dires, mais je suis sûr quand même à 99,999% que c'est vérifiable.

Ca depende de quoi on parle...

D'une part, si on parle de 25 fichiers ou de 5000 fichiers dans le meme repertoire ca change pas mal de choses... Le grand nombre d'entrees dans une table est quelque chose qui est bien mieux gere par MySQL qu'un bete filsystem

D'autre part, si les fichiers sont assez gros... MySQL sera plus rapide

Cela dit, s'il s'agit de gerer 25 fichiers de 200 octets, je veux bien croire que MySQL sera plus lent

Lol, donc si je comprends bien, pour vous l'hésitation c'est entre Sql et des fichiers...Pour le cas des fichiers c'est vrai que je me retrouverai avec un dossier contenant une trentaine de fichiers de 200 octets...Mais en utilisant une base moi je vois surtout de nouveaux appels à la base et ce qui m'embetterait c'est d'arriver à un stade ou il y'aurait trop d'axx simultané et donc des limitations...

Deux choses Guest.

1. A moins d'etre vraiment polio, avant de mettre un serveur SQL sur les genoux il faut y aller de bon coeur. Je ne dis pas que c'est difficile (au contraire même) mais avec un minimum de bon sens ça ne devrait pas arriver dans ton cas.

2. Vu le peu de fichier et leur taille, la solution du file system est sans aucun doute la plus efficace.

3. Attention aux includes qui dépendent de variables, gaffe aux failles (un post en parle plus loin).

Et Cedric, si j'en ai l'occasion je ferai des tests. Je pense justement que le file system est plus efficace lors du transfert de grosse masse de données (car ton serveur sql, bête qu'il est, essaye toujours de tout mettre en cache...).

Ensuite, de mémoire, le file system Unix est basé sur des inode tables (si un gourou passe par là...) qui sont plutôt super bien pensées et permettent de retrouver un fichier très rapidement (je crois que c'est basé sur des trees, mais je n'ai plus les détails en tête). Bon, cet argument est bancal, vu qu'un serveur SQL correct gérera sans sourciller plusieurs millions de rows, alors que le super file system d'Unix lui...
Enfin, j'avais envie d'étaler mon savoir scolaire

Par contre, tu as raison, la DB est très intéressante dés que :
tu as au moins deux personnes qui accèdent potentiellement à une donnée en même temps en lecture + écriture
tu as besoin de pouvoir revenir en arrière
tu as besoin de pleins d'info qui se recoupent (parce que faire des joins à la main... )
etc...

Mais encore une fois, ce n'est surement pas la solution la plus rapide dans tous les cas.

il y a qq chose que vous oubliez et qui favorise grandement la DB : c'est la mise en cache.
Si le serveur est bien dimensionné (beaucoup de RAM) et la DB pas trop grosse, elle peut tenir en mémoire exclusivement et donc il n'y a plus d'accès disk.

On vois donc que la fréquence d'appel de tes éléments (et la fréquence de leur mise à jour également) est cruciale.

Néanmoins, il est clair que dans le cas de données "statiques" peu nombreuses, il vaut 1000 fois mieux passer par des fichiers que se charger d'une requete SQL.

Euh ct moi deux réponses plus haut ^^
Bon bah apparement ca serait plutot des files...Je vais faire comme ca. Esperons que ca passe bien. Sinon je voulais savoir, entre un server sous unix et un server sous nt, est-ce que du coup il pourrait y avoir des écarts de performances étant donné qu'il n'utilisent pas le meme système de gestion des fichiers...

Et d'aillurs, oui je me disais, vous dites qu'avant de mettre "une base Mysql sur les genoux" il faut y aller mais ... le but c'est d'optimiser, parce que la moindre performance gagné c'est un petit peu moins d'attente pour le visiteur et donc une visite beaucoup plus agréable...enfin bon juste une petite note ^^

et plutot que de faire des fichiers...

pourquoi ne pas faire un truc du genre

ca ca se charge tout seul...

C'était bien l'idée oui Il parlait de faire des includes, je suppose que c'est ce qu'il voulait dire

bah moi je vois pas trop l'interet des array...vu qu'il faudra charger le array en entier, nan moi je pensai faire un fichier par objet et apres include 'nom_obj.php';
Mais c vrai que c'est risqué o nivo sécurité, enfin je m'assurerai qu'il n'y aura pas de probleme avec un tableau contenant le nom des fichiers qui existent...

Personnellement, j'utilise un système MySQL unique en son genre (je crois)

J'ai une table de donnée des items de base (100 items environ)
Et une table de donnnée des items attribuées aux joueurs, avec des modificateurs pour toute les valeur.

De cette facon, je peux toujours reballancer, corriger une erreur de francais dans une description de TOUTES les armes du jeu sans problème, et je peux aussi personnaliser chaque items attribué au joueur.

Ce système est assé complexe à géré car il faut toujours doublement tout vérifier, donc ca double les requêtes SQL, sauf si on optimise à fond (étape en cours dans mon cas), et la, ca fait des requêtes compliquées.

Mais coté gestion, c'est parfait!


Ps.: Concernant la peur de faire tomber un serveur MySQL, (voir mon post sur grand nombre de requete=je suis mauvais?) avant d'optimiser, j'avais parfois plus de 350 requetes pour la page principale et j'ai eu 50 joueurs en lignes en même temps.
Et le site était toujours très rapide et je n'ai eu aucun problème.

Je vous rassure, j'ai optimisé maintenant ;p Mais c'est pour vous dire que même avec près de 10000 requêtes par minute, ya pas eu de problèmes dans mon cas.

La solution la plus fléxible est puissante à mon sens est un mix de SQL+fichier...

function cachedQuery($sql)
{
// j'utilise Cache_Lite de PEAR
$cache = new Cache();

// la requete exemple
$sql = "SELECT * FROM `bzctoons-table`";

//si c'est pas en cache
if(!$records = $cache->get($sql))
{
// on execute la requete
$result = mysql_query($sql);
// on boucle sur les enregistrements renvoyés
$records = getRecords($sql, $result);
// on sauve sur le disque
$cache->save($records);
}
// et hop !
return $records;
}

Bon notez que le code est approximatif (i manque des fonctions...) mais le principe fonctionne trés bien je m'ent sert dans plusieurs sites.
La classe Cache_Lite gere le cache mémoire et le cache disque
D'ailleurs pour ma part j'ai codé une API sql avec un paramétre '$cached=false' par default afin que tourtes mes requetes passent dedans. C'est pas judicieux d'appliquer le cache pour toutes les requêtes mais la plupart des SELECT peuvent y passer.

Pour reagir à certains posts plus bas le systémes de fichiers est toujours plus rapide que MySQL puisque en cas de systéme avec bcp de RAM le cache fichiers est le premier utilisé car implémenté au niveau de l'OS.

Intéressant, mais est-ce que c'est vraiment économique de transféré une requête dans un fichier ? (c'est le double du temps donc.. )

Et ca ne viendrais pas compliquer de beaucoup la programmation générale ?

Dans quelles situations utilise tu cette optimisation exactement ?

C'est tres economique dans le cas de grosses requetes parce que le fichier se chargera plus vite.
En plus, il y a un parametres qui defini l'expiration du fichier. Par exemple, imaginons 1 heure pour le liste des accessoires, ce qui veut dire que cette requete ne sera executé que une fois par heure tout en fournissant toujours les bonnes infos.

Si ton code est ~bien fait tu n'as pas appelé directement les fonctions mysql_*, donc sur ta fonctions de requetes tu rajoutes un param facultatif indiquant si il faut utiliser le cache ou pas. Pas default il est à false donc rien n'a changé dans ton code. Pour les requetes que tu veux optimiser tu le mets à true.

J'utilise cette technique dans 80% de mes SELECT et j'y gagne toujours qq millisecondes voire des secondes. Plus ya de jointures plus j'y gagne, plus ya de records plus j'y gagne.
2 bemols toutefois :
- imaginons que tu viennes de mettre à jour des objets dans la partie admin de ton site, les modifs, ne seront effectives que dans une heure (le temps d'expiration du cache), il faut donc supprimer le fichier cache concerné au moment ou tu fait un INSERT ou UPDATE (quoique dans certains pas mal de cas une heure de latence c'est pas la mort et ça se régle). Dailleurs en mettant une expiration tres basse à 10 secondes par exemple, ça evite juste que tout le monde fasse la même requete en même temps.
- faut souvent gonfler la limite de memoire alloué par PHP par default à 8Mo c juste, 32 c'est mieux

Mwé, mwé, mwé.

Alors le débat fichier/bdd ça dépend. Comme dit précédemment, dès qu'on veut des données non statiques, il faut faire ça en bdd, c'est clair.

Mais si on veut également avoir des données cohérentes, plus facilement manipulables sans risque de doublons, d'erreur de lien ou je ne sais quoi, donc en gros, dès qu'on commence à gérer pas mal de choses, il vaut mieux utiliser un sgbd, c'est plus sûr et c'est fait pour.

En ce qui concerne les grosses requêtes, pour ceux qui ont la joie de jouer avec autre chose que mysql il y a les vues, c'est fait pour, c'est super pratique et c'est bien quoi. (rha, vivement qu'on change, nous )

Sinon effectivement le système de cache peut s'avérer utile, à partir du moment où le résultat de la requête est relativement statique ! Parce que si c'est pour actualiser le cache toutes les 2 minutes, c'est plus de la perte de performance qu'autre chose !

Dernière chose, c'est tout bête mais on sait jamais, faut bien vérifier qu'on n'accède qu'une seule fois aux données par page. (en cas de fichier, il ne doit être inclu qu'une seule fois, et pour les requête, tu ne dois avoir qu'un seul select sur ces données) Sinon c'est de la perte de perf pure.

Puis enfin, quand je vois des truc comme "il faut gonfler la mémoire allouable à php", ça me fait peur. Question : t'as combien de joueurs simultannés sur quel serveur ? Parce que si t'as besoin de tripler la mémoire allouable, c'est que ça doit consommer un max, c'est pas bon signe...

Je connais deja la reponse ;-) A une epoque on avait mis en place le systeme de cache dont il est fait mention plus bas (PEAR cache) et on a compare le cache fichier et le cache BDD.
Les performances du cache fichier baissent dramatiquement des que l'on a plusieurs centaines de fichiers en cache, alors que celui en MySQL se maintient a peu pres. Et pour 2500 fichiers, MySQL est bien plus rapide (de l'ordre de 2 fois plus rapide).
(Enfin en ce qui concerne PEAR cache, on peut bien entendu ameliorer ses perfs avec un ache fichiers hierarchise ;-) )

Oui, c'est certain... mais je doute que tu perdes beaucoup en perfs en passant par MySQL.

Enfin au final dans ton cas, MySQL ne s'impose pas, c'est juste plus propre ou plus facile a modifier... et puis si tu comptes rajouter des objets plus tard...

Oui de toute facon si je vois que y'a trop de fichiers je passerais en bdd, pour l'instant je pense que je vais me contenter des fichiers. De plus, tout ce qui est cache et tout ca c'est possible si on possède un server perso...ce que les jeux émergeants ne peuvent se permettre... un jour peut etre... Bon allé merci encore pour tout

C'est même une néccesité de passer par une BDD pour ce type d'utilisation !!!
C'est très utile pour faire des modifs facilement et pour avoir accès aux données sur d'autres pages, et c'est également uné économiede bande passante.

Non non, quand je parle de cache, je parle de cache MySQL.
Si l'on exclu la table des évenements et celle des messages internes, la DB de mountyhall tient sur 1Gb et des poussière. Comme notre serveur dispose de 2 Gb de RAM, TOUTES les tables d'équipement, joueurs, emplacements, etc. sont en RAM.
Accès disk en lecture = 0, le disk n'est accéder qu'en écriture pour "dumper" la ram lorsque les tables sont modifiées.

Bon, c'est vrai que le serveur est prévu pour ca mais c'est quand même le cas aussi chez les hébergeur mutualisés qui foncitonnent en cluster : OVh par exemple a des serveur mysql de 4 et 8 Gb de RAM qui est à 90% utilisable par les DB.

Quand vous choisissez le stockage par fichier plutot que par bdd, faites attention à un piège vraiment pas évident à première vue : mieux vaut lire le fichier et traduire le contenu (typiquement serialize/unserialize) plutot que de stocker le code directement et faire un include. Et ce même si le poids du fichier est plus faible en version "code" qu'en version "serialize".

Les détails ici : http://www.phpfrance.com/forums/voir_sujet-4628.php

(on ne compare pas MySQL/fichiers mais bien différentes méthodes de stockages par fichier entre elles, il y a aussi une petite comparaison rapide SQLite/"PCRE sur fichier" en fin de post)

J'ai répondu sur le forum.

Pour résumer, oui le serialize/unserialize est plus rapide que du code source, car il est optimisé pour l'interprétation et n'a pas besoin d'être lisible contrairement à du code source.

Mais, si on utilise un système de cache comme zend cache (cher) ou eaccelerator (gratuit mais un peu buggué, http://eaccelerator.net/HomeFr?lg=fr), la méthode include est nettement plus performante car le fichier n'est interprété qu'une seule fois (et c'est ça le plus long).

ahah tu a gamersloot dans tes signatures?
cest un site spécialisé pour les clé cd plutot !
pour ceux qui veulent des news http://www.facebook.com/pages/Gamerslootnet/148760525160091 cest ici sinon pour le reste cest sur leur site !