Php est-il suffisament robuste pour traiter des applications vraiment complexes

Je me demande si Php + MySql sont assez robustes pour
supporter un serveur effectuant des transcations multiples,
simultanées, de type bancaire:
- environ 20 tables
- chaque table sera en relation en moyenne avec 5 autres
- lecture de 10 tables
- insertion d'un enregistrement dans 10 tables, dont 3 que
j'ai lu, à chaque coup d'un joueur (300 octets en moyenne
par enregistrement)
- plusieurs mises à jour concurrentielles de valeurs dans
5 tables partagées (50 octets en moyenne pour une mise
à jour)
pour ce qui est des tables oui et non. en fait tout dépend du nombre de

joueurs. et de ton MCD.

- une transaction durerait entre 3 et 5 minutes
- une transaction moyenne = 5.000 lignes de code Php à dérouler
en plusieurs modules, avec de nombreux contrôles d'intégrité
5000 lignes ça ne veut rien dire. cela dépend du nombre d'instructions

des éléments (objets?) que tu comptes utiliser, la version de php etc...

Si c'est hébergé sur un PC de type Intel® P4 à 3 Ghz,
combien de joueurs maxi je pourrais supporter?

Pensez-vous que je puisse faire 300 transactions en simultané?
Tu devras conserver 300 connexions ouvertes vers l'extérieur, ce qui à

priori ne posera pas de pb, mais ton couple apache/php risque de
consommer un peu (trop) là dessus.

Franchement la meilleure solution c'est de faire des tests. et vu ce que

tu décris c'est pas bien difficile à faire : tu t'installes ton
apache/php/mysql et tu fais tout tes petits tests. Tu auras ainsi une
réponse certaine à ta question.

A priori, et je dis bien A PRIORI, ce que tu annonces ne me semble pas
énorme. maintenant il faut voir aussi la ram, la qualité de ton code,
ton pool de cnx mysql, le nb de joueur etc... Le mieux : fais des tests
sur différents scnéarii.

Lionel.

"Jerry Khann" <jerry_O_khann@freesurf.fr.invalid> a écrit dans le message de
news: cudhb3$2rt$1@ws41.cines.fr...

Je me demande si Php + MySql sont assez robustes pour
supporter un serveur effectuant des transcations multiples,
simultanées, de type bancaire:

MySQL n'est pas une base transactionnelle sauf en l'utilisant en mode
InnoDB.
Dans ce cas elle perd une trs grandes part de son interet a savoir sa
vitesse.
Donc autant prendre PostGreSQL...

Etienne

Tu parles de tables, de relations complexes, de données nombreuses, et
de nombreuses connections.
Tout ça n'a pas à voir avec PHP mais avec ton SGBD, ici MySQL.
Moi je te conseillerais plutôt de passer à PostgreSQL, ou à Oracle,
puisque tu sembles déjà le connaitre.

D'autant plus que vu la lourdeur de ton système, les fonctions avancées
peuvent faire du bien.

- une transaction durerait entre 3 et 5 minutes
- une transaction moyenne = 5.000 lignes de code Php à dérouler
en plusieurs modules, avec de nombreux contrôles d'intégrité

Je ne comprends pas ces deux points.

Jerry Khann wrote:

Bonjour,

Je suis en train de créer un jeu de rôle (non graphique)
en Php-MySql
...

Pensez-vous que je puisse faire 300 transactions en simultané?

je crois que tu confonds transaction au sens base de données
et transaction au sens utilisateur.

enfin, les 2 types de transactions possedent la meme signification
et la meme sémantique, cependant pour des raisons pratiques, tu
peux faire en sorte que les transactions utilisateur ne
conduisent pas à des transaction sur la BD. Il est certain que
les transactions en base de donnée sont couteuses en performance.

Une transaction au sens base de données, ce n'est que gerer une
situation de conflit sur une meme ressource par plusieurs utilisateur.

Est-ce que ton jeu de role sera intéractif ? dans ce cas, via de
simples clics souris, il est possible de prendre une forme de jeton,
et quand on possede ce jeton il est possible d'agir dans un
espace précis de ton espace de jeu. Quand le jeton est relaché
c'est un autre joueur qui prend la main. Reste a definir une granularité
suffisament fine pour eviter trop de colisions.

Bonjour,

Avant toute chose, ce titre m'agace fortement. Tous les langages sont
capables de traiter des applications "vraiment complexes", même le
fortran, le cobol ou le lisp. Mais c'est un autre sujet.

Je suis en train de créer un jeu de rôle (non graphique)
en Php-MySql
Architecture ? Socket connectée ? http/asynchrone non connecté ? Push de

