Tu te poses trop de questions pour des problèmes de perfs minimes... Tu verras bien à l'usage ce qu'il se passera. Il ne faut pas avoir les miquettes d'un "mon jeu a trop de succès!" ce serait franchement dommage...!
Pour répondre aux points techniques (donc, pas ceux de quantification de perfs dont on se tamponne un peu tant et que tu verras plus tard):
• Je ne sais pas pour la mémoire... OVH laisse une marge sur les mutus, pour autoriser un dépassement temporaire en pointe de charge, mais s'il persiste, ils te lockent cette mémoire et t'invite à monter en gamme, tout simplement. 50€/an ou 3 mois de dev? A toi de voir ce qui te "coûte" le moins cher.
• Bof, AJAX ou pas AJAX, t'as exactement les mêmes performances, la seule différence se fait sentir au niveau de la quantité de données retournée (et encore, si Gzippée côté serveur, une page web HTML et un JSON n'ont pas une diff de ouf). Ton impression de vitesse vient probablement plus du fait que l'AJAX n'a pas à être parsé puis rendu par le navigateur
• Une requête UPDATE ou un SELECT simple sont kiff kiff niveau vitesse. Si t'as des différences, c'est que t'as peut-être foiré tes index SQL
• Plus il y a de joueurs... requêtes SQL. Oui, il manque un mot dans la suite logique. Donc je vais supposer: + de joueurs => + de requêtes HTTP => plus de requêtes SQL. Un SQL peut lire plusieurs lignes de tables en même temps, cela ne pose aucun soucis. Donc, les traitements de requêtes ne changeront pas des masses.
• MySQL traite les requêtes de sessions parallèle "au mieux", donc, autant que possible, en parallèle. Les requêtes deviennent séquentielles uniquement si l'une bloque l'autre (transaction non fermée ou verrou sur une ligne qu'une autre requête veut lire/écrire). Il faut pas s'arrêter aux perfs de MySQL: elles sont excellentes (bon, OK, Oracle lui fout probablement une branlée, mais le goulot d'étranglement n'est *pas* le serveur SQL lui-même, sauf si on l'utilise comme un cochon). Si t'as un bundle de 3-4 requêtes à faire et que tu trouves que des latences se font sentir, alors c'est probablement un soucis de connexion PHP-MySQL. Tu peux le résoudre par les connexions persistantes (mais elles ont des effets de bord) ou par des appels de procédure (qui réduisent les N requêtes à 1 seule). Donc, il suffit de bien savoir gérer ses transactions et la notion de verrou en lecture/écriture pour avoir 0 soucis de perf ('fin bon, évidemment, tu feras pas un Twitter avec un SQL privé de 256Mo de RAM hein... mais bon! ).
• Hum, je ne sais pas pour ton "hit, miss, not, pass": où les as-tu vus (je dirai au niveau d'une page de stats de cache SQL peut-être)?
• Le temps de latence peu venir des deux réseaux: entre ta machine et le serveur (ordre de grandeur: 100ms à 1s) et entre le PHP et le MySQL (ordre de grandeur chez OVH: 1ms, ordre maxi: 5-10ms)
Pour répondre aux points techniques (donc, pas ceux de quantification de perfs dont on se tamponne un peu tant et que tu verras plus tard):
• Je ne sais pas pour la mémoire... OVH laisse une marge sur les mutus, pour autoriser un dépassement temporaire en pointe de charge, mais s'il persiste, ils te lockent cette mémoire et t'invite à monter en gamme, tout simplement. 50€/an ou 3 mois de dev? A toi de voir ce qui te "coûte" le moins cher.
• Bof, AJAX ou pas AJAX, t'as exactement les mêmes performances, la seule différence se fait sentir au niveau de la quantité de données retournée (et encore, si Gzippée côté serveur, une page web HTML et un JSON n'ont pas une diff de ouf). Ton impression de vitesse vient probablement plus du fait que l'AJAX n'a pas à être parsé puis rendu par le navigateur
• Une requête UPDATE ou un SELECT simple sont kiff kiff niveau vitesse. Si t'as des différences, c'est que t'as peut-être foiré tes index SQL
• Plus il y a de joueurs... requêtes SQL. Oui, il manque un mot dans la suite logique. Donc je vais supposer: + de joueurs => + de requêtes HTTP => plus de requêtes SQL. Un SQL peut lire plusieurs lignes de tables en même temps, cela ne pose aucun soucis. Donc, les traitements de requêtes ne changeront pas des masses.
• MySQL traite les requêtes de sessions parallèle "au mieux", donc, autant que possible, en parallèle. Les requêtes deviennent séquentielles uniquement si l'une bloque l'autre (transaction non fermée ou verrou sur une ligne qu'une autre requête veut lire/écrire). Il faut pas s'arrêter aux perfs de MySQL: elles sont excellentes (bon, OK, Oracle lui fout probablement une branlée, mais le goulot d'étranglement n'est *pas* le serveur SQL lui-même, sauf si on l'utilise comme un cochon). Si t'as un bundle de 3-4 requêtes à faire et que tu trouves que des latences se font sentir, alors c'est probablement un soucis de connexion PHP-MySQL. Tu peux le résoudre par les connexions persistantes (mais elles ont des effets de bord) ou par des appels de procédure (qui réduisent les N requêtes à 1 seule). Donc, il suffit de bien savoir gérer ses transactions et la notion de verrou en lecture/écriture pour avoir 0 soucis de perf ('fin bon, évidemment, tu feras pas un Twitter avec un SQL privé de 256Mo de RAM hein... mais bon! ).
• Hum, je ne sais pas pour ton "hit, miss, not, pass": où les as-tu vus (je dirai au niveau d'une page de stats de cache SQL peut-être)?
• Le temps de latence peu venir des deux réseaux: entre ta machine et le serveur (ordre de grandeur: 100ms à 1s) et entre le PHP et le MySQL (ordre de grandeur chez OVH: 1ms, ordre maxi: 5-10ms)