Zend FR

Pour l'instant, je n'ai pas eu l'occasion de réaliser des benchmarks ou des tests de charge mais il est déjà clair que la mémoire utilisée est importante. Pour moi, c'est le prix de l'efficacité. Tu peux coder un site en utilisant les fonctions PHP de base et utiliser 100k de RAM. Plus on tend vers l'automatisation et simplification des processus de développement, plus les ressources sont mises à rude épreuve. Egalement, la sécurité tient une grande place dans cette consommation.

Par contre, l'optimisation mémoire est assez facile. Par exemple, on peut mettre des clauses WHERE à nos requêtes ce qui épargnera également pas mal de bande passante. Ou alors utiliser divers outils de mise en cache comme memcache : http://fr.php.net/memcache ou http://www.danga.com/memcached

Egalement, il y a des classes Zend à ne surtout pas utiliser en boucle comme Zend_Date qui fera tomber les performances de tes pages de manière astronomique.

Dès que j'ai des benchmarks, je reviendrai par ici !

Je reviens un peu sur ce que j'ai dit. Je me retrouve aujourd'hui dans une situation un peu délicate sur un développement avec ZF.

Une application client que j'ai développée a d'énormes problèmes de mémoire. Le serveur a un "memory_limit" de 16M, or, dans une page qui affiche pas mal de données, cette limite est dépassée et donc il y a un crash.

Quand j'analyse un peu le chargement de la page je remarque que les données en elle même ne font que 1M mais qu'à l'arrivée dans le contrôleur d'action, il y a déjà presque 9M de consommé par Zend.

En poussant un peu plus loin j'obtiens des chiffres qui me font un peu peur, à titre d'exemple :

Zend_Date    2.6M
Zend_Db    876k
Zend_Cache    470k
Zend_Acl    461k
Zend_Layout    288k
...

Ca fait un total de 4.7M uniquement pour initialiser ces classes sans même les utiliser. Aucune donnée n'est chargée jusque là.

Pire encore, de l'initialisation de ma configuration jusqu'à routeStartup(), uniquement du code interne est exécuté. Ce code consomme 1.5M de mémoire.

Bien entendu, en supprimant Zend_Date, je pourrais déjà gagner pas mal mais est-ce que ça va me solutionner le problème ou le repousser à un peu plus tard ?

J'en viens presque à me dire que Zend Framework est une usine à gaz. Que les piètres performances de chargement ne m'étonne guère étant donné la lourdeur du code. Et qu'il ne faut en tout cas pas utiliser ce framework sur des sites à haute charge.

Je dois justement évaluer si le développement d'un site à haute charge se fera sur ZF. Pour l'instant, j'ai presque envie de passer sur CodeIgniter ou Kohana.

Qu'en pensez vous ? Avez-vous développé des sites à haute charge (50'000 à 100'000 utilisateurs) sur ZF ?

Effectivement, ça coûte toujours moins cher d'acheter même 16Go de RAM plutôt que de passer 2 semaines à optimiser un code. Mais disons que j'ai l'impression de cacher la poussière sous le tapis. Surtout qu'avec 50 à 100k utilisateurs, on ne parle pas de 20 accès concurrents mais plutôt 200 voire 2000, dépendant des timezones et des pics d'accès.

Ce que je pense est à déterminer également, c'est quelles parties de ZF font gagner du temps de développement ? Le controller frontal ? Le MVC ? Zend_Db ? Est-ce que ces classes sont uniques ou peuvent-elles être remplacées par d'autres qui consomment moins de mémoire ?

Si je prends l'exemple de Kohana, il propose certainement un contrôleur frontal et un modèle MVC mais pas pour autant d'accès Db autant simple que ZF. Mais rien n'empêche d'importer Zend_Db et l'utiliser en standalone. Quel est le bon choix ? Grande question...

D'ici là, j'ai commandé des "vrais" benchmarks. Je pense pas que je pourrais les publier mais j'en ferai sûrement un petit article.

Merci pour ces chiffres, c'est indicatif mais intéressant quand même.

Donc, calculé à la rache, vous avez environ 800 à 1000 utilisateurs uniques. Si on compte, dans mon cas, 50'000 utilisateurs uniques, ça fait 50x plus, donc 0.11 * 50 = 5.5 accès concurrents.

C'est probablement complètement faux étant donné le type de contenu et le public type complètement différent. Mais ça donne un ordre de grandeur. Je vais voir ce que donne les benchmarks.

C'est étonnant autant peu d'accès concurrents quand même. Bien que sur un forum, on puisse s'attendre à avoir plus de consultation plutôt que du requêtage frénétique.

philippe a écrit:

Bonjour,

Mais supposons que tu aies 50Mo utilisés par process et un serveur qui peut allouer 1Go à ton apache, ça te fait 20 utilisateurs simultanés. Si on considère que ta page répond en 1s, et si on considère que ton trafic est sur 10h, ça te permet d'absorber le trafic suivant :
20*3600*10 = 720 000 pages vues / jour (à la grosse louche)


A+, Philippe

720 000 pages vues cela me semble très correct, mais si c'est fort probable qu'il y ai plus de 20 utilisateurs simultanés non?


