Sebastian Benoit wrote:
> Hugo Monteiro([EMAIL PROTECTED]) on 2007.05.02 23:52:18 +0000:
>   
>> Hello all,
>>
>> I was wondering if there is any "right thumb" rule for the
>> incoming/local/remote concurrency values in a clustered qmail-ldap
>>     
>
> that depends on your setup: incoming concurrency is to protect your server
> from to many connections, and how many are possible depends on your
> processing (think spam/virus scanner...)
> similar logic applies to local & outgoing...
>
> /B.
>   

Hello Sebastian,

I am aware of the use of each concurrency option, and i'm also aware
that specific values depend on the system setup. However, the point of
my question, if not understood, is to focus on finding a set a possible
to rules to calculate such values.

For instance, in my perspective, it's not advisable to have a greater
number of concurrencyincoming processes than local and remote, since it
can origin delivery bottleneck and high server load, under high volume
message injection, if you have several MX servers and only one/few
backend servers.

On the other hand you'd want to have similar values for
concurrencylocal/remote of an MX and concurrencyincoming of a backend
server if the ratio is aprox 1/1.

In the case of many backend servers and few MX servers, you might want
the all concurrency values to be the same on the MXs and fewer
concurrency incoming on the backends.

I'm not sure if i was clear enough this time. My goal here , like said
before, is to find, if possible, a set of rules to help on the
calculation of these values, not in terms of absolute values, but in
terms of relative values or ratio.

Best regards,

Hugo Monteiro.

-- 
ci.fct.unl.pt:~# cat .signature

Hugo Monteiro
Email    : [EMAIL PROTECTED]
Telefone : +351 212948300 Ext.15307

Centro de Informática
Faculdade de Ciências e Tecnologia da
                   Universidade Nova de Lisboa
Quinta da Torre   2829-516 Caparica   Portugal
Telefone: +351 212948596   Fax: +351 212948548
www.ci.fct.unl.pt             [EMAIL PROTECTED]

ci.fct.unl.pt:~# _

Reply via email to