Temps De Création / Chargement Des Pages, sur jeu en PHP avec interface

Hello,

par curiosité, en combien de temps générez-vous vos pages ?

décomposé si possible de la manière suivante :

1 - chargement des données de la BDD
2 - Traitement
3 - Génération du Html

Merci

Nygma

de 0,9s à 3 secondes.

ah ben ça me rassure alors.

ça met de 0.5 à 1.5 sur ma bécane perso (config relativement costaud), donc probablement le double sur le serveur mutualisé.

Et les autres ? ça donne quoi ?

Perso, le truc qui me tue, c'est les 0.1 sec perdue par requête d'update.

un pauvre "update persomonstre_main set PV = 5 where numero = 10" prend 0.1 sec. et y'a ce qu'il faut en index. (je suis en INNOdB)
avec une boule de feu sur une zone assez peuplée, ça ralentit pas mal....

C'est pas surprenant si tu es en Innodb , myisam est la solution si tu veux que tes update soient plus rapide.

C'est juste pour afficher une page ?
Il n'y a pas d'autres joueurs connectés ?

Sans autres joueurs connectés ça tourne entre 0.1 et 0.3 dependant de la page et c'est sur un pentium 733mhz ^^


/Ludvig

mon dieu, svp, oubliez tous ça...

c'est à peine valable avec un utilisateur connecté, alors avec quelques dizaines y'a pas photo... en particulier à cause du verrouillage de la table entière

un refresh de l'écran de jeu prend 0.45 sec.

ça veut dire quoi, cette remarque ?
je dois oublier InnoDB ?

c'est un pote informaticien qui m'avait conseillé InnoDB, car base de donnée toujours intègre. et c'est vrai que c'est confortable, avec un seule 'delete from' d'avoir les items liés dans 15 autres tables qui dégagent tous seuls.....

En lecture, ça bourinne bien, vu la masse de requête SQL que je fais.

c'est de dire que les update sont plus rapide en myisam qu'en innodb qui est complètement faux, rassure toi, innodb est très bien, et indispensable dès que l'on veut un minimum de sérieux dans ses données (intégrité comme tu l'as dit). L'un des seuls cas où l'on pourrait préférer myisam c'est pour des gros select sur des table peu dynamiques (donc à priori pas un jeu online) ou alors pour utiliser les FULLTEXT (donc à priori pas un jeu online non plus)

