Forum TourDeJeu [Powered by Invision Power Board]

Version imprimable du sujet
Cliquez ici pour voir ce sujet dans son format original

Forum TourDeJeu > Programmer > Temps De Création / Chargement Des Pages

Ecrit par: nygma Vendredi 24 Novembre 2006 à 00h35

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

Ecrit par: gorgu Vendredi 24 Novembre 2006 à 19h16

de 0,9s à 3 secondes.

Ecrit par: nygma Vendredi 24 Novembre 2006 à 20h20

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

Ecrit par: xaero Vendredi 24 Novembre 2006 à 21h12

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

Ecrit par: Ludvig Vendredi 24 Novembre 2006 à 21h22

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

Ecrit par: Haiken Vendredi 24 Novembre 2006 à 21h25

QUOTE

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

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

Ecrit par: nygma Vendredi 24 Novembre 2006 à 22h41

QUOTE

C'est juste pour afficher une page ?

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

QUOTE

mon dieu, svp, oubliez tous ça..

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

Ecrit par: Haiken Vendredi 24 Novembre 2006 à 23h02

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)

Ecrit par: xaero Samedi 25 Novembre 2006 à 00h11

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.

Ecrit par: Jim Samedi 25 Novembre 2006 à 00h48

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

Ecrit par: Sybler Samedi 25 Novembre 2006 à 02h33

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

Ecrit par: nygma Samedi 25 Novembre 2006 à 11h41

QUOTE

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.

Ecrit par: Sybler Samedi 25 Novembre 2006 à 17h56

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

Ecrit par: gorgu Samedi 25 Novembre 2006 à 19h16

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

Ecrit par: nygma Samedi 25 Novembre 2006 à 20h55

QUOTE

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

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.

Ecrit par: Ludvig Dimanche 26 Novembre 2006 à 03h25

QUOTE

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

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

Ecrit par: Sybler Dimanche 26 Novembre 2006 à 04h19

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:

QUOTE

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

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 ?

Ecrit par: gorgu Lundi 27 Novembre 2006 à 19h54

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.

Ecrit par: Guest Lundi 27 Novembre 2006 à 22h36

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

Ecrit par: [VYS] Mardi 28 Novembre 2006 à 12h26

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

Ecrit par: Galdor Mardi 28 Novembre 2006 à 17h16

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

Ecrit par: Haiken Mardi 28 Novembre 2006 à 20h47

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)

Ecrit par: Galdor Mercredi 29 Novembre 2006 à 13h58

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.

Ecrit par: Haiken Mercredi 29 Novembre 2006 à 15h27

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

Ecrit par: Sybler Jeudi 30 Novembre 2006 à 07h07

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)

Ecrit par: [VYS] Jeudi 30 Novembre 2006 à 15h43

1,3 Go. En pratique, la table est décomposée en deux qui comprennent chacune 3 millions de records (une table avec les infos et une table pour l'indexation).

Perso, ca ne m'impressionne plus, on a une dizaine de tables qui dépassent le million de record (3,8 million et 240 Mo pour l'historique des equipements)

Ce ne sont que des entrées dans une DB, le défi est surtout d'y accéder rapidement.

Donc, mon expérience de l'innoDb est purement empirique mais basée sur des tables de taille assez peu ordinaire.
Ceci dit, ces tests ont été faits avec Jocelyn Fournier qui est l'un des plus gros spécialiste de MySQL en France (http://www.mysql.com/doc/en/Contributors.html
). C'est lui qui nous a suggérer d'essayer innoDB avant de suggérer le retour à MyIsam au vu de la dégradation des performances.

Ecrit par: Sybler Jeudi 30 Novembre 2006 à 19h05

... ca doit être la joie pour les backups / restauration ...

Ecrit par: [VYS] Vendredi 01 Décembre 2006 à 10h03

25 minutes de coupures toutes les nuits à partir de 4h00 pour optimisation et backup des tables.
3 mois de backup en permanence sur le serveur (compressé évidemment).
Vu la puissance du serveur DB, la restauration n'est pas si longue que ca (une petite heure, la seule fois où ca nous est arrivé avec cette machine).

Ecrit par: gorgu Mardi 05 Décembre 2006 à 19h27

QUOTE (Guest @ 27 Nov 2006, 21:36 )

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

j'ai changé de serveur. tout va beaucoup mieux

0,3 s pour la plus grosse page

0,02 pour une page classique.

Ecrit par: Sybler Mardi 05 Décembre 2006 à 21h00

D'un serveur à l'autre on parle de quel changement (Mhz + RAM) ?

Ecrit par: Seren Lundi 22 Janvier 2007 à 13h59

Une petite question de neophyte.

Je comprends comment évaluer le temps de chargement d'une page. (time (footer) - time(header)).

Par contre comment vous calculez le nombre de requêtes par page ? Vous mettez tout dans une global et à chaque requête effectué: $nb_requete ++ ?

Si il y a une autre solution plus intelligente, ça me servirait bien pour faire du profiling.