Sujet très très intéressant au passage

Donc en gros, si j'ai bien compris,  si ma page prends 0.1sec à se charger il faut compter le nombre d'utilisateurs simultanés qui demanderont une page dans ces 0.1 sec.

En effet ça laisse un peu de marge !

Cordialement,
Kaimite

Salut,

Celà dépend essentiellement du temps de réponse d'une page.

20 accès concurrents c'est quand même déjà pas mal.

Quand on parle d'accès concurrents il s'agit du nombre d'utilisateurs simultanés qui chargent la même page au même moment.

Kaimite a bien saisi le truc.

Comme le précise philippe, si une page est longue à se charger, celà augmente les chances de générer des accès concurrents et donc de multiplier le nombre de process simultanés et donc la mémoire utilisée.

L'optimisation n'est donc pas uniquement en mémoire, mais aussi bien dans le code. Une uzine à gaz n'est générée que par la complexité du code et le temps de réponses des pages/scripts. Le fait que Zend bouffe de la mémoire sur un process n'est pas très important, c'est surtout pendant combien de temps le process reste en vie qui est important. De plus, les nouveaux serveurs possèdent la plupart du temps 4go de ram, ce qui laisse de la marge.


A+ benjamin.

Dernière modification par Delprog (04-03-2009 11:32:44)

Oui je voudrais ajouter aussi que lorsqu'on propose des services qui doivent générer un trafic assez énorme, tout ne doit pas reposer sur une seule machine. Il existe des solutions, entre autres, le load-balancing (répartition de charges) qui permet d'assurer un service viable quelque soit la charge.

A+ benjamin.

Si tu n'as pas d'accélérateur (genre APC) ça peut prendre pas mal de ressources CPU pour les recompilations des scripts. Je peux pas te donner plus d'info, j'ai APC sur toutes mes machines.

Si tu as APC installé, oui, je dirais que c'est la RAM le plus gros impact (je te dis ça au nez, je n'ai jamais fait de tests poussés dans le domaine).

A+, Philippe

Quand on parle d'accès concurrents il s'agit du nombre d'utilisateurs simultanés qui chargent la même page au même moment.

Non, on parle pas forcément d'accès concurrents à la même page, mais d'accès concurrent au serveur web. Donc potentiellement une multiplication de la consommation mémoire dû à la multiplication des processes. Ces processes sont générés peu importe la page chargée.

J'ai déjà atteint 2000 connexions concurrentes.

Sur un site développé avec ZF ? Si c'est pas indiscret, tu as quoi comme configuration pour supporter ça ?

De toute façon, dans 95% des cas, la base de données va ramer avant Apache.

Bah non, pas forcément, on a vu que des classes comme Zend_Date explosent la consommation de mémoire sans faire aucune requête SQL. En l'occurrence, l'utilisation de ZF fait baisser les 95% proposé à 50% à mon avis.

Mais il est clair qu'au niveau de l'optimisation du temps de réponse, l'accès à la base de données est plus lent que le reste et donc prioritaire...

J'ai parlé de même page pour prendre un exemple.

Alors dans ce cas : X visiteurs qui utilisent l'application simultanément = X accès concurrents

Non c'est plutôt X visiteurs dont les scripts auquels ils accèdent sont en train de se charger en même temps et ont donc chacun un process en mémoire.

Si 100 personnes sont sur ton site, et que tu as 100 accès concurrents, tu peux jouer au loto desuite. D'où l'intérêt d'avoir des temps de réponse rapides. Plus une page est rapide à se charger, moins de temps le process reste en vie et moins il y a de chances pour se retrouver avec plusieurs process en même temps et multiplier donc la charge mémoire.

Effectivement c'est souvent les accès concurrents à la BDD qui posent problème en premier. Après c'est aussi et souvent une conf du moteur qui est bloquant plus qu'un overload, de la prévention quoi.

Avec une base bien construite, en s'autorisant quelques optimisations moins scolaires pour diminuer les accès, des index biens placés et des ré-indexation régulières, en général ça le fait bien.


A+ benjamin.

Dernière modification par Delprog (04-03-2009 14:22:42)

Pour continuer un peu dans notre quête d'un framework "rapide", j'ai testé hier XDebug qui permet l'analyse complète de l'arbre d'exécution du code. C'est vraiment utile et très facile à mettre en place ! J'ai pour l'instant testé que sur un projet de moindre ampleur mais ai pu détecter que les goulets d'étranglement ne sont pas toujours là où on croit.

L'article en question :
http://www.wowww.ch/index.php?post/2009 … vec-XDebug

Egalement, pour les benchmarks, il s'avère que la mémoire est en fait un moindre problème. Après pas mal de tests, le plus gros problème sur un site à haute charge est que le CPU part en vrille très rapidement ce qui rallonge les temps de chargement. A partir d'une centaine de connexions concurrentes, le temps de chargement devient presque exponentiel et ce bien avant que la mémoire se retrouve saturée ou que la base de données soit surchargée.

Dans d'autres applications, sans framework, on avait constaté que la base de données était le goulet, mais avec ZF la tendance est inversée ce qui est particulièrement étonnant.