Optimisation de dépot dans Plone / GED

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Optimisation de dépot dans Plone / GED

Georges Mariano-2
Bonjour à tous,

Je profite d'un fonctionnement satisfaisiant d'un montage "plone /
ftp" (env ubuntu / gnome /nautilus) pour réaliser un dépôt "massif" de
docis sur une instance Plone (utilisée [un peu] comme GED)

Voici quelques éléments quantitatifs :

Taille globale : 280 Mo
Nbre de fichiers :  650

Là où ça coince un peu c'est ici :

Débit annoncé/mesuré par nautilus : 20 ko/s
Temps estimé : 2h30 (ça varie quand même dans le temps, estimation
"instantanée")

C'est pas tellement que le débit semble catastrophique, [si j'ai bien
compris] cela s'explique je pense par un fonctionnement synchrone du
dépot :

on transfert un fichier / il est indexé ./ on transfert le fichier
suivant / etc ...

en effet, htop ne me montre qu'une seule thread plone/ occupée à
convertir (wvware et cie)

Question : comment pourrait-on optimiser un peu ce genre de manip (nb
: la machine cible comporte 8 coeurs) MAIS tout en préservant une
manip user-friendly (à la drag-n-drop) ? [ce sera le boulot de
personnel administratif pas de geek barbus]

Merci
--
jabber:[hidden email]
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation de dépot dans Plone / GED

Gilles Lenfant-2

Le 24 mars 2011 à 17:28, Georges Mariano a écrit :

> Bonjour à tous,
>
> Je profite d'un fonctionnement satisfaisiant d'un montage "plone /
> ftp" (env ubuntu / gnome /nautilus) pour réaliser un dépôt "massif" de
> docis sur une instance Plone (utilisée [un peu] comme GED)
>
> Voici quelques éléments quantitatifs :
>
> Taille globale : 280 Mo
> Nbre de fichiers :  650
>
> Là où ça coince un peu c'est ici :
>
> Débit annoncé/mesuré par nautilus : 20 ko/s
> Temps estimé : 2h30 (ça varie quand même dans le temps, estimation
> "instantanée")
>
> C'est pas tellement que le débit semble catastrophique, [si j'ai bien
> compris] cela s'explique je pense par un fonctionnement synchrone du
> dépot :
>
> on transfert un fichier / il est indexé ./ on transfert le fichier
> suivant / etc ...
>
> en effet, htop ne me montre qu'une seule thread plone/ occupée à
> convertir (wvware et cie)
>
> Question : comment pourrait-on optimiser un peu ce genre de manip (nb
> : la machine cible comporte 8 coeurs) MAIS tout en préservant une
> manip user-friendly (à la drag-n-drop) ? [ce sera le boulot de
> personnel administratif pas de geek barbus]

Un cluster ZEO


>
> Merci
> --
> jabber:[hidden email]
> _______________________________________________
> Plone-FR mailing list
> [hidden email]
> https://lists.plone.org/mailman/listinfo/plone-fr

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation de dépot dans Plone / GED

Encolpe DEGOUTE
Le 25/03/2011 08:02, Gilles Lenfant a écrit :

> Le 24 mars 2011 à 17:28, Georges Mariano a écrit :
>
>> Bonjour à tous,
>>
>> Je profite d'un fonctionnement satisfaisiant d'un montage "plone /
>> ftp" (env ubuntu / gnome /nautilus) pour réaliser un dépôt "massif" de
>> docis sur une instance Plone (utilisée [un peu] comme GED)
>>
>> Voici quelques éléments quantitatifs :
>>
>> Taille globale : 280 Mo
>> Nbre de fichiers :  650
>>
>> Là où ça coince un peu c'est ici :
>>
>> Débit annoncé/mesuré par nautilus : 20 ko/s
>> Temps estimé : 2h30 (ça varie quand même dans le temps, estimation
>> "instantanée")
>>
>> C'est pas tellement que le débit semble catastrophique, [si j'ai bien
>> compris] cela s'explique je pense par un fonctionnement synchrone du
>> dépot :
>>
>> on transfert un fichier / il est indexé ./ on transfert le fichier
>> suivant / etc ...
>>
>> en effet, htop ne me montre qu'une seule thread plone/ occupée à
>> convertir (wvware et cie)
>>
>> Question : comment pourrait-on optimiser un peu ce genre de manip (nb
>> : la machine cible comporte 8 coeurs) MAIS tout en préservant une
>> manip user-friendly (à la drag-n-drop) ? [ce sera le boulot de
>> personnel administratif pas de geek barbus]
> Un cluster ZEO

