Discussion :

[ricozor]

Bonjours,

je voudrait savoir quelle est la limite du nombre d'objet dans un site ezpublish

je m'explique:

je dois faire un site touristique sur ez qui va comprendre en moyenne 5000 objets touristiques (restaurants, hôtels, camping, bars, agenda, évènements...) dans chaque langue.

Chaque objets pourra contenir plusieurs images et d'autres sous éléments.

si on compte 10 sous éléments de moyenne par objet touristique et 5 langues on arrive à 5000 x 5 x 11 soit 275 000 éléments et sous éléments
ça commence à faire beaucoup.

j'ai fais la semaine dernière, sur un serveur linux, un teste de charge en chargeant 80 000 objets Touristiques factices + 2-3 sous éléments par objets ce qui fait ~200 000 éléments et sous éléments.
j'ai utilisé data_import que j'ai modifié pour charger 80 000 xml plutôt que 1 seul, ça a mis plus de 2 jours pour faire mon import.

ma base de donnée MySQL pèse 5.1 Go (~26 millions d'enregistrements) dont 3.6 Go pour la table ezsearch_object_word_link (~22 millions d'enregistrements)

Ces chiffres me paraissent énormes.

A votre avis est-ce que une telle quantité d'objets ne risque pas de nuire au performances du site et à la stabilité du serveur ?

En vous remerciant.

Eric

[jeanvoye]

Salut Eric,

La taille de la DB est conséquente après ton test, mais reste un volume standard pour une installation eZ Publish. A ta question finale je réponds par d'autres, qui conditionneront l'architecture à mettre en place autour de la plateforme de publication web :

• Quels pics de fréquentation penses tu devoir supporter (utilisateurs simultanés)
• Quelle sera la part de navigation personnalisée (en mode connecté)

Voici une présentation proposée au eZ Day Paris vendredi dernier, traitant justement des performances en cas de forte volumétrie de contenus, et présentant des solutions : http://t.co/LL6hE7Gi

A titre indicatif, l'après-midi eZ Community fut fort intéressante, le récit et lien vers les slides ici :
http://share.ez.no/blogs/ez/communit...th-the-wrap-up
--
Nicolas

[ricozor]

Bonjour Nicolas,

merci pour les liens je vais prendre le temps de les regarder.

Concernant les chiffres demandés :
- nombre d'utilisateurs connectés simultanément : 2-3 (il y que l'admin + 2-3 éditeurs)
- pic de fréquentation (nombre d'utilisateurs simultanés) je n'ai que je pic de fréquentation sur une journée pour l'instant ~8000, ça serait plus parlant sur une heure, je suppose, et je ne sais pas si google analytique peu remonter les pic d'utilisateurs silmultané

par contre j'ai fait des teste de charge en local avec 2 serveurs
1 serveur qui fait office d’hébergeur, un autre qui fait se simulateur d'utilisateurs) j'utilise Pylot pour cela.
Ce qui me permet de faire monter le site en charge jusqu’à 200 utilisateurs simultanés sur une période de 600s.
Jusqu’à 150 utilisateurs simultanés sur 600s ça marche encore par contre le temps de réponse par page commence à être long 30-40s
à 200 utilisateur simultané sur 600s j'ai 150 erreurs

je fait ces testes sur 10 pages du sites avec les caches activés, si je désactive les caches j'ai bien sûre des temps de réponse plus long et les erreurs commencent à 150 utilisateurs sur une période de 600s

je sais que le serveur local qui fait office d’hébergeur test n'est pas très performant donc on peu s'attendre à des temps de réponse plus rapide sur le serveur de prod.

Est-ce que ces chiffres apportent plus de précisions ?

En te remerciant

Eric

[jeanvoye]

Bonjour Eric,

Il semble donc que la navigation ne se fasse que de manière anonyme, cela ouvre des portes quant à la conception de l'architecture. Le premier point clé (dans toutes les conceptions et développements eZ Publish que tu pourras faire) est de s'assurer que les caches, et notamment le ViewCaching (cache de vue, plus d'infos : http://doc.ez.no/eZ-Publish/Technica...s/View-caching ) sont activés systématiquement.

Lorsque la navigation est anonyme, un reverse proxy tel que Varnish permet de simplifier drastiquement l'architecture hosting. Sur le portail share.ez.no, qui supporte environ 1700 visites par jour et 7000 PVs, est propulsé par un seul serveur aux caractéristiques matérielles modernes mais standards (pas un quadruple quad-core). Sa charge moyenne s'élève à 0.2 (!!) et Varnish sert, avec un temps de réponse fantastique, quasiment l'intégralité des requêtes. C'est sans compter qu'une bonne partie des éléments de la page sont personnalisés, c'est à dire varient suivant si la personne est connectée ou pas, et se personnalisent par compte connecté (fait avec de l'ajax principalement).

La clé lorsqu'un reverse proxy tel que Varnish est utilisé est de bien synchroniser la gestion des caches de contenu eZ Publish avec le cache Varnish. Une extension récemment mise à disposition sur eZ Market permet cela : eZ Accelerator ( http://ez.no/market/eZ-Accelerator ). D'autres intégrations existing, disponibles sur la forge communautaire : http://projects.ez.no/content/advanc...hButton=Search (clique sur les liens de type "Project").

J'espère t'avoir donné des pistes de réflexion.