yodark Posté 27 Février 2009 Posté 27 Février 2009 Bonjour à tous, Je voudrais savoir combien d'utilisateurs simultané peut supporter une application en PHP faisant des requêtes mySQL sur un hébergeur mutualisé (www.infomaniak.com) ? J'explique mon problème, j'ai actuellement un jeu écrit en PHP qui se joue en multijoueurs ou contre l'ordinateur. Les parties contre l'ordinateur ne me font pas souci mais les parties multijoueurs c'est plus compliqué. En effet en multi le status et les variables de la partie sont stockés dans une base MySQL. Toutes les 3 secondes (ou plus) le système appelle une page qui va aller chercher le status actuel de la partie dans la base de données. Et comme je prévois une expansion du jeu je me demande si le serveur pourra supporter ça... Donc si 3000 joueurs sont connectés il y aura 1000 requêtes par secondes, c'est viable ça ? Quel seraient les solutions (répartir la charge sur plusieurs bases, ne pas utiliser mySQL) ?
Dan Posté 27 Février 2009 Posté 27 Février 2009 Utiliser un serveur dédié ... Parce qu'à 1000 requêtes par seconde, je doute qu'Infomaniak tolère le compte !
yodark Posté 27 Février 2009 Auteur Posté 27 Février 2009 Combien d'utilisateurs estime-tu d'utilisateurs pour prendre un serveur dédié ? Je caricature mais si il faut un serveur dédié pour 4 utilisateurs et deux serveurs pour 8 utilisateurs je peux abandonner directement le projet Combien de requêtes secondes ? La grande question que je me pose est : est-il possible que je lance mon service tel quel dans un premier temps puis évoluer plus tard vers un service dédié en cas de succès ou faut-il que je trouve une autre solution pour stocker récuperer des valeurs car ça ne sera jamais viable?
jcaron Posté 27 Février 2009 Posté 27 Février 2009 Il y a plein de solutions techniques qui seront certainement plus efficaces qu'une base mysql pour ce genre de choses, mais elles passent toutes par l'utilisation d'un dédié (utilisation de memcached, de mémoire partagée, d'un démon maintenant l'état de tout le monde en mémoire...). Ensuite plutôt que de faire des requêtes en permanence, tu peux avoir intérêt à utiliser un système par lequel les joueurs ont des connexions "en attente" jusqu'à ce qu'un événement se produise, donc plutôt "notification-driven" que "polling" (ce qui a de plus l'avantage d'être beaucoup plus rapide). Mais tu ne pourras probablement pas faire ça avec apache/php, il faudra quelque chose de nettement plus "léger". Jacques.
yodark Posté 27 Février 2009 Auteur Posté 27 Février 2009 ok alors j'en reviens a ma question initiale combien de joueurs simultanés (a 1 requête pour 3 sec) peu supporter une base mySQL mutualisée ?
paolodelmare Posté 27 Février 2009 Posté 27 Février 2009 C'est difficile de donner une réponse pertinente. Certains hébergeurs de mutus surveillent l'activité de ton domaine pour éviter les scripts qui bouclent indéfiniment et risquent de ne pas tolérer une surcharge. Le mieux est de consulter l'aide ou les forums de ton hébergeur ou de contacter le service technique. Pour un taux récurrence important, il te faudra un dédié.
jcaron Posté 27 Février 2009 Posté 27 Février 2009 Difficile à dire... Il n'y a pas que les requêtes SQL en plus, il y a les requêtes php qui vont avec, et évidemment il y a la complexité des deux. Pas pareil de faire "SELECT 1" et de faire un gros select avec des jointures sur 12 grosses tables. Pareil au niveau php, ce n'est pas la même chose que de faire juste une requête SQL et de renvoyer une valeur que de faire plein de traitements dans tous les sens... Sur certains mutualisés tu vas avoir des limites bien établies sur le nombre max de requêtes (simultanées, par minute, whatever), sur d'autres tu n'en as pas, mais les performances vont s'écrouler et/ou ils vont te mettre dehors et/ou les performances vont varier énormément en fonction de que les autres sites sur la même machine font (ce qui peut varier suivant l'heure, etc.). Ce qui est normal, un mutualisé c'est pas cher, mais comme toute ressource partagée, c'est un peu le loto. C'est comme le métro, tu ne sais pas si tu vas faire le voyage assis tranquillement ou debout serré contre la vitre... En plus sur un mutualisé tu as généralement peu d'outils qui te permettent de voir précisément l'"état" de la machine et de savoir si tu es à 1% des capacités ou si au contraire tu es juste à la limite et si tu augmentes de 10% la machine est à genoux. Bref, si c'est un projet un peu sérieux, tu as probablement intérêt à prendre un dédié dès le départ. Au moins tu pourras instrumenter pour voir la consommation (en RAM, en CPU, en accès disque...) de ton service, et tu pourras extrapoler sur le nombre de joueurs potentiels. Jacques.
yodark Posté 27 Février 2009 Auteur Posté 27 Février 2009 Difficile à dire... Il n'y a pas que les requêtes SQL en plus, il y a les requêtes php qui vont avec, et évidemment il y a la complexité des deux. Pas pareil de faire "SELECT 1" et de faire un gros select avec des jointures sur 12 grosses tables. Pareil au niveau php, ce n'est pas la même chose que de faire juste une requête SQL et de renvoyer une valeur que de faire plein de traitements dans tous les sens... Pour ce qui est de la complexité des connections la majeur partie du temps c'est une requete simple sur une table simple permetant de récuperer une valeur disant si oui ou non le joueur à déjà joué son tour. Je pense que c'est ça la requete qui sera très (trop) souvent effectuée
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant