TourDeJeu, le réseau des jeux en ligne alternatifs : jeux web multijoueurs, jeux par forum. En savoir +

Flux RSS des discussions du forum : pour les joueurs, et pour les créateurs et MJ
  Reply to this topicStart new topicStart Poll

> Gestion Des Objets/accessoires, Comment gérer un grand nombre d'obj ?
Ver2terre
  Ecrit le : Vendredi 17 Juin 2005 à 12h00
Quote Post


Kid
*

Groupe : Membre
Messages : 11


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
PMEmail Poster
Top
Cedric
Ecrit le : Vendredi 17 Juin 2005 à 14h16
Quote Post


Ouf
*

Groupe : Membre
Messages : 368


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

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

QUOTE
Sachant que je ne pense pas que l'utilisation de Sql puisse etre un atout ici...

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


--------------------
user posted image
PMEmail PosterUsers Website
Top
Guest
Ecrit le : Vendredi 17 Juin 2005 à 14h34
Quote Post


Unregistered






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.
Top
Arckam
Ecrit le : Vendredi 17 Juin 2005 à 14h40
Quote Post


Pro
*

Groupe : Membre
Messages : 137


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

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.
PMEmail Poster
Top
Cedric
Ecrit le : Vendredi 17 Juin 2005 à 14h54
Quote Post


Ouf
*

Groupe : Membre
Messages : 368


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

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

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

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


--------------------
user posted image
PMEmail PosterUsers Website
Top
Guest
Ecrit le : Vendredi 17 Juin 2005 à 16h08
Quote Post


Unregistered






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...
Top
Arckam
Ecrit le : Vendredi 17 Juin 2005 à 16h46
Quote Post


Pro
*

Groupe : Membre
Messages : 137


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... smile.gif
Enfin, j'avais envie d'étaler mon savoir scolaire tongue.gif

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... smile.gif )
etc...

Mais encore une fois, ce n'est surement pas la solution la plus rapide dans tous les cas.
PMEmail Poster
Top
[VYS]
Ecrit le : Vendredi 17 Juin 2005 à 17h00
Quote Post


Ouf
*

Groupe : Membre
Messages : 317


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.


--------------------
VYS - DungeonMaster
* président asbl JeuxWeb.org
* webmaster MountyHall - La Terre des Trõlls
user posted image
PMEmail PosterUsers Website
Top
Ver2terre
Ecrit le : Vendredi 17 Juin 2005 à 17h20
Quote Post


Kid
*

Groupe : Membre
Messages : 11


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...
PMEmail Poster
Top
Ver2terre
Ecrit le : Vendredi 17 Juin 2005 à 17h24
Quote Post


Kid
*

Groupe : Membre
Messages : 11


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 ^^
PMEmail Poster
Top
bibi.skuk
Ecrit le : Vendredi 17 Juin 2005 à 18h02
Quote Post


Pro
*

Groupe : Membre
Messages : 64


et plutot que de faire des fichiers...

pourquoi ne pas faire un truc du genre

CODE

<?php
$NOM_DE_MA_TABLE = array(
1 => array( les données que je veux );
2 => array( les données que je veux );
);
?>


ca ca se charge tout seul...
PM
Top
Arckam
Ecrit le : Vendredi 17 Juin 2005 à 18h07
Quote Post


Pro
*

Groupe : Membre
Messages : 137


C'était bien l'idée oui smile.gif Il parlait de faire des includes, je suppose que c'est ce qu'il voulait dire smile.gif
PMEmail Poster
Top
Ver2terre
Ecrit le : Vendredi 17 Juin 2005 à 18h32
Quote Post


Kid
*

Groupe : Membre
Messages : 11


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...
PMEmail Poster
Top
Sybler
Ecrit le : Samedi 18 Juin 2005 à 07h13
Quote Post


Ouf
*

Groupe : Membre
Messages : 453


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.


--------------------
user posted image
PMEmail PosterUsers Website
Top
bzctoons
Ecrit le : Samedi 18 Juin 2005 à 07h37
Quote Post


Newbie
*

Groupe : Membre
Messages : 5


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.



--------------------
Conception & réalisation sites internet
bzctoons network

http://www.antreducobra.com
Elevage virtuel de Cobra

http://bzctoons.free.fr/flvs/
Streaming vidéo

http://www.gamersloot.net
Echanges et achats pour MMORPG (WoW, etc )
PMEmail PosterUsers Website
Top
Sybler
Ecrit le : Samedi 18 Juin 2005 à 07h56
Quote Post


Ouf
*

Groupe : Membre
Messages : 453


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 ?


--------------------
user posted image
PMEmail PosterUsers Website
Top
bzctoons
Ecrit le : Samedi 18 Juin 2005 à 08h12
Quote Post


Newbie
*

Groupe : Membre
Messages : 5


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


--------------------
Conception & réalisation sites internet
bzctoons network

http://www.antreducobra.com
Elevage virtuel de Cobra

http://bzctoons.free.fr/flvs/
Streaming vidéo

http://www.gamersloot.net
Echanges et achats pour MMORPG (WoW, etc )
PMEmail PosterUsers Website
Top
Nonothehobbit
Ecrit le : Samedi 18 Juin 2005 à 10h55
Quote Post


Alien
*

Groupe : Moderateurs
Messages : 1298


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. smile.gif (rha, vivement qu'on change, nous sweatdrop.gif)

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

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


--------------------
user posted image
PMEmail PosterUsers Website
Top
Cedric
Ecrit le : Samedi 18 Juin 2005 à 11h09
Quote Post


Ouf
*

Groupe : Membre
Messages : 368


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

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

QUOTE
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 ^^

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


--------------------
user posted image
PMEmail PosterUsers Website
Top
Ver2terre
Ecrit le : Samedi 18 Juin 2005 à 12h27
Quote Post


Kid
*

Groupe : Membre
Messages : 11


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... wink.gif un jour peut etre... Bon allé merci encore pour tout
PMEmail Poster
Top
Kévin
Ecrit le : Samedi 18 Juin 2005 à 14h03
Quote Post


Pro
*

Groupe : Membre
Messages : 56


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.


--------------------
Webmaster, programmeur PHP mysql. Mon jeu en fin de réalisation :).
PMEmail Poster
Top
[VYS]
Ecrit le : Samedi 18 Juin 2005 à 14h26
Quote Post


Ouf
*

Groupe : Membre
Messages : 317


QUOTE (Nonothehobbit @ 18 Jun 2005, 09:55 )
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. smile.gif

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

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.


--------------------
VYS - DungeonMaster
* président asbl JeuxWeb.org
* webmaster MountyHall - La Terre des Trõlls
user posted image
PMEmail PosterUsers Website
Top
naholyr
Ecrit le : Lundi 20 Juin 2005 à 06h28
Quote Post


Ouf
*

Groupe : Membre
Messages : 423


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)
PMEmail PosterUsers WebsiteICQYahoo
Top
Nonothehobbit
Ecrit le : Lundi 20 Juin 2005 à 12h45
Quote Post


Alien
*

Groupe : Moderateurs
Messages : 1298


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


--------------------
user posted image
PMEmail PosterUsers Website
Top
lukifier
Ecrit le : Jeudi 23 Décembre 2010 à 13h51
Quote Post


Newbie
*

Groupe : Membre
Messages : 2


QUOTE (bzctoons @ Samedi 18 Juin 2005 à 08h12)
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

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 !
PMEmail Poster
Top
« Sujets + anciens | Programmer | Sujets + récents »

Reply to this topicStart new topicStart Poll