Publicité
+ Répondre à la discussion
Page 2 sur 2 PremièrePremière 12
Affichage des résultats 21 à 24 sur 24
  1. #21
    Futur Membre du Club
    Inscrit en
    décembre 2009
    Messages
    28
    Détails du profil
    Informations forums :
    Inscription : décembre 2009
    Messages : 28
    Points : 17
    Points
    17

    Par défaut

    C'est assez amusant quand-même.

    Il faut bien évidemment faire les bon choix techniques avant de commencer à développer, mais il faut arrêter de voir tout de suite dans le "gros", faut arrêter de rêver.

    C'est très peu probable que ce jeu en ligne fasse 300k requêtes par seconde.
    MySQL ou PostgreSQL peuvent très bien convenir. Vu qu'à ce que j'ai compris le jeu utilisera un ORM il sera alors plus ou moins aisé de faire la migration sur un autre SGBDDR si un jour le besoin est.

    Je vois qu'SQLpro est plutôt pro-Microsoft (tant mieux vu qu'il est MVP).
    Mais il faut arrêter de dénigrer les autres technologies, comme Java.
    Java reste moins performant que les langages compilés tel que le C, mais il reste quand-même plutôt bon.
    La plateforme .Net et le C# sont certainement au même niveau que le Java.
    SQL Server est certes certainement très bon mais pour un simple jeu par navigateur, pourquoi ne pas utiliser des technologies libres ?

  2. #22
    Modérateur

    Homme Profil pro Fabien
    Ingénieur d'études en décisionnel
    Inscrit en
    septembre 2008
    Messages
    6 809
    Détails du profil
    Informations personnelles :
    Nom : Homme Fabien
    Âge : 36
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études en décisionnel
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : septembre 2008
    Messages : 6 809
    Points : 13 450
    Points
    13 450

    Par défaut

    Citation Envoyé par iMeee Voir le message
    SQL Server est certes certainement très bon mais pour un simple jeu par navigateur, pourquoi ne pas utiliser des technologies libres ?
    La demande initiale est bien quel SGBD pour gérer 300k requêtes par secondes.

    Je pense aussi comme Jester et vous que c'est probablement vu trop gros pour commencer, mais on ne peut pas reprocher à SQLPro de répondre à la question.

  3. #23
    Modérateur

    Profil pro
    Inscrit en
    janvier 2010
    Messages
    2 830
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : janvier 2010
    Messages : 2 830
    Points : 4 729
    Points
    4 729

    Par défaut

    Bonjour
    Citation Envoyé par Fabien Henon Voir le message
    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.
    SQL Server existe en version gratuite (SQL Server Express). Vu ce que vous décrivez, vous serez vite contraint de bypasser votre ORM pour certaines requêtes complexes ou spécifiques (faire des procédures stockées, ...) et alors changer de SGBDR ne se fera pas sans mal (malgré votre ORM ou toute surcouche d'abstraction que vous utiliserez)...

  4. #24
    Nouveau Membre du Club
    Homme Profil pro
    Inscrit en
    février 2013
    Messages
    23
    Détails du profil
    Informations personnelles :
    Sexe : Homme

    Informations forums :
    Inscription : février 2013
    Messages : 23
    Points : 28
    Points
    28

    Par défaut

    Citation Envoyé par Waldar Voir le message
    La demande initiale est bien quel SGBD pour gérer 300k requêtes par secondes.

    Je pense aussi comme Jester et vous que c'est probablement vu trop gros pour commencer, mais on ne peut pas reprocher à SQLPro de répondre à la question.
    Par contre, il est urgent qu'il arrête d'écrire des contre-vérités en dehors de son domaine d'expertise.

    D'une part l'excellente petite présentation du début du topic montre qu'un jeu peut servir 2 millions d'utilisateurs avec quelques dizaines de serveurs alors qu'il est écrit en Ruby.

    Fact: Ruby est grosso merdo entre 10 et 50x plus lent que Java (l'implémentation du calcul de pidigits n'est manifestement pas optimisée). Si Java était si peu performant, Oracle n'aurait pas pris la peine d'intégrer une JVM dans son moteur de bases de données et d'en faire l'un de ses principaux chevaux de bataille.

    Donc si ça marche en Ruby, il n'y a pas de raison que ça ne marche pas en Java, pour peu qu'on fasse un peu attention à ce qu'on fait. Et d'ailleurs, pas mal de jeux en ligne ont leurs serveurs écrits en Java.
    Ensuite, PostgreSQL est capable de répondre à 350 000 queries/sec et 14000 écritures/sec (seulement) sur une machine 64 cores. Il faudrait vraisemblablement mettre plusieurs instances en parallèle. Mais même si on n'atteint pas un tel débit, comme le montre la présentation, le vrai secret est de limiter les accès à la base en tapant au maximum dans les caches redis ou memcache. Si le backend est optimisé, on peut diviser par 5 ou 10 les accès à la Bdd.
    Donc en principe, si on a une grosse machine multicore pour la base doublée d'un cache redis sur d'autres serveurs, et d'un moteur de jeu écrit en Java sur quelques serveurs supplémentaires, il est parfaitement possible d'atteindre des centaines de milliers de joueurs pour un jeu Flash en ligne.

    Après, il y a d'autres problèmes, qui sont décrits dans le slide suivant (qui fait suite au slide d'avant: http://fr.slideshare.net/wooga/20121...e-game-servers). En gardant l'état de la partie complètement en RAM et en écrivant sur le disque uniquement quand le joueur quitte l'application (ce qui a impliqué de réécrire leur backend de Ruby à Erlang), ils ont divisé par 100 le nombre d'écriture en base, et sont donc passés de 150+ serveurs à 3 serveurs seulement, tout en augmentant la disponibilité.
    Leur 4e backend gère les parties multijoueurs, et leurs exigences ressemblent un peu à ce qu'offrent des bases NoSQL comme HBase et Cassandra.
    http://fr.slideshare.net/wooga/you-a...tiplayer-games
    Ils ont choisi Riak.

+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 2 PremièrePremière 12

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •