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!

[Yogui]

Quand tu fais "Back" avec ton navigateur, normalement il n'y a pas besoin de recharger toute la page puisque le navigateur l'a déjà mise en cache.

[GrandFather]

Je crois que je dois modifier pas mal de code pour arriver à optimiser tout ça.

L'erreur serait de commencer une quelconque optimisation avant d'avoir obtenu quelques mesures objectives des performances de ton application. Si ça se trouve, ton matériel est suffisamment dimensionné pour la charge, et tu n'auras que quelques aménagements mineurs à faire dans ton code.

Il faut de toutes façons cantonner l'optimisation au strict minimum nécessaire, car elle a pour effet pervers de rendre le code moins lisible et d'altérer la maintenabilité. Selon mon expérience, le goulet d'étranglement des applications Web (et souvent Desktop) est la base de données ; c'est sur elle que tu devrais porter, à mon avis, l'essentiel de tes efforts. En second lieu, la mise en place d'un cache d'opcode peut t'épargner un refactoring de ton application.

[whitespirit]

C'est pas bête ce que tu dis GrandPère !!

Selon mon expérience, le goulet d'étranglement des applications Web (et souvent Desktop) est la base de données

Selon toi, utiliser des vues et procédures stockés seraient un atout dans mon optimisation. Bon le hic c'est que d'un point de vue théorique je sais à quoi ça sert, mais maintenant qu'est ce que je vais mettre dedans ? Tu pourrais me donner un petit exemple (au pire je me déplacerai sur un forum approprié mais ton "expérience" pourrait me faire gagner beaucoup de temps) ?

Si tu me parles de ça ici, c'est que je n'aurai pas de problème pour utiliser ces éléments liés à Mysql (vue et proc. stockées) dans ZF, on est d'accord?

[Yogui]

Selon toi, utiliser des vues et procédures stockés seraient un atout dans mon optimisation. Bon le hic c'est que d'un point de vue théorique je sais à quoi ça sert, mais maintenant qu'est ce que je vais mettre dedans ? Tu pourrais me donner un petit exemple (au pire je me déplacerai sur un forum approprié mais ton "expérience" pourrait me faire gagner beaucoup de temps) ?

Voici : http://alain-defrance.developpez.com...D/contraintes/
http://g-rossolini.developpez.com/tu.../partager-bdd/

[GrandFather]

Si tu me parles de ça ici, c'est que je n'aurai pas de problème pour utiliser ces éléments liés à Mysql (vue et proc. stockées) dans ZF, on est d'accord?

Absolument, et c'est d'ailleurs ma pratique quotidienne de ZF. J'utilise PostgreSQL plutôt que MySQL, mais le principe est le même, les vues et procédures stockées sont "vues" côté PHP comme des tables en lecture seule(1). Ces vues et procédures stockées sont compilées côté serveur, et s'exécutent bien plus rapidement que si leur code SQL devait être évalué à chaque requête par le SGBDR.

Il y a bien d'autres actions sur les bases pouvant avoir un impact positif sur les performances, comme (liste non exhaustive) :

• Placer des indexes sur les clés étrangères
• Dénormaliser certaines tables pour supprimer des jointures coûteuses
• Spécifier les champs à renvoyer par la requête plutôt qu'utiliser le caractère joker *

Pour aborder des projets d'application à fort trafic et/ou avec un gros volume de données, il est à mon avis nécessaire de s'adjoindre les services d'un DBA, ou à défaut d'avoir quelques connaissances en matière de design et de tuning de base.

(1) Il existe dans Postgres un système de règles basées sur la réécriture SQL permettant de rendre modifiables des vues (en apparence seulement, en fait la requête insert ou update sur la vue est réécrite en requêtes SQL équivalentes sur les tables constituant la vue), mais c'est une utilisation avancée et qui a le défaut d'être liée à un SGBDR particulier.

[trashyquaker]

[*]Dénormaliser certaines tables pour supprimer des jointures coûteuses

Bonjour,
Ca m'interesserait aussi d'optimiser mes applications.
Est ce que celà veut dire, par exemple:

Si j'ai une table "utilisateur" (codeUser, nomUser, codePays) et une table "pays" (codePays, nomPays), je ferais mieux de changer ma table "utilisateur" en (codeUser, nomUser, codePays, nomPays) afin d'éviter les jointures avec la table "pays". Quitte à mettre à jour les 2 champs (codePays et nomPays) à chaque update?

J'avais pensé à le faire mais je n'ai jamais osé... Les jointures sont vraiment toutes couteuses ou seulement certaines?

[Yogui]

Attention, toute dénormalisation doit être extrêmement limitée, contrôlée par des opérations automatiques (triggers par exemple) et mesurée (perte en volume de données).

Dès que tu dénormalises la base, tu créés de la redondance, donc une complication de mise à jour et une perte d'espace disque, donc aussi une perte de performances (plus gros volume de données donc temps de recherche plus élevé).

GrandFather parlait de dénormalisation sous certaines conditions, ce n'est pas quelque chose qui peut être fait en 2 minutes à la lecture d'un tuto, c'est le travail d'un véritable DBA connaissant intimement le système de l'entreprise considérée.