ou RelStorage

--
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation de dépot dans Plone / GED

yboussard@alterway.fr
In reply to this post by Gilles Lenfant-2
Avec un pound (webdav full support )
8 coeur = 8 zeoclient
A voir si ensuite les requetes webdav sont bien dispatchés entre les zeoclients.

Le 25 mars 2011 08:02, Gilles Lenfant <[hidden email]> a écrit :

Le 24 mars 2011 à 17:28, Georges Mariano a écrit :

> Bonjour à tous,
>
> Je profite d'un fonctionnement satisfaisiant d'un montage "plone /
> ftp" (env ubuntu / gnome /nautilus) pour réaliser un dépôt "massif" de
> docis sur une instance Plone (utilisée [un peu] comme GED)
>
> Voici quelques éléments quantitatifs :
>
> Taille globale : 280 Mo
> Nbre de fichiers :  650
>
> Là où ça coince un peu c'est ici :
>
> Débit annoncé/mesuré par nautilus : 20 ko/s
> Temps estimé : 2h30 (ça varie quand même dans le temps, estimation
> "instantanée")
>
> C'est pas tellement que le débit semble catastrophique, [si j'ai bien
> compris] cela s'explique je pense par un fonctionnement synchrone du
> dépot :
>
> on transfert un fichier / il est indexé ./ on transfert le fichier
> suivant / etc ...
>
> en effet, htop ne me montre qu'une seule thread plone/ occupée à
> convertir (wvware et cie)
>
> Question : comment pourrait-on optimiser un peu ce genre de manip (nb
> : la machine cible comporte 8 coeurs) MAIS tout en préservant une
> manip user-friendly (à la drag-n-drop) ? [ce sera le boulot de
> personnel administratif pas de geek barbus]

Un cluster ZEO


>
> Merci
> --
> [hidden email]
> _______________________________________________
> Plone-FR mailing list
> [hidden email]
> https://lists.plone.org/mailman/listinfo/plone-fr

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr


_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: Optimisation de dépot dans Plone / GED

toutpt
In reply to this post by Georges Mariano-2
Bonjour,

C'est assez difficile de réaliser ça de manière asynchrone et ça serait qd meme la meilleur solution ou d'essayer de répartir ça entre instance zope. Ca devrait être possible avec un balancer bien configuré.

L'import n'est à faire qu'une seule fois ?
Si c'est le cas, il faut privilégier un accès au serveur (ssh ou ftp ou encore un montage sshfs) et utiliser transmogrifier pour importer le contenu à partir du système de fichier dans un site Plone;

-- 
Regards / Cordialement,
JeanMichel FRANCOIS


Le 24 mars 2011 17:28, Georges Mariano-2 [via Plone (Regional forums)] <[hidden email]> a écrit :
Bonjour à tous,

Je profite d'un fonctionnement satisfaisiant d'un montage "plone /
ftp" (env ubuntu / gnome /nautilus) pour réaliser un dépôt "massif" de
docis sur une instance Plone (utilisée [un peu] comme GED)

Voici quelques éléments quantitatifs :

Taille globale : 280 Mo
Nbre de fichiers :  650

Là où ça coince un peu c'est ici :

Débit annoncé/mesuré par nautilus : 20 ko/s
Temps estimé : 2h30 (ça varie quand même dans le temps, estimation
"instantanée")

C'est pas tellement que le débit semble catastrophique, [si j'ai bien
compris] cela s'explique je pense par un fonctionnement synchrone du
dépot :

on transfert un fichier / il est indexé ./ on transfert le fichier
suivant / etc ...

en effet, htop ne me montre qu'une seule thread plone/ occupée à
convertir (wvware et cie)

Question : comment pourrait-on optimiser un peu ce genre de manip (nb
: la machine cible comporte 8 coeurs) MAIS tout en préservant une
manip user-friendly (à la drag-n-drop) ? [ce sera le boulot de
personnel administratif pas de geek barbus]

Merci
--
jabber:[hidden email]
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr



If you reply to this email, your message will be added to the discussion below:
http://plone-regional-forums.221720.n2.nabble.com/Optimisation-de-depot-dans-Plone-GED-tp6204770p6204770.html
To start a new topic under Plone - France, email [hidden email]
To unsubscribe from Plone - France, click here.








Reply | Threaded
Open this post in threaded view
|

Re: Optimisation de dépot dans Plone / GED

Georges Mariano-2
Le 25 mars 2011 09:56, toutpt <[hidden email]> a écrit :
> Bonjour,

Bonjour à tous,

Merci pour les pistes qui rejoignent +/- ce que je pensait ou craignait :P

Très rapidement, j'ai quelques réticences à empiler des outils
complémentaires (même puissants), après faut les gérer en sus  ...

> C'est assez difficile de réaliser ça de manière asynchrone et ça serait qd
> meme la meilleur solution

par curiosité, les difficultés seraient  où ?

>  ou d'essayer de répartir ça entre instance zope.
> Ca devrait être possible avec un balancer bien configuré.

oui, encore faut-il que la manip "clickodrome", engendre bien les n
requètes non ?
(actuellement, une méthode de contournement consisterait simplement à
suggérer de travailler en découpant la demande sur les
sous-répertoires...)

> L'import n'est à faire qu'une seule fois ?
> Si c'est le cas, il faut privilégier un accès au serveur (ssh ou ftp ou
> encore un montage sshfs)

ah... me semble pas avoir vu de doc reliant sshfs et plone ... ou
alors il y a autre chose dans la boucle ?

>  et utiliser transmogrifier pour importer le contenu
> à partir du système de fichier dans un site Plone;

encore une ref à transmogrifier, ... va falloir y regarder :P

A+
--
jabber:[hidden email]
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

zeoclients, threads et mémoire

martronic
In reply to this post by toutpt
Bonjour!

Nous avons quelques questions sur la configuration des zeoclients.

En général on lit "1 coeur = 1 zeoclient" mais peut-on attribuer 1 coeur
à 1 zeoclient? Si oui, comment le faire?


Egalement en question le nombre de threads:

Nous avons constaté que lorsque l'on attribue 2 threads ( dans le
buildout.cfg zserver-threads = 2 )en réalité il en crée 4 ou plus et
généralement ils ne sont pas tous utilisés. On constate que un des
threads, un deuxième un peu moins, éventuellement un troisième et les
autres ne sont jamais utilisés.

Les threads non-utilisés prennent une certaine place en mémoire.

Tout cela est multiplié par le nombre de zeoclients ce qui a comme
conséquence on forte utilisation de la mémoire (server avec 12 Go
disponible) et fini par causer un swap qui ralentit tout le système.

Bien-sûr tout cela est certainement influencé par le zodb-cache-size.

En frontal nous utilisons nginx avec répartition de charge.

Avez-vous des suggestions ou des éclaircissements?

Merci d'avance!

Martial Moret
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

yboussard@alterway.fr
Bonjour Martial,

Le 25 mars 2011 12:08, Martronic SA <[hidden email]> a écrit :
Bonjour!

Nous avons quelques questions sur la configuration des zeoclients.

En général on lit "1 coeur = 1 zeoclient" mais peut-on attribuer 1 coeur à 1 zeoclient? Si oui, comment le faire?
C'est le système d'exploitation qui doit géré cela suivant la charge. Ce n'est pas dépendant d'une conf au niveau du serveur d'application .


Egalement en question le nombre de threads:

Nous avons constaté que lorsque l'on attribue 2 threads ( dans le buildout.cfg zserver-threads = 2 )en réalité il en crée 4
Vérifier dans le zope.conf que la conf est bien répercuté car cela doit fonctionner.
Le plus simple pour vérifier cela est AMA de mettre 1 thread et de pousser un gros fichier dans la zodb. Normalement le serveur n'est plus accessible vu que le thread est occupé.
ou plus et généralement ils ne sont pas tous utilisés.
Heureusement car un zope dont tout les threads sont utilisés est un zope qui n'accepte plus de connection
On constate que un des threads, un deuxième un peu moins, éventuellement un troisième et les autres ne sont jamais utilisés.

Les threads non-utilisés prennent une certaine place en mémoire.
Les zodb cache sont par thread . Dans les conf il y a le nombre d'objet en cache. Il faut bien faire attention car cela est une configuration de cache par thread (voir le zodb_cache dans le control panel).
Donc peu de thread = cache moins disparate et on peu en mettre plus. Mais attention aussi à la dispo du serveur.
Il y a des nouvelles directive à ce niveau là si votre zodb est récente (taille max en mémoire autorisée)

Tout cela est multiplié par le nombre de zeoclients ce qui a comme conséquence on forte utilisation de la mémoire (server avec 12 Go disponible) et fini par causer un swap qui ralentit tout le système.

Bien-sûr tout cela est certainement influencé par le zodb-cache-size.
Voila. Mais pas seulement , les ramcache aussi et tout ce qui peut bouffer de la mémoire (styles les DateTimes).....

Youenn.
 

En frontal nous utilisons nginx avec répartition de charge.

Avez-vous des suggestions ou des éclaircissements?

Merci d'avance!

Martial Moret
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr


_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

Encolpe DEGOUTE
In reply to this post by martronic
Le 25/03/2011 12:08, Martronic SA a écrit :
Bonjour!

Nous avons quelques questions sur la configuration des zeoclients.

En général on lit "1 coeur = 1 zeoclient" mais peut-on attribuer 1 coeur à 1 zeoclient? Si oui, comment le faire?

C'est possible mais pas forcément conseillé.
Du fait de la présence d'un verrou global dans Python, un client zeo et tout ses threads vont toujours être ensemble sur le même core, mais le système peut choisir de les déplacer ensemble d'un core à un autre. Dans certains cas tous les clients ZEO vont être sur le même core et les autres vont se tourner les pouces.
La command 'schedtool' sous linux permet d'assigner à un programme un liste de cores sur lesquels il peut travailler.
L'autre solution est d'utiliser des machines virtuelles (XEN, VMWare,...) pour créer une machine virtuele par client ZEO. Malgré tout cela reste assez contre-productif au niveau de la maintenance.




Egalement en question le nombre de threads:

Nous avons constaté que lorsque l'on attribue 2 threads ( dans le buildout.cfg zserver-threads = 2 )en réalité il en crée 4 ou plus et généralement ils ne sont pas tous utilisés. On constate que un des threads, un deuxième un peu moins, éventuellement un troisième et les autres ne sont jamais utilisés.

Les deux premiers threads lancées sont des programmes de gestion de Zope, le deuxième dépendant du premier et le deuxième lançant les ZServer. La commande 'ps xf' permet de bien mettre ce point en évidence. Normalement seuls les deux threads 'ZServer' sont réellement sollicités dans votre configuration.
Les threads 'ZServer' utilisant le même adressage mémoire, plus ils sont nombreux plus il y a un risque de créer souvent des ConflictError dans la ZODB. C'est pour cela que par défaut le nombre de threads est à 2 dans la configuration ZopeSkel ou UnifiedInstaller de base. La configuration de base de Zope en lance 4 et conseille de ne pas dépasser 10. Dans la réalité, au delà de 7 threads par client le nombre de ConflictError est déjà très important et peu limiter les performances de la plateforme. C'est pour cela que l'on préconise de multiplier les clients ZEO plutôt que d'augmenter le nombre de threads.

Je conseille d'utiliser le répartiteur de charge HAProxy qui met à disposition une console web qui permet de suivre en direct l'évolution des tâches demandées à chaque client ZEO.

NGinx -> HAProxy -> Clients ZEO

Cordialement,
-- 
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

yboussard@alterway.fr


Le 25 mars 2011 13:24, Encolpe Degoute <[hidden email]> a écrit :
Le 25/03/2011 12:08, Martronic SA a écrit :
Bonjour!

Nous avons quelques questions sur la configuration des zeoclients.

En général on lit "1 coeur = 1 zeoclient" mais peut-on attribuer 1 coeur à 1 zeoclient? Si oui, comment le faire?

C'est possible mais pas forcément conseillé.
Du fait de la présence d'un verrou global dans Python, un client zeo et tout ses threads vont toujours être ensemble sur le même core, mais le système peut choisir de les déplacer ensemble d'un core à un autre. Dans certains cas tous les clients ZEO vont être sur le même core et les autres vont se tourner les pouces.
La command 'schedtool' sous linux permet d'assigner à un programme un liste de cores sur lesquels il peut travailler.
L'autre solution est d'utiliser des machines virtuelles (XEN, VMWare,...) pour créer une machine virtuele par client ZEO. Malgré tout cela reste assez contre-productif au niveau de la maintenance.





Egalement en question le nombre de threads:

Nous avons constaté que lorsque l'on attribue 2 threads ( dans le buildout.cfg zserver-threads = 2 )en réalité il en crée 4 ou plus et généralement ils ne sont pas tous utilisés. On constate que un des threads, un deuxième un peu moins, éventuellement un troisième et les autres ne sont jamais utilisés.

Les deux premiers threads lancées sont des programmes de gestion de Zope, le deuxième dépendant du premier et le deuxième lançant les ZServer. La commande 'ps xf' permet de bien mettre ce point en évidence. Normalement seuls les deux threads 'ZServer' sont réellement sollicités dans votre configuration.
Les threads 'ZServer' utilisant le même adressage mémoire, plus ils sont nombreux plus il y a un risque de créer souvent des ConflictError dans la ZODB. C'est pour cela que par défaut le nombre de threads est à 2 dans la configuration ZopeSkel ou UnifiedInstaller de base. La configuration de base de Zope en lance 4 et conseille de ne pas dépasser 10. Dans la réalité, au delà de 7 threads par client le nombre de ConflictError est déjà très important et peu limiter les performances de la plateforme. C'est pour cela que l'on préconise de multiplier les clients ZEO plutôt que d'augmenter le nombre de threads.
Salut Encolpe,
 
AMA multiplier le nombre de zeo n'est pas une solution meilleure qu'augmenter le nombre de thread au niveau des conflict error.
Il y a un zeoserveur, c'est le goulet du systeme , pas les threads ou les zeoclients. C'est de multiplier le nombre d'écriture en concurrence sur les même objets qui provoque des conflicts errors.
Je ne vois pas comment le zeoserveur résoudrait de maniere plus efficace les conflits d'ecriture d'un zeoclient avec 10 threads ou de deux zeoclients avec 5 thread. Au contraire  car en architecture zeo , le zeoserveur est a mon avis plus sollicité pour des charges égale sur les deux architectures (les 5 thread sont séparés, le système se débrouille pour tout le monde fonctionne ensemble).

Amicalement Youenn.


Je conseille d'utiliser le répartiteur de charge HAProxy qui met à disposition une console web qui permet de suivre en direct l'évolution des tâches demandées à chaque client ZEO.

NGinx -> HAProxy -> Clients ZEO

Cordialement,
-- 
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr



_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

Encolpe DEGOUTE
Le 25/03/2011 14:17, Youenn Boussard a écrit :


Le 25 mars 2011 13:24, Encolpe Degoute <[hidden email]> a écrit :
Le 25/03/2011 12:08, Martronic SA a écrit :



Egalement en question le nombre de threads:

Nous avons constaté que lorsque l'on attribue 2 threads ( dans le buildout.cfg zserver-threads = 2 )en réalité il en crée 4 ou plus et généralement ils ne sont pas tous utilisés. On constate que un des threads, un deuxième un peu moins, éventuellement un troisième et les autres ne sont jamais utilisés.

Les deux premiers threads lancées sont des programmes de gestion de Zope, le deuxième dépendant du premier et le deuxième lançant les ZServer. La commande 'ps xf' permet de bien mettre ce point en évidence. Normalement seuls les deux threads 'ZServer' sont réellement sollicités dans votre configuration.
Les threads 'ZServer' utilisant le même adressage mémoire, plus ils sont nombreux plus il y a un risque de créer souvent des ConflictError dans la ZODB. C'est pour cela que par défaut le nombre de threads est à 2 dans la configuration ZopeSkel ou UnifiedInstaller de base. La configuration de base de Zope en lance 4 et conseille de ne pas dépasser 10. Dans la réalité, au delà de 7 threads par client le nombre de ConflictError est déjà très important et peu limiter les performances de la plateforme. C'est pour cela que l'on préconise de multiplier les clients ZEO plutôt que d'augmenter le nombre de threads.
Salut Encolpe,
 
AMA multiplier le nombre de zeo n'est pas une solution meilleure qu'augmenter le nombre de thread au niveau des conflict error.
Il y a un zeoserveur, c'est le goulet du systeme , pas les threads ou les zeoclients. C'est de multiplier le nombre d'écriture en concurrence sur les même objets qui provoque des conflicts errors.

Le nombre de lecture peut aussi poser problème.

