Christopher Browne wrote:

> Note I've changed the subject to make that seem more relevant...
>
> Cyril SCETBON <cyril.scetbon at free.fr> writes:
>   
>> Here are the plots of several metrics taken with the original slon
>> binary (25 september 2007) and with the new slon binary (including
>> modifications of static variables, 16 october 2007)
>>     
>
> The graphs aren't quite well enough marked to figure out what's
> what...
>
> Is the first one, where "delay" times seem to stay low, but where
> there are pretty regular spikes for everything else, the modified
> slon, and the second one, where there are fewer but generally rather
> higher spikes, represents the "stock" slon?
>   
yes
> If what I *think* I am seeing is correct, then there looks as though
> there may be some value in increasing the default value for
> SLON_DATA_FETCH_SIZE, but I think I need to understand this better.
>
> You might want to comment on some of the lines, and relative
> interpretations.  Also, it's not clear what you set
> SLON_DATA_FETCH_SIZE to.
>   
I told it in a previous mail :

/" I've modified the value of SLON_DATA_FETCH_SIZE in src/slon/slon.h 
and rebuilt it. I've changed it from 10 to 50 to make fetchs of 500 lines. "
/
> What would seem ideal to me would be to have 3 or 4 graphs, where
> there is an attempt to keep as many similarities as possible...  Thus,
> my "ideal" would involve the following sorts of properties:
>
>  - Preferably, each run would be at about the same time of day, or
>    whatever is relevant such that we can expect to see similar
>    performance characteristics;
>
>  - It would be nice to have some information on each graph indicating
>    amounts of replication traffic (e.g. - numbers of tuples getting
>    replicated) so that we can see how well they compare.
>
>  - Multiple runs, and hence multiple graphs, varying on SLON_DATA_FETCH_SIZE:
>    - One with the "baseline" of 100
>    - One with SLON_DATA_FETCH_SIZE = 400
>    - One with SLON_DATA_FETCH_SIZE = 1600
>    - One with SLON_DATA_FETCH_SIZE = 3200
>
>   Those numbers are scaling up by a factor of x4 each time, so that we
>   can see a pretty wide range of increase.
>
>  - If you can track the size of the slon processes, that may also be
>    useful; it might turn out that increasing SLON_DATA_FETCH_SIZE to
>    5000 has wonderful performance effects as long as you have 4GB of
>    memory available, but that the slon will start swapping if you have
>    more modest hardware :-(.
>
>  That may be a lot of work, which I obviously can't make you do :-).
>  It may be that further explanations of what is in the two existing
>  graphs will tell us enough to come up with a better value than
>  SLON_DATA_FETCH_SIZE = 100.
>
> My expectation is that we'll discover that most of the benefits,
> e.g. - most of the reshaping of performance, come from the early
> increases, and that this comes at only modest memory consumption
> costs, and that further improvements would be costlier.
>
> If that turns out to be the case, then the right answer may be to bump
> up the default value from 100 to 400, for everyone, and to turn it
> into a tunable parameter.  I'd like to have a way to draw that
> conclusion!
>   
The platform is not available anymore, but when it will be I'll try to 
make most of these tests.

-- 
Cyril SCETBON - Ingénieur bases de données
AUSY pour France Télécom - OPF/PORTAILS/DOP/HEBEX

Tél : +33 (0)4 97 12 87 60
Jabber : cscetbon at jabber.org
France Telecom - Orange
790 Avenue du Docteur Maurice Donat 
Bâtiment Marco Polo C2 
06250 Mougins
France

***********************************
Ce message et toutes les pieces jointes (ci-apres le 'message') sont
confidentiels et etablis a l'intention exclusive de ses destinataires.
Toute utilisation ou diffusion non autorisee est interdite.
Tout message electronique est susceptible d'alteration. Le Groupe France
Telecom decline toute responsabilite au titre de ce message s'il a ete
altere, deforme ou falsifie.
Si vous n'etes pas destinataire de ce message, merci de le detruire
immediatement et d'avertir l'expediteur.
***********************************
This message and any attachments (the 'message') are confidential and
intended solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. France Telecom Group shall not be
liable for the message if altered, changed or falsified.
If you are not recipient of this message, please cancel it immediately and
inform the sender.
************************************