Et je vous prie de concentrer vos remarques sur les performances de Zend Framework. Les autres questions ou réponses, aussi intéressantes soient-elles, ont leur place ailleurs dans les forums

[arthak]

Bonjour,
Ca m'interesserait aussi d'optimiser mes applications.
Est ce que celà veut dire, par exemple:

Si j'ai une table "utilisateur" (codeUser, nomUser, codePays) et une table "pays" (codePays, nomPays), je ferais mieux de changer ma table "utilisateur" en (codeUser, nomUser, codePays, nomPays) afin d'éviter les jointures avec la table "pays". Quitte à mettre à jour les 2 champs (codePays et nomPays) à chaque update?

Les jointures dont tu parles sont des jointures utiles, et même pour seulement conserver la pérennité de ta base de donnée, ton schéma semble approprié.

[whitespirit]

Merci pour vos réponses, derrière vos pseudos se cachent des bibliothèques de connaissances !!!!

Encore une chose :

- Pourquoi avoir choisi Postgre plutôt que MySQL ? Est-ce que tu n'as pas de problèmes de mise à jour entre les versions ?

Entre temps je vais clôturer ce post et l'ajouter précieusement car vous avez répondu à toutes mes attentes. Pour l'instant je vais d'une part orienter mes recherche sur les "stress test" et leur fonctionnement et d'autre part sur l'optimisation de ma base de données.

Toutefois je suis très malheureux car je me rends compte qu'il me manque encore une compétence majeure à appréhender : l'optimisation de base de données. J'espère que vous avez tous entre 50-70 ans pour être aussi pointu sur des sujets diverses et indispensable, et j'oserai espérer avoir atteint le niveau du Jedi suprême ! Le plus impressionnant c'est de combiner toutes ces compétences et connaissances !!

Bon un grand merci à tous ceux qui ont participer à ce post (malgré qu'il soit fermé, je suis toujours preneur de liens ou de nom d'outils concernant ce domaine).

Aurevoir.

PS: je viens de voir ce simley il fallait que je le mette qq part, sorry

[Yogui]

PostgreSQL est connu pour avoir davantage de fonctionnalités que MySQL (fonctions directement en SQL, types, plus grand respect de la norme SQL-92, etc.), mais peut-être moins d'outils pour l'utiliser (outils externes). De son côté, MySQL incorpore certains aspects fondamentaux des SGBD (triggers, vues, sous requêtes, intégrité référentielle) depuis peu de temps et ses moteurs de stockage ne cessent de changer, ce qui n'aide ni sa maturité ni sa popularité.

PostgreSQL est moins connu car il n'y a pas d'entreprise derrière, du moins pas au même titre que MySQL AB et maintenant Sun (avec le soutien de Wikipedia, Google...). Bref, il n'y a pas le même budget publicitaire derrière PostgreSQL et MySQL.

[GrandFather]

Pour continuer dans le H.S. (désolé Yogui ) :

Pourquoi avoir choisi Postgre plutôt que MySQL ? Est-ce que tu n'as pas de problèmes de mise à jour entre les versions ?

Pour le choix de PostgreSQL plutôt que MySQL, ce sont pour tous les motifs cités par Yogui ; et encore, à l'époque où j'avais fait l'évaluation des deux (2001), la différence était encore plus marquée (en défaveur de MySQL). Pour ce qui est des changement de versions, j'ai migré 130 tables et des dizaines de procédures stockées de PostgreSQL 7.3 à 8.1 avec juste quelques modifications mineures, portant généralement sur des choses mal codées à la base et rejetées par la version la plus récente, plus restrictive.

Toutefois je suis très malheureux car je me rends compte qu'il me manque encore une compétence majeure à appréhender : l'optimisation de base de données.

Entendons-nous sur les termes : en guise d'optimisation je n'ai fait que mentionner quelques recettes simples et règles de bon sens qui valent pour la majorité des SGBDR et pour des applications de petite et moyenne taille, et qui sont accessibles à la quasi-totalité des développeurs sans pour autant devenir un dieu des bases de données... Pour du "lourd", des bases complexes de plusieurs tera-octets avec beaucoup de connexions et de transactions, il faut les compétences d'un vrai DBA.

Désolé pour cette digression sur les bases de données, mais c'était pour relater une conviction personnelle qui a été rarement démentie par les faits (selon mon expérience) : en cas de soucis de performances d'une application Web, les premiers soins sont à apporter à la base de données plutôt que de se lancer dans des micro-optimisations du code PHP.

[Rakken]

Je n'ai jamais utilisé le Zend Framework et je ne sais pas a quel point il est gourmand, mais d'après mon expérience personnelle, tant que tu ne fais pas des calculs de folie a chaque fois qu'un utilisateur se connecte, 50 users minute (on peut arrondir a 1 par seconde en moyenne), ca reste franchement raisonnable et tu ne devrait pas avoir a t'inquieter d'optimiser particulièrement ton code.
Attention, je n'ai pas dit que tu pouvais coder comme un porc hein ! juste que tant que tu fais les choses proprement, sans optimisation spécifique, tu ne devrais pas avoir de soucis de perf. Et si jamais c'est le cas, alors seulement, il faudra que tu t'en préocupe. Vu le nombre de connexion, optimiser "par avance" va te causer plus de problème qu'autre chose, pour un gain qui risque d'être inutile.