Je ne vois pas comment le zeoserveur résoudrait de maniere plus efficace les conflits d'ecriture d'un zeoclient avec 10 threads ou de deux zeoclients avec 5 thread. Au contraire  car en architecture zeo , le zeoserveur est a mon avis plus sollicité pour des charges égale sur les deux architectures (les 5 thread sont séparés, le système se débrouille pour tout le monde fonctionne ensemble).
Dans l'architecture ZEO le client qui s'apprête à écrire une donnée demande un verrou au serveur avant de travailler en local dans son cache (RAM ou disque). Le thread travaille dans son coin et les modifications sont propagées au serveur ZEO lorsqu'un autre client demande à lire la donnée. Le verrou posé est plus exlusif que le verrou local lorsque 2 threads travaillent avec la même mémoire.

En septembre dernier, avec un cluster de 20 clients de 2 threads répartis sur moins de cores (deux serveurs physiques qui hébergent 6 serveurs virtuels) nous avons réussi à écrire une série de données dans le même dossier pour 200 utilisateurs en concurence. Après se pose un autre problème : la taille de la bande passante effective entre le serveur ZEO et les clients ZEO.

Bon vendredi
-- 
Encolpe DEGOUTE
http://encolpe.degoute.free.fr/
Logiciels libres, hockey sur glace et autres activités cérébrales

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

Gilles Lenfant-2
In reply to this post by yboussard@alterway.fr
Hi,

En tout état de cause, le support des écritures massives et parallèles, d'autant plus s'il s'agit de fichiers, est l'un des points faibles de la ZODB.

S'il y a 20 auteurs qui font du drag'n'drop massif et quasi simultanément vers un site, j'imagine qu'il s'agit uniquement de la préparation de la mise en production du site, et non d'un cas d'utilisation quotidien d'un site Plone. Dans le cas contraire, Plone n'est pas la bonne solution, il serait préférable de s'orienter vers des outils plus orientés GED tels que AlFresco.

S'il s'agit uniquement de la préparation d'une mise en production, il est préférable de fournir un espace sur le serveur partagé avec Samba dans lequel les auteurs pourront placer les documents en masse par drag'n'drop puis de les faire distribuer par Plone :

* Soit par import en utilisant transmogrifier
* Soit en utilisant un outil tel que FRS pour explorer une hiérarchie de fichiers à travers Plone.

A noter qu'il doit être également "facile" de réaliser une passerelle Plone / Dropbox pour lequel un client Python est disponible.

https://www.dropbox.com/developers

Autre avantage de ces solutions  : on peut se permettre de faire l'économie d'une architecture de production "cluster" couteuse, délicate à mettre en place et exploiter, telles que suggérées par Youenn ou Encolpe

--
Gilles

Le 25 mars 2011 à 14:17, Youenn Boussard a écrit :

>
>
> Le 25 mars 2011 13:24, Encolpe Degoute <[hidden email]> a écrit :
> Le 25/03/2011 12:08, Martronic SA a écrit :
>> Bonjour!
>>
>> Nous avons quelques questions sur la configuration des zeoclients.
>>
>> En général on lit "1 coeur = 1 zeoclient" mais peut-on attribuer 1 coeur à 1 zeoclient? Si oui, comment le faire?
>
> C'est possible mais pas forcément conseillé.
> Du fait de la présence d'un verrou global dans Python, un client zeo et tout ses threads vont toujours être ensemble sur le même core,     mais le système peut choisir de les déplacer ensemble d'un core à un autre. Dans certains cas tous les clients ZEO vont être sur le même core et les autres vont se tourner les pouces.
> La command 'schedtool' sous linux permet d'assigner à un programme un liste de cores sur lesquels il peut travailler.
> L'autre solution est d'utiliser des machines virtuelles (XEN, VMWare,...) pour créer une machine virtuele par client ZEO. Malgré tout cela reste assez contre-productif au niveau de la maintenance.
>
>
>>
>>
>>
>> Egalement en question le nombre de threads:
>>
>> Nous avons constaté que lorsque l'on attribue 2 threads ( dans le buildout.cfg zserver-threads = 2 )en réalité il en crée 4 ou plus et généralement ils ne sont pas tous utilisés. On constate que un des threads, un deuxième un peu moins, éventuellement un troisième et les autres ne sont jamais utilisés.
>
> Les deux premiers threads lancées sont des programmes de gestion de Zope, le deuxième dépendant du premier et le deuxième lançant les ZServer. La commande 'ps xf' permet de bien mettre ce point en évidence. Normalement seuls les deux threads 'ZServer' sont réellement sollicités dans votre configuration.
> Les threads 'ZServer' utilisant le même adressage mémoire, plus ils sont nombreux plus il y a un risque de créer souvent des ConflictError dans la ZODB. C'est pour cela que par défaut le nombre de threads est à 2 dans la configuration ZopeSkel ou UnifiedInstaller de base. La configuration de base de Zope en lance 4 et conseille de ne pas dépasser 10. Dans la réalité, au delà de 7 threads par client le nombre de ConflictError est déjà très important et peu limiter les performances de la plateforme. C'est pour cela que l'on préconise de multiplier les clients ZEO plutôt que d'augmenter le nombre de threads.
> Salut Encolpe,
>  
> AMA multiplier le nombre de zeo n'est pas une solution meilleure qu'augmenter le nombre de thread au niveau des conflict error.
> Il y a un zeoserveur, c'est le goulet du systeme , pas les threads ou les zeoclients. C'est de multiplier le nombre d'écriture en concurrence sur les même objets qui provoque des conflicts errors.
> Je ne vois pas comment le zeoserveur résoudrait de maniere plus efficace les conflits d'ecriture d'un zeoclient avec 10 threads ou de deux zeoclients avec 5 thread. Au contraire  car en architecture zeo , le zeoserveur est a mon avis plus sollicité pour des charges égale sur les deux architectures (les 5 thread sont séparés, le système se débrouille pour tout le monde fonctionne ensemble).
>
> Amicalement Youenn.
>
>
> Je conseille d'utiliser le répartiteur de charge HAProxy qui met à disposition une console web qui permet de suivre en direct l'évolution des tâches demandées à chaque client ZEO.
>
> NGinx -> HAProxy -> Clients ZEO
>
> Cordialement,
> --
> Encolpe DEGOUTE
>
> http://encolpe.degoute.free.fr/
>
> Logiciels libres, hockey sur glace et autres activités cérébrales
>
>
> _______________________________________________
> Plone-FR mailing list
> [hidden email]
> https://lists.plone.org/mailman/listinfo/plone-fr
>
>
> _______________________________________________
> Plone-FR mailing list
> [hidden email]
> https://lists.plone.org/mailman/listinfo/plone-fr

_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr
Reply | Threaded
Open this post in threaded view
|

Re: zeoclients, threads et mémoire

Georges Mariano-2
Le 25 mars 2011 16:34, Gilles Lenfant <[hidden email]> a écrit :
> Hi,
>
> En tout état de cause, le support des écritures massives et parallèles, d'autant plus s'il s'agit de fichiers, est l'un des points faibles de la ZODB.

Ça se comprend...

Mon objectif est essentiellement de reduire l'impact utilisateur de
cette lenteur relative, et de libérer celui-ci le plus rapidement
possible (même si le plone continue de moulienr)


> S'il y a 20 auteurs qui font du drag'n'drop massif et quasi simultanément vers un site,

Je dirais plutôt qu'il s'agit de transvaser "régulièrement" des
"dossiers", plus petits que l'exemple (celui étant l'accumulation de
plusieurs dossier au bout d'un certain temps).

Il faut donc "juste" établir une procédure la plus ergonomique
possible, à enclencher facilement.

> S'il s'agit uniquement de la préparation d'une mise en production, il est préférable de fournir un espace sur le serveur partagé avec Samba dans lequel les auteurs pourront placer les documents en masse par drag'n'drop puis de les faire distribuer par Plone :

> * Soit par import en utilisant transmogrifier
> * Soit en utilisant un outil tel que FRS pour explorer une hiérarchie de fichiers à travers Plone.

hmmm... il (me) faut préserver les fonctionnalités
d'indexation/recherche et (ultérieurement & potentiellement) jouer sur
les workflow (changement d'états)...

l'idée d'utiliser un partage réseau (d'arborescence isomorphe) comme
"tampon d'entrée", me plait bien. Elle a un côté rassurant, on a au
moins une copie des docs hors plone.


> Autre avantage de ces solutions  : on peut se permettre de faire l'économie d'une architecture de production "cluster" couteuse, délicate à mettre en place et exploiter, telles que suggérées par Youenn ou Encolpe


Que oui !! :)


--
http://tartine-blog.blogspot.com/
jabber:[hidden email]
_______________________________________________
Plone-FR mailing list
[hidden email]
https://lists.plone.org/mailman/listinfo/plone-fr