Je travaille sur un jeu pseudo-multijoueur qui stocke les données importantes de chaque joueur sur ma base de données MySQL. Le jeu est similaire à celui des clans des clans dans lesquels les joueurs construisent leurs propres bases et peuvent choisir d'attaquer les bases des autres joueurs.
Pour éviter toute triche, toutes les fonctions importantes sont exécutées sur mon serveur via PHP. Par exemple, si un joueur souhaite construire une maison, le serveur est dit: le joueur veut construire le bâtiment_a à la grille {x, y} et le script PHP vérifie de la base de données si la zone est gratuite, si le joueur a la technologie , l'argent, etc. pour le faire.
Toutes ces fonctions sont relativement simples. Ils vérifient simplement qui a essayé d'accéder à la base de données et s'ils peuvent faire ce qu'ils voulaient faire. Ensuite, le serveur mettra à jour les données du lecteur dans la base de données et renvoyera un message à l'appareil.
Donc, essentiellement, mon jeu suivra toujours le même processus:
1) appareil de lecteur fait une demande,
2) Le serveur authentifie le lecteur et permet ou nie la demande,
3) Le serveur envoie un appareil de lecteur une réponse et le périphérique le suit.
Mais je ne suis pas sûr de la manière viable ou évolutive de mon approche. Je viens de le tester seul et ça marche bien, mais disons que je reçois 100 ou 1000 joueurs dans la première semaine. Il peut y avoir quelques centaines de demandes de serveur par seconde au pic, où les scripts PHP sont appelés et la base de données est accessible et mise à jour. Et si cela devient un coup et il y a des milliers de personnes accédant simultanément à mes scripts et bases de données PHP?
Ce type d'approche est-il viable au tout pour commencer? Si mon (s) serveur (s) était assez puissant, un script PHP unique peut-il être accédé par tant de personnes en même temps, et le serveur peut-il écrire à ma base de données des centaines de fois dans une seconde? Cela ferait-il la file d'attente des opérations, cela ignorerait-il certaines des opérations qui se chevaucheraient simplement échouent?
Par exemple, si j'ai payé AWS EC2 et installez ma lampe, ce type de système peut-il travailler ou puis-je rencontrer une sorte de limitation ou de problèmes que je ne suis pas au courant?
5 Réponses :
Oui, plus de 10 000 demandes par seconde peuvent être facilement gérées par l'environnement de la lampe.
Une seule suggestion ici au lieu de Report: https://theorganicagency.com/blog/apache- vs-nginx-performance-comparaison /
Si vous souhaitez effectuer une analyse comparative par vous-même que vous pouvez utiliser: HTTPS: // www.litespeedtech.com/benchmarks/php-hello-world
Comme vous envisagez de le déployer sur EC2 pour l'initialement, vous pouvez utiliser M5A.Large et plus loin sur la popularité Créez (clone) un autre serveur Ubuntu et les mettre à la fois sous ELB.
Bonne chance! Apache2 Utilisez le serveur nginx serveur qui fonctionne mieux que Apache2 serveur. Comme nginx est toujours le meilleur choix pour la performance dans la plupart des situations.
"Dans la plupart des situations" - Compte tenu de la capacité de la demande bien définie, Apache + Mod_PHP, en particulier pour une application de service de données surperformera une large marge de NGinx + PHP-FPM. La différence est Effacer avec le contenu mixte / la réglementation des charges dépassant la capacité planifiée / l'hébergement minimal bon marché.
Le script PHP est accessible par tant de personnes en même temps et le serveur peut-il écrire à ma base de données des centaines de fois dans une seconde? Cela ferait-il la file d'attente des opérations, cela ignorerait-il certaines des opérations qui se chevaucheraient simplement échouent?
- des centaines par seconde - OK. Des milliers - cela dépend.
- File d'attente des opérations - Oui, mais c'est plutôt rapide; Les opérations seront principalement effectuées en parallèle.
- Ignore certains - N ° bien, s'ils restent la file d'attente pendant si longtemps qu'il dépasse
verrk_wait_timeout , qui est par défaut comme 50 secondes. (Peu susceptible de se produire.)- 'juste échouer' - non.
Vous devriez probablement prévoir d'avoir suffisamment de RAM pour gérer toutes les données impliquées. (On sonne comme ça ne sera pas de problème.) Si les requêtes doivent atteindre le disque trop souvent, que devient une limitation de la mise à l'échelle du jeu. AWS EC2 utilise des SSD, correct? (HDDS serait trop lent.)
sont impliqués des graphiques? Qu'est-ce qui gère ça? Est-il entièrement dans le navigateur client de chaque utilisateur? Je demande parce que s'il y a des requêtes SQL impliquées dans la redécession de l'écran, que pourrait être une charge lourde.
On dirait que la "session" typique est
- Démarrage PHP
- Connectez-vous à MySQL
Sélectionnez INFO UTILISATEUR- Faites du traitement PHP
- `Mettre à jour les informations utilisateur
Et cela arrivera, en moyenne une fois toutes les quelques secondes. Mille utilisateurs qui font cela devraient être faciles à atteindre.
qui suppose qu'il s'agit d'un jeu à une seule personne. Si, au lieu de cela, il s'agit d'un jeu multi-utilisateur, la "maison nouvellement construite" ne doit pas être diffusée à tous les autres utilisateurs?
Les graphiques ne seraient pas impliqués. J'ai une table mysql où chaque joueur est représenté par une rangée qui a des choses comme leur identifiant, une quantité d'or, une chaîne JSON de leur disposition de base, etc. Tous les graphiques et tels que cela seraient traités dans l'application Android / iOS. L'application enverrait le serveur la commande du lecteur, comme "Le joueur veut construire la maison à l'emplacement X, Y". Le serveur charge ensuite les données du joueur et vérifie si le lecteur a suffisamment d'argent et si la zone de construction est gratuite. Si tout fonctionne, le serveur mettra à jour la saisie de la base de données du lecteur. Ensuite, le serveur renvoie un message comme "succès" ou "échec", et pourquoi.
@Jamest. - J'ai ajouté à ma réponse.
Eh bien, c'est un jeu pseudo-multijoueur. L'information doit être mise à jour uniquement pour le joueur dont la ville est lorsque l'action est prise. L'idée est similaire à celle des clignotants dans ce que chaque joueur voit sa propre ville et lorsqu'une nouvelle maison commence à construire, aucun autre joueur n'est notifié. D'autres joueurs peuvent voir les villes des autres via différentes commandes, mais dans ces cas, seule la mise en page de la ville du joueur serait renvoyée à leur appareil à partir du serveur et que l'application du joueur rendrait la ville en fonction des informations données. Donc, lorsque quelque chose est construit, seul le joueur qui l'a construit le sait.
@Jamest. - Eh bien, tous les autres trafic feront partie de la rapidité des échelles du système. Alors, réfléchissez à une minute de jeu «typique», énumérant toutes les requêtes SQL typiques. Énumérez-les comme si j'ai essayé de faire. Alors Nous pouvons discuter de la mise à l'échelle.
@Jamest. - et je suppose de votre dernier commentaire que si 3 autres joueurs sont dans ma ville , alors quand i construire une maison, certains sélectionnez est nécessaire Pour les découvrir, plus un message doit aller à chacun d'eux. Pendant ce temps, ma nouvelle maison n'a aucun impact sur le reste des milliers d'utilisateurs.
@Jamest. - Alors, ... si la découverte de "qui d'autre est dans ma ville" doit être codée efficacement, sinon cela pourrait être le goulot d'étranglement de la performance.
Fondamentalement, chaque fois qu'un autre joueur charge votre ville, ils chargent simplement la disposition / carte de la ville une fois. Si vous décidez de construire une nouvelle maison, il ne sera pas mis à jour pour que quiconque soit à moins qu'ils (laissent) et rechargez votre ville. La seule fois où un joueur peut vraiment voir votre ville est si ils envisagent de l'attaquer. Et, comme dans Clash of Clans, vous ne pouvez pas attaquer les joueurs en ligne. Il n'est donc même pas possible pour quelqu'un de voir votre ville pendant que vous le construisez.
Tout d'abord, vous voudrez probablement rechercher un package "AJAX Server" ou "Serveur de procédure à distance (serveur de procédure à distance" écrit dans la langue de votre choix. Vous n'avez réellement besoin de "serveur Web" pour faire ce travail particulier. Vous pouvez trouver des outils plus spécialisés et plus légers spécifiquement ciblés pour cet objectif . (Et pour "déploiements conteneurisés" qui sont couramment utilisés pour des tâches telles que celles-ci.)
Les fournisseurs tels que Rackspace écrivent très largement sur leur site Web sur différentes façons de déployer "des serveurs dynamiquement évolutifs". Je crois qu'ils ont toujours une rémunération par une entreprise qui vend une application mobile utilisée par "Mamans de football". Lorsque personne n'utilise l'application, les "conteneurs" correspondants ne fonctionnent pas. Lorsque le week-end vient et chaque maman goudune leur écran tout en regardant leurs petits cheaux courir sur le terrain, un nombre réglable de conteneurs viennent de dynamiquement en ligne pour gérer la charge ... puis éventuellement mourir à nouveau.
Alors, oui, votre raisonnement est sonore et votre exigence est très courante. Vous pouvez rester sur les épaules des géants ici.
Disons que je reçois 100 ou 1000 joueurs dans la première semaine
Je pense que vous n'avez pas à vous soucier de la configuration pour ce nombre de joueurs. Mais je vais écrire quelles sont les choses possibles que vous devriez être au courant afin de rendre votre système suffisamment robuste pour gérer le trafic important
Vérification de
MySQL max_connections limiteVérification de
Apache2 MAXREQUESTWORKERS LIMIT Pour plus d'informations Voir cette questionVérification de
Nombre maximum de fichiers ouverts au niveau du système Pour plus d'informations Voir ceSi votre nombre de joueurs augmente, vous pouvez utiliser
ELB avec plusieurs instances etesclave MySQL maître
Il n'y a pas de réponse facile à cela, mais pour une application bien écrite exécutée sur un serveur bien configuré, l'exécution de la logique ne prendra qu'une fraction du temps pris pour traiter une demande de demande - les temps de réponse sont normalement dominés par le réseau. Temps de voyage aller-retour et le temps passé à parler au SGBD. Lorsque les systèmes multi-utilisateurs échouent souvent à l'échelle consiste à manipuler la concurrence; Choses que le programmeur pense fonctionner parallèlement à fonctionner de manière séquentielle et peut utiliser le verrouillage pour l'appliquer. D'où le choix du langage de programmation (tant que ce n'est pas CGI, où un programme est indiqué pour gérer chaque demande) ne comporte pas beaucoup d'importance.
Vous devez être capable de comparer chacune de ces opérations - collecter des données sur les temps de réponse de bout en bout sur le client et le récupérer à un emplacement central (pas nécessairement en temps réel) et la collecte de mesures sur la base de données attend temps dans votre application.
Les sessions PHP peuvent être un goulot d'étranglement majeur - essayez également de minimiser le nombre d'appels que chaque demande apporte à la base de données.
J'ai vu Blated WordPress installe des difficultés à tourner autour d'une demande en moins de 3 secondes avec 256 Mo de RAM et de ne pas prendre en charge plus de 20 connexions simultanées sur un hôte spécifique raisonnablement spécifié - et j'ai également vu des systèmes de gestion de contenu capables de manipuler Une demande en 10millisecondes avec une limite de 4 Mo de RAM. À peu près une différence de capacité de plus de mille fois.
Si je comprends votre candidature, je pense que vous devriez envisager un courtier de messages et des sockets Web au lieu d'une solution à base de traction. Si vous venez de PHP, regardez Rabbitmq. Cela réduirait la circulation et l'échelle mieux.