[Server-devel] [ejabberd] ejabberd tests with old and new TLS code

[Douglas Bagnall]

Martin Langhoff wrote:
>> http://wiki.laptop.org/go/Ejabberd_resource_tests/tls_comparison
>
> The graphs all have different y scales, which makes them hard to
> compare. Can you fix them easily to all be with the same y scale? Or
> put a big blinking warning -

I've taken out the minimum graphs for each category, which were the
ones with different scales (and least value), and put bigger divisions
between the categories.

>> These are different tests than the one I reported a few weeks ago,
>> which was conducted without the shared roster.
>
> Well, _without_ the shared roster and without the new tls patch it did
> seem that ejabberd peaked at 1MB per connection even at low numbers of
> connections. This test now shows rather different numbers... now with
> or without the patch the added marginal mem use is very low at the low
> connection numbers. I doubt having @online@ set reduces mem usage...
> Something is suspect here, or am I reading the numbers wrong?

The latter, I think.

Resident memory in megabytes with 500 users, on shared roster:

               min    median   max
old tls:       570     583     730
new tls:       555     561     688

So peaks of 1.46 and 1.36 MB per connection. It is greater than 1MB
per user at all loads, and grows consistently with the number of
users.

The test without the shared roster rarely had stable connection
numbers, but if you look at this page:

http://wiki.laptop.org/go/Ejabberd_resource_tests/try_4

(specifically at the second graph:
http://wiki.laptop.org/go/Image:Users_active-resident_mem-virtual_mem.png)

you'll see two stable periods, at around 1000 and 2000 users.  At 1000
users, resident memory appears to peak at around 480MB and at 2000,
maybe 680MB.  So that's 0.48 and 0.34 megabytes per connection.

Martin: some of my earliest tests were suggesting peaks over 1MB per
connection, which might be the source of the confusion.  But for those
I probably *did* have the shared roster on, though because I was
unaware that I'd been turning it off, I have no certainty of that.

Also in earlier tests there seemed to be more of a noise floor below
which a reduction in connections had no effect on memory, which is
less evident in these tests.


douglas