données du serveur vers le client, applets java dans le client, uniquement
get de al part du client ?

Je me demande si Php + MySql sont assez robustes pour
supporter un serveur effectuant des transcations multiples,
simultanées, de type bancaire:

Ce ne sont pas des transactions.

- environ 20 tables
Donc queudale.

- chaque table sera en relation en moyenne avec 5 autres
Donc il pourra êter nécessaire de dénormaliser. Tout dépend ce qu'on

appelle "être en relation avec".

- lecture de 10 tables
Par requête ("transaction" comme tu dis) ? Ca dépend de la quantité de

données à lire.

- insertion d'un enregistrement dans 10 tables, dont 3 que
j'ai lu, à chaque coup d'un joueur (300 octets en moyenne
par enregistrement)
Lue ou pas on s'en fou complètement dans la pratique, si ce n'est que tu

as potentiellement un dilemne sur la présence ou non d'index.

- plusieurs mises à jour concurrentielles de valeurs dans
5 tables partagées (50 octets en moyenne pour une mise
à jour)
Là, la taille des octets, on s'en tamponne. La question c'est de savoir si

tu utlises ici "concurrentielles" en tant que "pouvant avoir lieu au même
moment" ou "accédant en concurrence aux même données", cas dans lequel il
faudra probablement des transactions (les vraies, pas le terme que tu
utilises).

- une transaction durerait entre 3 et 5 minutes
Donc on est en mode connecté apparement, ou est-ce qu'on peut couper en N

reuqêtes atomiques (y'a intérêt).

- une transaction moyenne = 5.000 lignes de code Php à dérouler
en plusieurs modules, avec de nombreux contrôles d'intégrité
RAF, c'est de la puissance CPU. Si le parsing pur prend beaucoup de temps,

on peut penser à des caches d'opcode (compiler les scripts si tu
préfères).

Si c'est hébergé sur un PC de type Intel® P4 à 3 Ghz,
combien de joueurs maxi je pourrais supporter?
Ca dépend, outre les questions que j'ai posé, de la qualité du codage. En

particulier de la gestion des requêtes sur le SGBDR.

Pensez-vous que je puisse faire 300 transactions en simultané?
Ce qui compte en non connecté, c'est le nombre de requêtes http seconde.

Si une personne qui joue fait 2 clics en 5 minutes ou 3000 clics en 5
minutes, c'est pas pareil. Donc on se fout du temps de connexion de
chacun, c'est le besoin instantané qu'on doit mesurer.

----- Pour les modérateurs
----- à retirer, si vous voulez
-----
Les modérateurs ne changent pas les articles des contributeurs, ils ne

font que l'approuver ou le refuser en l'état.

Parce que je ne sais pas quelles ressources sont sollicitées
1) réseau, surtout si c'est en mode connecté.

2) CPU pour parser le code php (dnc cache d'opcode)
3) accès disques. C'est là que sont les temps de latence les plus
importants.
4) éventuellement re-réseau si le client sgbdr (php donc) et le serveur
sgbdr(mysql ici) ne sont pas sur la même machine.
5) si tu empiles les couches qui se transmettent 20 fois la même
information dupliquée en copie, la RAM s'explose.

par Php et MySql, le second allant en général avec le premier.
PHP était encore en version 2 (PHP/FI) qu'on utilisait déjà mysql avec

perl...

Si vous me demandez la même chose avec Pascal + Oracle, je sais
vous répondre.
C'est la même chose. La seule différence entre le Pascal et PHP est que

PHP est recompilé à la volée, mais on peut supprimer cette partie. Oracle
et Mysql ont des besoins tout à fait similaires, si ce n'est que si je
sais tout de suite comment et où paramétrer le SGA, je ne sais pas où
aller tripoter dans mysql pour augmenter la taille de son cache.

Théoriquement un informaticien qui connait bien
son environnement technique doit être capable de répondre à cette
question.
Si tu parles des ressources consommées, oui. Du nombre de hits simultanés

que ton appli sera capable d'encaisser... je sens que je vais aller poser
la question à la marmotte...

a++;
JG

Je dirais aussi qu'il peut être avantageux d'utiliser Linux comme OS et pas
Windows parce que tu risques là d'avoir des problèmes de performance plus rapidement...

Bonjour,

J'utilise ce post pour répondre et remercier chacun.

Merci beaucoup de vos réponses et ... questions qui me
permettent d'avancer dans ma réflexion et mon analyse.

Rapidement:
1- La question "énervante" initiale, répondait à une rumeur
que j'entends de ci de là, comme quoi Php+MySql c'est bien
pour des "petites" applications et des "petites" bases,
mais qu'ils trouvent vite leur limites.

J'ai la réponse: ça dépend, et maintenant c'est à moi de
trouver la réponse, qui grâce à vos infos, devrait arriver
facilement.

2- Le fonctionnement interne du parser Php, semble effectivement
être dépendant de la "qualité" de la programmation.

Je ferai donc des tests et des benchmarks pour voir les
limites.

3- Concernant la notion de "transaction": je désigne sous ce
terme, qui semble donc mal adapté à la situation, la
réservation de ressources serveur + parser Php + base de
données, le temps que l'utilisateur ait réalisé l'ensemble
de ses opérations, à la fois du point de vue fonctionnel et
du point de vue technique.

J'ai compris qu'il me fallait étudier plus profondément les
modes de fonctionnement techniques pour optimiser au mieux
la gestion de l'ensemble des ressources.

4- J'ai bien compris l'intérêt, dans ce cas, de "dénormaliser"
la BdD.

5- Mes excuses aux modérateurs et contributeurs pour l'adendum
qui expliquait pourquoi, selon moi, CE groupe était concerné
par mon post.

Finalement, de bonnes questions valent parfois mieux que pas
de réponses.

Merci à tous, je "revois ma copie".

Cordialement

--
Jerry Khann

Adresse invalide: retirer le bouchon _O_ et .invalid

Re,

1- La question "énervante" initiale, répondait à une rumeur
que j'entends de ci de là, comme quoi Php+MySql c'est bien
pour des "petites" applications et des "petites" bases,
mais qu'ils trouvent vite leur limites.

Toute application trouve ses limites. Principe de base que je me tue à
répéter depuis des années : à chaque besoin applicatif la solution qui lui
est la plus adaptée. Il n'y a pas de solution universelle, sinon il y a
longtemps que tout le monde l'emploierait. En particulier, même s'il est
possible de faire un deamon socket en php, je maintiens que du C/C++
serait beaucoup plus adapté. Java en 1.4 (avec NIO) devient tolérable
aussi. En revanche, sortir un serveur d'applications pour accepter trois
arguments en entrée et pondre du html du jpg ou du pdf en sortie, c'est
débile. Etc, etc...

2- Le fonctionnement interne du parser Php, semble effectivement
être dépendant de la "qualité" de la programmation.
Pas tellement en termes de parsing (savoir si on utilise print ou echo ou

des " ou des ' relève très clairement de la sodomie des coléoptères en
termes de perf par rapport aux requêtes inutiles mal codées). Le parsing
a lieu une seule fois par lancement de script. En revanche,
attention à l'utilisation *à outrance* des couches successives.

3- Concernant la notion de "transaction": je désigne sous ce
terme, qui semble donc mal adapté à la situation, la
réservation de ressources serveur + parser Php + base de
données, le temps que l'utilisateur ait réalisé l'ensemble
de ses opérations, à la fois du point de vue fonctionnel et
du point de vue technique.

Justement, on ne réserve pas une ressource pendant tout le temps
d'activité d'un joueur (sauf socket en mode connecté). Il s'agit aussi de
programmation événementielle quelque part, quand on reçoit l'événement "le
joueur a décidé telle action", on exécute (donc au passage, on "réserve"
et on utilise des ressources) puis on les libère au plus vite.

J'ai compris qu'il me fallait étudier plus profondément les
modes de fonctionnement techniques pour optimiser au mieux
la gestion de l'ensemble des ressources.
Principalement les accès concurrentiels à la base de données.

4- J'ai bien compris l'intérêt, dans ce cas, de "dénormaliser"
la BdD.

Dans TOUS les cas, il faut se *poser la question* de dénormaliser ou pas.
Dénormaliser, ça se fait selon les besoins de l'application.
On a pondu un superbe modèle entité-association (pardons aux Merisiens : un
MCD), puis un superbe modèle relationnel (encore pardon : un MLD), là si
on dénormalise pas au moment du CREATE TABLE, on COURT A LA CATA dans
moult % des cas. Mais ceci relève plus de fr.comp.applications.sgbd


a++;
JG

Jerry Khann <jerry_O_khann@freesurf.fr.invalid> wrote:

1- La question "énervante" initiale, répondait à une rumeur
que j'entends de ci de là, comme quoi Php+MySql c'est bien
pour des "petites" applications et des "petites" bases,
mais qu'ils trouvent vite leur limites.

Je t'assure qu'on peut aussi faire des grosses applications en php/mysql
:)

--
Romuald Brunet, ICQ 33033393, http://mog.online.fr

Remplacez nospam par mon prénom pour me contacter par email