IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

Le bon SGBD pour un jeu vidéo en ligne sur navigateur à fort trafic


Sujet :

Décisions SGBD

  1. #1
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut Le bon SGBD pour un jeu vidéo en ligne sur navigateur à fort trafic
    Bonjour,

    Je suis en train de développer un jeu vidéo sur navigateur. Le projet avance bien et je me pose des questions techniques par rapport à la résistance à la charge des serveurs.

    Par rapport au serveur hébergeant le jeu les problèmes de surcharge peuvent être évités en ayant plusieurs serveurs et en redirigeant les joueur vers des serveurs moins chargés.

    Par contre pour la BDD je me demande comment faire. En effet les données sont les mêmes pour tous les joueurs et donc je risque d'avoir environ 300 000 requêtes à la seconde (je suppose que MySQL ne tient plus le coup à ce rythme ?).

    Je me pose alors plusieurs questions :
    - Quel SGBD est-ce qu'il faudrait que j'utilise pour résister à autant de requêtes et aussi pour stocker plusieurs milliards de données (il faudrait donc aussi que les index supportent des très grandes valeurs)
    - Est-ce qu'il faudrait que je partage le jeu en plusieurs BDD sur plusieurs serveurs ? Et que les joueurs choisissent un serveur et ne le quittent plus ?

    J'avoue ne pas encore très bien savoir comment gérer tout ça et j'aimerais avoir vos conseils. De plus je ne connais pas les limites des SGBD.

    Bien sûr quand je parle de 300 000 requêtes à la seconde j'anticipe mais ça reste quelque chose de réaliste et qui correspond à notre prévisionnel sur ce projet, il me semble donc important que je prévois tout ça dès la conception plutôt qu'une fois le problème de surcharge rencontré. Lorsque je parlais avec des développeurs de jeux vidéo ayant bien marchés ils me disaient que le goulot d'étranglement est la BDD.

    Je vous remercie par avance de votre aide et de vos conseils !
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  2. #2
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    300k requêtes à la seconde? Donc disons 300k joueurs faisant une action en même temps sur la même instance du jeu?

    C'est irréaliste.

    Le reste des réponses est sur :
    http://fr.slideshare.net/wooga/10000...he-splash-2011

    La BD est le goulot d'étranglement ça dépend, notemment de la compétence des gens. En tout cas, il y a toujours des solutions.

  3. #3
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    La présentation est très intéressante !

    Cependant je ne suis pas sûr d'avoir tout compris.

    Déjà au début si j'ai bien compris il y avait 2 BDD. Est-ce que ça veut dire que le jeu était divisé en instances et que les joueurs devaient en choisir une ? Ou bien est-ce que ça veut dire qu'il y avait un système avec MySQL qui permet de gérer une BDD sur plusieurs serveurs ?

    Apparemment MySQL tient donc pas mal le coup lorsqu'on a beaucoup de trafic ? PostGreSQL n'est pas meilleur à ce niveau là ?

    Est-ce qu'on a le temps en pratique de voir venir les problèmes et de les régler ou bien est-ce qu'il faut vraiment tout prévoir à l'avance ?

    D'après ce que j'ai compris, MySQL peut tenir le choc jusque 1000 opérations de mise à jour par seconde ?
    Si on dépasse ce nombre que se passe t'il concrètement ? Latence ? Crash du serveur ?

    Merci de vos réponses
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  4. #4
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Ca dépend de pas mal de paramètre ce qui arrive, dans un cas c'est ça. Tout se gère toujours avec un peu de temps et de l'argent quand les gens sont compétents.

    Faites votre produit et benchmakez pour trouver la limite de votre infrastructure.

    Mais d'abord faut faire le produit. Et c'est pas la choix de la DB qui va influer de beaucoup sur la qualité du produit. Prennez là où vous êtes à l'aise.

  5. #5
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    D'accord merci !

    Et par contre au niveau de l'architecture de la BDD du site, est-ce que ça vaut le coup de faire plusieurs instances du jeu et de la BDD ? Pour ainsi répartir la charge ? Ou bien est-ce que la BDD est censée tenir le coup avec une seule instance ?
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  6. #6
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Ca peut mais souvent c'est une décision de design et pas une limitation technique (ou à la rigueur une limitation de la compétence des devs)

  7. #7
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 778
    Points
    30 778
    Par défaut
    Si l'accès au SGBD est effectué au travers de requêtes optimisées et respectant toutes les règles du langage SQL, il ne sera pas difficile de changer de SGBD en cours de développement, voire d'exploitation.
    Cela demande bien sur d'être rigoureux et de ne pas céder à la facilité des à-peu-près que propose mySql.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  8. #8
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Fabien Henon Voir le message
    ...
    Par contre pour la BDD je me demande comment faire. En effet les données sont les mêmes pour tous les joueurs et donc je risque d'avoir environ 300 000 requêtes à la seconde (je suppose que MySQL ne tient plus le coup à ce rythme ?).
    Tout dépend de la volumétrie... Sachant que les SGBDR mettent toutes les données en mémoire, si vous avez affaire à de petites requêtes durant moins de 1 ms, alors cela ne fait que 300 s de CPU... Si le SGBR cjoisit sait les faire en parallèle, par exemple répartit sur 64 cœurs, cela ne fait plus que 4,68 s de CPU et si enfin il est capabale de faire du "rescan" c'est à dire réutiliser un scan de table en cours pour une autre requête, vous pouvez diviser encore ce chiffre par 8 ou 10.. On arrive alors à 0,58 s de CPU et vous êtes OK avec un seul serveur...
    Il faut aussi que votre SGBDR supporte le pooling de connexion.

    Bref, au panier MySQL et PostGreSQL ! visez au moins SQL Server...

    Et si cela ne suffit pas, il faudra paralléliser les serveurs, mais ça c'est une autre paire de manche !
    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  9. #9
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    Bonjour et merci pour vos réponses !

    Pour compléter un que ce que je dis, nous utilisons le langage Java pour le site et nous utilisons JPA et Hibernate (j'avoue ne pas bien savoir distinguer leur utilité) pour la gestion de la BDD.

    Pourquoi MySQL et PostGreSQL seraient à mettre au panier ? Ils ne supportent pas la parallélisation des requêtes ?

    SQL Server serait donc un meilleur choix ?

    Je suppose qu'il nous serait assez facile de commencer avec PostGreSQL et de migrer sur SQL Server dès que la charge devient trop importante, qu'en pensez-vous ?
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  10. #10
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Fabien Henon Voir le message
    Bonjour et merci pour vos réponses !

    Pour compléter un que ce que je dis, nous utilisons le langage Java pour le site et nous utilisons JPA et Hibernate (j'avoue ne pas bien savoir distinguer leur utilité) pour la gestion de la BDD.

    Pourquoi MySQL et PostGreSQL seraient à mettre au panier ? Ils ne supportent pas la parallélisation des requêtes ?

    SQL Server serait donc un meilleur choix ?

    Je suppose qu'il nous serait assez facile de commencer avec PostGreSQL et de migrer sur SQL Server dès que la charge devient trop importante, qu'en pensez-vous ?
    La vous partez dans les choux tout de suite. Java est un langage des plus lents. Si vous envisagez sérieusement 300 000 requêtes SQL à envoyer par seconde à un SGBDR en java, je vous conseille de prévoir un budget conséquent pour acheter 10 000 serveurs frontaux !!!
    Et en plus avec la pire merde qui soit Hibernate... c'est bien plus encore qu'il faudra.

    MySQL se vautre à partir d'une dizaine de user, là ou PostGreSQL arrive à sa limite de 100 en toute sérénité... Il faut rajouter pgPoll, mais ça gère pas beaucoup plus (quelques centaines de connexion en //)

    mais pour SQL Server, la limite est nativement de 32 000 !!!

    En sus ni MySQL ni PostGreSQL ne savent paralléliser les requêtes...

    Avant de vous lancer dans une telle aventure je vous conseille de lire http://sqlpro.developpez.com/cours/b...s-epaisses.pdf


    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  11. #11
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    Java peut être lent, mais qu'en est-il de l'ASP via le C# ou le VB, PHP, RubyOnRails qui sont tous aussi des langages interprétés ? Les différences de performances ne devraient pas être si grandes ?

    Hibernate est-il si mauvais que ça ? N'est-il pas utilisé par certains sites à fort trafic ?

    Par rapport au budget de départ que nous avons je pense qu'il faudrait que nous commencions avec un SGBDR gratuit comme PostGreSQL et que nous migrions ensuite sur SQL Server par exemple dès que la charge se fait sentir.

    A côté de ça je pense que l'on va designer notre jeu de façon à avoir plusieurs instances qui soient sur plusieurs serveurs, ainsi la charge sera réduite sur chacun des serveurs.

    Je lis les papiers de ce pas !
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  12. #12
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    En même temps je vous ai montré une présentation qui montre que Wooga sait gérer 100k db ops par seconde dont 50k update. Zynga donne aussi ses méthodes de stockage qui ont aussi débuté avec MySQL.

    Ni Java ni MySQL ne seront le problème dans les prochains temps. Le problème sera d'abord de faire un jeu qui attirera assez de joueur pour que la question se pose et ensuite la compétence des devs.

    Tant que vous n'êtes pas au stade de beta privée, vous pouvez même utiliser H2 si ça vous permet d'aller plus vite.

    Au travail

  13. #13
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Citation Envoyé par Fabien Henon Voir le message
    Java peut être lent, mais qu'en est-il de l'ASP via le C# ou le VB,
    C'est nettement plus performant... car optimisé pour Winows... Exemple site fnac.com, cdiscount, ooshop...
    PHP
    pas mal non plus
    , RubyOnRails qui sont tous aussi des langages interprétés ? Les différences de performances ne devraient pas être si grandes ?
    Plus de couche = plus lent. En sus on ne peut optimiser un même langage que sur une seule plateforme.... Seuls les grands éditeurs arrivent à optimiser plus finement...

    Hibernate est-il si mauvais que ça ? N'est-il pas utilisé par certains sites à fort trafic ?
    Absolument aucun. Certaines entreprise ont même fait faillite à cause de la lenteur d'Hibernate lors de la montée en charge...

    Par rapport au budget de départ que nous avons je pense qu'il faudrait que nous commencions avec un SGBDR gratuit comme PostGreSQL et que nous migrions ensuite sur SQL Server par exemple dès que la charge se fait sentir.
    Une fois ferré avec un SGBDR, vous aurez du mal à en sortir car le SQL est rarement compatible d'un SGBDR l'autre.

    A côté de ça je pense que l'on va designer notre jeu de façon à avoir plusieurs instances qui soient sur plusieurs serveurs, ainsi la charge sera réduite sur chacun des serveurs.
    C'est possible pour les serveur WEB et quasiment impossible pour les SGBDR. En effet il faudrait que TOUS possèdent la même information au même moment ce qui suppose de distribuer les transactions sur les n serveurs. Donc, mis à part Oracle en architecture RAC (et il faut concevoir l'appli et le modele de donées qui va avec) ou SQL Server avec une mode de réplication transactionnel, votre systèmes est infaisable.

    Je lis les papiers de ce pas !
    Pourquoi ne pas commencer par la version gratuite de MS SQL Server (Express). Certe les bases sont limtées à 10 Go, mais vous pouvez en concevoir 32 000 sur la même instance et allez jusqu'à 10 instances par serveur.
    Ensuite passez à l verison Web dont le prix de licence est modique et sensuite en fonction de la mntée en charge, allers vers la standard ou l'enterprise...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  14. #14
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    Merci de vos réponses, je tiens compte de vos remarques à tous.

    Juste par rapport à faire plusieurs instances de BDD en fait je ne cherche pas à paralléliser les BDD, mais plutôt à designer le jeu pour diviser les joueurs sur des BDD différentes mais avec des données différentes (les français d'un côté, les anglais de l'autre par exemple, ...)
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  15. #15
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    Par contre je me demandais si quand on utilise Hibernate en précisant directement les requêtes compliquées pour optimiser le tout, les performances étaient toujours aussi mauvaises ?

    Par exemple il m'arrive lorsque la requête utilise des jointures de la préciser manuellement pour avoir une requête bien faite qui n'engendre qu'une seule requête sur la BDD plutôt que plusieurs en temps normal.
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  16. #16
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 736
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 736
    Points : 52 448
    Points
    52 448
    Billets dans le blog
    5
    Par défaut
    Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
    http://ormeter.net/

    De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  17. #17
    Membre actif
    Avatar de Fabien Henon
    Homme Profil pro
    Développeur indépendant
    Inscrit en
    Mars 2005
    Messages
    151
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur indépendant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mars 2005
    Messages : 151
    Points : 226
    Points
    226
    Par défaut
    Merci pour vos réponses, ça m'est très utile !
    Soft Creations - FirmLife

    Soft Creations: Blog de Fabien Henon et site de prestations de sites web et applications mobiles
    FirmLife: Le nouveau jeu de gestion d'entreprises en ligne

  18. #18
    Modérateur

    Avatar de CinePhil
    Homme Profil pro
    Ingénieur d'études en informatique
    Inscrit en
    Août 2006
    Messages
    16 793
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Ingénieur d'études en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : Août 2006
    Messages : 16 793
    Points : 34 024
    Points
    34 024
    Billets dans le blog
    14
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
    http://ormeter.net/

    De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

    A +
    Une preuve de plus qu'un ORM est un Objet Réellement Merdique !
    Philippe Leménager. Ingénieur d'étude à l'École Nationale Supérieure de Formation de l'Enseignement Agricole. Autoentrepreneur.
    Mon ancien blog sur la conception des BDD, le langage SQL, le PHP... et mon nouveau blog sur les mêmes sujets.
    « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)
    À la maison comme au bureau, j'utilise la suite Linux Mageïa !

  19. #19
    Membre expert
    Avatar de alassanediakite
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2006
    Messages
    1 599
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : Mali

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2006
    Messages : 1 599
    Points : 3 590
    Points
    3 590
    Billets dans le blog
    8
    Par défaut
    Salut
    Citation Envoyé par SQLpro Voir le message
    Voici les métrqiues de Hibernate (entre autres) vous y constaterez qu'un simple UPDATE met 24 fois plus de temps qu'un UPDATE fait directement sur le SGBDR sans passer par la couche objet.
    http://ormeter.net/

    De plus si vous voulez des performances il faut développer UNIQUEMENT en procédures stockées et ne jamais faire de requêtes initialisées depuis le client.

    A +
    La discussion est certe résolu, mais juste une remarque. Je pense que lien parle de NHibernate et non de Hibernate. Mes excuses si je suis dans le choux
    @+
    Le monde est trop bien programmé pour être l’œuvre du hasard…
    Mon produit pour la gestion d'école: www.logicoles.com

  20. #20
    Membre éprouvé Avatar de Jester
    Inscrit en
    Septembre 2003
    Messages
    813
    Détails du profil
    Informations forums :
    Inscription : Septembre 2003
    Messages : 813
    Points : 1 058
    Points
    1 058
    Par défaut
    Dans un thread qui explique que php est plus rapide que Java, qui préconise d'utiliser SQL Server alors qu'aucun jeu de ce type n'utilise SQL Server dans la concurrence, je crois qu'on est plus à cette approximation près.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Tec pour un jeu vidéo en ligne
    Par ddavid88 dans le forum Performance Web
    Réponses: 2
    Dernier message: 04/07/2013, 10h42
  2. développement piloté par les tests pour un jeu vidéo
    Par Mindiell dans le forum Méthodes Agiles
    Réponses: 1
    Dernier message: 06/08/2009, 11h28
  3. Langage de script pour un jeu vidéo
    Par Balmung dans le forum Développement 2D, 3D et Jeux
    Réponses: 7
    Dernier message: 28/06/2009, 11h18
  4. Quels revenus pour un jeu vidéo?
    Par gamerome dans le forum Projets
    Réponses: 26
    Dernier message: 24/01/2008, 18h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo