Discussion :

[whitespirit]

Bonjour et bon lundi,

Je sais que ma question n'est pas bien posé, donc je vais détailler mon souci et la reformuler. J'ai développé grâce à ZF une plate-forme utilisant le module ZF Zend_Auth et Zend_Acl permettant ainsi de gérer des droits d'accès et une authentification.

Pour un projet futur je dois assurer la possibilité de créer 200 utilisateurs actifs continuellement et les utilisateurs qui seront non actifs (un type d'utilisateur pourra se connecter 1semaines-1mois environs) sera archivé. Bref par mois, j'aurai environs 500 utilisateurs qui pourront se connecter à ma plate-forme (pas simultanément, mais au moins 50 connexions simultanés min).

Mes questions sont :
- Quels vont être les conséquences sur ma gestion d'ACL d'avoir autant de connexions simultanéments ?
- Que dois-je prévoir pour que mon système se ne ralentissent pas
- Au niveau de la base de données, je vais avoir des gigas et des gigas, est-ce que je dois mettre en oeuvre des mécanismes particuliers ?
- Est-ce que le fait d'avoir autant de connexions demandes une technologies particulières ?

Je dois répondre à ce besoin, et je n'ai jamais travaillé sur qq chose aussi gros. Donc je flippe un peu. Tous les commentaires seront les biens venus.

Merci

[GrandFather]

Bonjour,

- Quels vont être les conséquences sur ma gestion d'ACL d'avoir autant de connexions simultanéments ?

Evidemment, les ACL ont un impact sur les performances, à toi de le minimiser en les réduisant au strict nécessaire. Le système d'ACL de ZF met en oeuvre des rôles et des ressources, dont le nombre est en principe lié à celui des fonctionnalités de ton application, pas celui des utilisateurs. Donc, à moins d'avoir une gestion très particulière des ACL impliquant la création d'un rôle spécifique à chaque utilisateur, pas de crainte particulière à avoir.

- Que dois-je prévoir pour que mon système se ne ralentissent pas

Prévoir une étape de profiling en fin de développement et installer un cache d'opcode.

- Au niveau de la base de données, je vais avoir des gigas et des gigas, est-ce que je dois mettre en oeuvre des mécanismes particuliers ?

Là, on rentre dans le domaine des DBA.
Ca dépend en grande partie de la base que tu utilises ; d'une manière générale, il faudra déplacer les requêtes "complexes" (impliquant beaucoup de jointures internes ou externes) de l'application vers le SGBDR, en les créant sous formes de vues (compilées) ou de procédures stockées. A l'extrême, il est possible que tu sois obligé de renoncer au confort apporté par l'ORM de ZF pour accéder à la base directement avec l'API PHP correspondante.

- Est-ce que le fait d'avoir autant de connexions demandes une technologies particulières ?

Des technologies particulières, non. Par contre un serveur bien configuré, avec de la mémoire, et une utilisation rationnelle du framework me semblent incontournables.

Je dois répondre à ce besoin, et je n'ai jamais travaillé sur qq chose aussi gros.

Pour en avoir le coeur net, mets en place assez rapidement et en cours de développement des "stress tests", il existe des tas d'outils te permettant de simuler des connexions multiples et avoir une idée de la façon dont se comporte le système avec une forte charge .

[whitespirit]

Merci d'avoir répondu avec autant de précision à mon post.

Je fais un retour de ce que j'en tire comme conclusion :

Est-ce que le cache d'opcode est un élément indépendant de ZF ? Faut-il implémenter une gestion particulière ou bien je fonctionne avec un "bon sens", c'est à dire je met en cache les informations connues pendant une durée T ?

J'utilise actuellement MySQL comme SGBD, est-ce que c'est un bon choix ? Je vais me documenter sur la gestion des vues, procédures stockées (si ça existe déjà sur MySQL). J'espère toutefois ne pas avoir à me passer de l'ORM de ZF.

Je n'ai pas compris ce que tu veux dire par "Stress Test"... Ca m'a fait beaucoup rire. J'ai même penser à "Sucide Test" si jamais je ne m'en sors pas. Peux tu me conseiller sur des outils permettant de simuler une charge forte ?

Je suis prenant de tous types de commentaires, de liens...

[Yogui]

Salut

Il faut garder à l'esprit que le plus efficace est de se tenir au principe "graceful degradation", c'est-à-dire d'utiliser chaque technologie uniquement pour son point fort. Cette utilisation des technologies permet une programmation par couches, et ainsi de laisser à chacune le soin d'optimiser ses propres traitements.

Un exemple : Utilise PHP pour le dynamisme, utilise le SGBD pour la recherche de données, réduis autant que possible les échanges entre PHP et ton SGBD (ce qui suppose un maximum de procédures stockées), réserve JS et CSS pour ce qu'ils font de mieux, etc.
Voici un très bon exemple minimaliste par Google : http://feeds.feedburner.com/~r/blogspot/amDG/~3/287117148/design-patterns-for-accessible.html

Cela te permet d'utiliser un système de cache à chaque niveau :

• Le SGBD (côté SGBD)
• PHP (PDO)
• PHP (opcode)
• PHP (pages générées)
• N'oublie pas les en-têtes pour la mise en cache du navigateur
• Apache peut être utile également
• etc.

Le principe général étant de répondre au client le plus tôt possible dans le traitement de la requête, donc le plus proche possible d'Apache et surtout avant d'atteindre le SGBD.

Voici un excellent (court) exposé sur les méthodes et les outils qui peuvent t'être utiles : http://devzone.zend.com/article/3150...t-Environments

Sans oublier bien sûr l'amélioration des performances de ZF lui-même : http://www.developpez.net/forums/sho...d.php?t=553692


[Edit] "stress-test" = test de charge.
C'est simplement un outil qui envoie plusieurs milliers de connexions simultanées, et qui les renvoie pendant une certaine durée, afin de voir comment le serveur répond à une montée en charge. Tu peux le faire avec Apache Bench (voir les liens ci-dessus), mais un framework de test est plus intéressant à ce niveau afin de simuler une session de navigation standard.

[arthak]

A la place d'apache j'opterais pour le nouveau petit venu Nginx qui sert depuis ces dernières années les plus gros sites de prod web2.0 et qui consomme bien moins (en ram) qu'Apache.

[whitespirit]

Merci pour ces commentaires. Bon, mon premier développement web et développement ZF date de Février 2008 !! Je ne m'étais pas du tout soucier du cache (mon problème étant la compréhension du ZF). Je crois que je dois modifier pas mal de code pour arriver à optimiser tout ça. Le positif c'est que j'ai toutes les cartes en mains (bon, faudra vraiment que je me penche sur cette histoire de cache, car je vois bien que c'est la clé de l'optimisation).

Par contre, un élément que je n'ai pas compris :

N'oublie pas les en-têtes pour la mise en cache du navigateur

Tu voulais dire quoi par là Yogui ? Ca m'interpelle car ce qui ralenti le plus mon site, c'est le chargement du <head></head>, peut-être que ça n'a rien à voir (surtout le chargement du éditeur tel que tinymce).

Pour les procédures stockées, il faudrait que je m'y replonge dedans, je n'ai pas fait ça depuis des années, à l'époque sur Oracle.

Prochainement je testerai les outils cités dans ce post. Merci encore pour votre aide!