On 01.01.2014 19:55, Paul J Stevens wrote:
> Aleksander,
>
> imapproxy appears quite pathetic!
>
> I just did a simple benchmarker which does a login/logout cycle.
>
> hitting dbmail directly is an order of magnitude faster than hitting
> imapproxy. That seems quite surprising since imapproxy doesn't have to
> do any authentication, just hash and compare to the connection cache.
> But still, the numbers speak clearly:
>
> testing login/logout
>
> COUNT    | 10     | 100    | 1000
> ---------+--------+--------+---------
> DBMail:  | 0.0532 | 0.6054 |  6.9042
> IMAPProxy| 0.3995 | 4.0095 | 40.0218
>
>
> I'm adding the benchmark script I wrote to the master branch so you can
> test for yourself.
>
> http://git.dbmail.eu/paul/dbmail/tree/test-scripts/imapbench.py
>
> Note that for dbmail-2 using imapproxy made sense in order to reduce the
> concurrency pressure. But for dbmail-3 that doesn't fly any more.
May be something wrong with my dbmail setup, but before installing
imapproxy with dbmail 3.x (we don't use it with 2.x) I ran similar
benchmark and it says than login to imapproxy much faster. Test results
were kept in our wiki (25 is imapproxy avg. caching ratio):

    $ time for i in `seq 25`; do python -c "from imaplib import IMAP4; m
    = IMAP4('localhost', [dbmail_port]); m.login('test', '*****');
    m.logout()"; done
    real    0m10.051s
    $ time for i in `seq 25`; do python -c "from imaplib import IMAP4; m
    = IMAP4('localhost', [imapproxy_port]); m.login('test', '*****');
    m.logout()"; done
    real    0m3.639s

Now I ran imapbench.py with 3.1.7 setup and got a similar picture:

    # python imapbench.py --host localhost --port [dbmail_port] --login
    test --password *****
    testing: login/logout
    count:  100
    time:  47.5001049042
    root@styx:~/dbmail-imaproxy# python imapbench.py --host localhost
    --port [imapproxy_port] --login test --password *****
    testing: login/logout
    count:  100
    time:  4.00187397003

As you mentioned earlier, max_db_connections can be a source of
problems, I tried to use the default value, but it did not change the
situation. Maybe our database is too slow, but there's nothing we can do
about it. It is quite big, it is about 100 GB.

_______________________________________________
DBmail mailing list
DBmail@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail

Reply via email to