Pour en revenir au sujet, au dessus de 0,5s en local, qui est une grosse valeur, il y un problème (ou alors c'est une grosse page et/ou compliquée à calculer)

je disais juste que si on compare un update simple en innodb et en myisam , cet update sera plus rapide en myisam ( 0,004 seconde contre 0,10 seconde en innodb ) , il s'agit juste de comparer deux valeurs ...

je vois pas pourquoi il faudrait utiliser automatiquement innodb sur toutes les tables et pour toutes les applications imaginable , je trouve que myisam a encore sa raison d'etre notamment parce qu'il est moins consommateur en ram qu'innodb , on peut pas généraliser et dire il faut utiliser ça tout le temps , ça me parait etre un raccourci tres facile.

Ouais,

Le blème c'est que si t'utilise myisam des que tu touches deux tables qui doivent rester syncro d'une manière ou d'une autre, c'est embêtant ou alors faut tout journaliser, ce qui est aussi embêtant

Franchement, même sur une résolution de stellarium qui balance quand même une tonne de requêtes dans des boucles avec environ 30 % pour les insert/update/delete et 70% pour des select tous ça dans la même transaction. Ca prend pas plus de 30 secondes et encore la page de débug à afficher et d'environ 500ko. Avant chez ovh j'avais une config plus costaud ct 10 secondes.

Si j'avais pas eu moyen d'utiliser les transactions je pense que le jeu aurait été beaucoup plus long à faire. Il aurait fallu tout historiser et ça c'est du boulot en plus, du code en plus, des bugs en plus.

Bon c'est sur qu'avec des multiples connections et des updates concurrents ça peux dégrader les performances, mais InnoDb est bien plus rapide (à config comparable) que la plupart des concurrents.

Mais l'argument que je pense primordiale, que je préfère 100 fois que ma page soit plus lente à afficher. Mais je veux être sûr de pas avoir à aller triturer la base à la main par ce que la page a buggé ou à remonter un backup et a expliquer à mes joueurs qu'on a perdu des données...

Enfin bref c'est juste mon avis après tout

Actuellement --sur mon nouveau dévellopement de moteur de jeu-- la page de jeu principale (celle qui affiche l'historique des message, les statistiques du perso ainsi que le menu d'action en fonction des items en inventaire) donne, pour 3 perso différents:

Nombres de requêtes: 16 (0.026sec), Génération de la page: 0.0712sec
Nombres de requêtes: 16 (0.0407sec), Génération de la page: 0.0993sec
Nombres de requêtes: 16 (0.055sec), Génération de la page: 0.1125sec

Le temps SQL est compris dans le temps de génération de la page. Et la génération de la page est calculée sans triche (c'est à dire avant les requires et tout)

Et je suis actuellement en MyISAM partout, mais il est pas impossible que quelques tables se voient passer en InnoDB éventuellement (Surtout la table des messages des historiques des évènements qui fait 400mo actuellement).



Edit:
Quelqu'un peut me donner un exemple concret d'une situation qui OBLIGE (ou presque) à utiliser InnoDB plutot que MyISAM. ?

eh bien, par exemple :

j'ai des types d'objet. si un objet est créé sur un type d'objet, puis posé sur le sol d'un donjon, le simple fait de faire un delete du type d'objet, va faire que tous les objets créés avec ce type là vont être détruits, (ça évite donc des bugs avec des objets 'incohérents' puisque sans type), ça enlève lesdits objets de là où ils sont, destruction du record dans la table de croisement entre les objets et le sol du donjon, destruction des records dans la table de croisement entre les parties des corps des persos et les objets, etc...

ça assure une cohérence globale obligatoire avec un seul delete. quand tu as bcp de tables croisées, sans INNODB, ça devient vite source de bug.
De plus, au moindre bug de ton code PHP au beau milieu d'un séance de delete 'manuels' en myIsam, ta base devient incohérente.

le cas concret, c'est ça : bcp de tables interconnectées.

autre exemple, si l'objet en question est un cadavre :
Si c'est un PJ, il est possible de le ramener à la vie. (lien entre objet et table perso). mais si c'est un PNJ, à sa mort, je fais un delete du perso. il faut donc impérativement que l'objet se voit dissocié du perso qui n'existe plus.

autre exemple : détruire un donjon, çadétruit les cartes du donjon, qui détruit les cases des cartes, qui détruit les pièges sur les cartes, qui détruit les téléports sur les cartes etc....

Toutes référence à une carte qui n'existe plus est automaiquement supprimée.

Les persos qui étaient sur ladite carte ne seront en revanche pas détruit. les attributs X,Y et numcarte seront alors passés à NULL. (par choix)

je sais pas si je réponds à ta question, mais je sais que ce serait la galère sur la version 4 de mon jeu si je n'avais pas InnoDB.

Donc le problème, c'est que si tu fait:

DELETE FROM inventaire_items WHERE type='epe3';
DELETE FROM lieu_items WHERE type='epe3';


Le risque est qu'entre les deux, une personne déplace un item d'un lieu à son inventaire
C'est bien ca ?


Je comprend bien tes exemples, mais je vois pas trop en quoi MyISAM pourrait corrompre les données...

bon j'ai divisé ces mesures par 2 en rebidouillant la config d'apache.

ces mesures sont pour environ 60 personnes connectée et 120 visiteurs.

les 3secondes sont sur les actualisations de map (fichier xml pour flash)

les 0.9 sont pour le forum et autres pages d'accueil.

j'ai beaucoup plus de mal à configurer apache que mysql .
En effet mysql ralentis un peu de temps en temps que les grosses requetes (table carte de 250 Mo)

par contre apache à la facheuse tendance de vouloir planter complétement...

ce n'est pas ce que je voulais dire. ça ne lutte pas contre des actions qui surviennent entre 2 delete.

en fait, avec un code parfait qui buggue jamais et que tu ne modifies plus, mysiam est sans doute aussi bien que Innodb.

disons qu'innodb te simplifie la vie sur l'exhaustivite de tes delete en cascade d'un MEME item.

Hmm, dit moi si j'ai rien compris là... qui ferait des copies d'un objet
parce qu'il est à la fois dans un sac et que le sac est dans un lieu ?


J'avoue que je ne comprends pas vraiment quel est la problème, sauf que
si on duplique des items, c'est sur qu'il y a des risques enormes...



/Ludvig

Heu non cet exemple la supprimerais 100% des objet de type "epe3" dans tout le jeu, soit tout les objets dropés au sol et tout ceux en inventaire.

Pour InnoDB je viend de comprendre l'intérêt je crois.. en gros c'est une sécurité (et ca permet de faire des transactions)

Avez-vous besoin d'optimiser vos tables comme avec MyISAM de temps à autres ?


gorgu:

Je suis pas certain de suivre: quelles mesures à tu divisé par deux ?

3 seconde pour afficher une mappe ca me semble beaucoup non ?
>> Générer (qui impliquerais un cache) ou vraiment juste afficher ?

3 secondes pour créer juste le fichier xml avec PHP.

oui c'est trés (trop) long.

maintenant j'ai 1,8 secondes.

Je vais tenter de sortir du systéme mysql pour le fond de carte, même si c'est pas évident.

Woa c'est fou, qu'est-ce qui cause cette lenteur principalement ?

sur le forum 0.5 seconde par page
sur le site moins de 0.01 seconde par page
sur le jeu de 0.01 à 0.20 seconde par page, 11.000 requetes sql par minute
(nous avons un superplan OVH pour le site et les forums et deux opterons pour le jeu - mysql sur un et apache sur l'autre)

Pour la discussion myisam - innodb : nous avons testé à deux reprises il y a un an et un an et demie un passage de notre plus grosse table (insert et select ultra fréquents, 3,1 millions de records) en innodb et celà a plombé les performances (toutes autres choses restant égales évidemment).
Depuis, myisam est réellement le choix que je fais pour des tables fortement dynamique (mais c'est empirique, je l'avoue). Donc sybler, je peux te suggérer de rester en MyIsam pour ta table d'événement.
Je trouve un intéret à l'innodb pour effectivement garantir des transactions (en cas d'update et delete fréquent et concurrents) et pour des tables où le table locking peut poser des problèmes (opérations longues) mais jusqu'à présent, j'ai favorisé la rapidité à la cohérence

Petites notes sur les tables MyIsam :
- optimize toutes les nuits obligatoire sur les tables fortement modifiées
- ne pas hésiter à faire des INSERT DELAYED sur les tables d'historique

Je dis peut-etre une betise, mais les transactions ne fournissent-elles pas un moyen efficace d'eviter les gros locks ?

(Desole pour la brievete et l'absence d'accents, mais je suis en plein apprentissage du layout clavier dvorak (et au passage, ca enfonce l'azerty))

non, les transactions servent à maintenir la cohérence (applicative) de tes données.
MyIsam, qui ne supporte pas les transactions, verrouille une table entière en cas de modification. Innodb ne verrouille que les lignes concernées ; c'est mieux, mais pas indispensable pour faire des transactions.

(il existe un layout dvorak pour le francais, avec les accents)

Bah oui, ca sert a maintenir la coherence... comme les locks, le principe etant en gros "personne ne touche a ma table tant que je n'ai pas finis mes operations".

Le layout dvorak-fr n'est pas standardise et tres mal foutu pour les programmeurs.

ben, pour être précis, les transactions utilisent les verrous, et donc par définition ne permettent pas de les éviter

woa 3.1 millions c'est intense, ca pèse lourd ?
Moi j'ai 260 000 évènements et la table fait 520 000Ko :-\ (Donc à 3.1 million, ca doit être fou)