Re: [Server-devel] ejabberd tests with old and new TLS code
Hi Douglas, Thank you so much for this work. We are trying to come up the learning curve on the XS and scalability and I'm sure that I care about this data. Deds and I have been contemplating these and your previous results this morning and moving ourselves up the learning curve. TLS = ttp://en.wikipedia.org/wiki/Transport_Layer_Security correct? When you test old and new TLS there are code changes on both XO and XS? What releases are the control setup? IS the New TLS released code? Questions about the methodology. - 1 connection models 1 user? - Does it just connect? does it share any activities? would sharing activities affect the outcome in XS in any way? - Have you tested with current shared roaster vs a roster grouping system that only allows say 30 or 50 people in any online users roaster at once? If not do you expect that to be an important factor? Thanks, Caroline Deds On Fri, Nov 21, 2008 at 5:34 AM, Douglas Bagnall [EMAIL PROTECTED]wrote: With the @online@ shared roster, I have found a small decrease in both memory and CPU consumption with the new tls code, as shown here: http://wiki.laptop.org/go/Ejabberd_resource_tests/tls_comparison This is based on these two test runs: http://wiki.laptop.org/go/Ejabberd_resource_tests/try_7 http://wiki.laptop.org/go/Ejabberd_resource_tests/try_6 which can be found in raw form, and converted into graphs via the next two links: http://dev.laptop.org/~dbagnall/ejabberd-tests/http://dev.laptop.org/%7Edbagnall/ejabberd-tests/ http://dev.laptop.org/git?p=users/dbagnall/ejabberd-tests.git These are different tests than the one I reported a few weeks ago, which was conducted without the shared roster. Evgeniy asked if I could repeat that test with SMP disabled, but it happens that I can't because I've lost one of the computers that ran the clients. I could re-run this one without SMP if that was likely to be interesting. It looks like the cost of @online@ shared roster outweighs the cost of TLS. That's about as insightful as I get at this time of night. douglas ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel -- Caroline Meeks Solution Grove [EMAIL PROTECTED] 617-500-3488 - Office 505-213-3268 - Fax ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] ejabberd tests with old and new TLS code
Hi Caroline! TLS = ttp://en.wikipedia.org/wiki/Transport_Layer_Security correct? Yes. ejabberd is a memory hog, and we recently discovered (hint: lots of detail in the mailing list archive) that it's only a memory hog when ssl/tls connections are used. Using ssl or tls in the xmpp protocol has the advantage of using compression -- that's why we use it. When you test old and new TLS there are code changes on both XO and XS? Only XS. Recently, Process One (developers of ejabberd) published a patch that promised to reduce the mem usage on the server. Douglas and others are comparing before-and-after -- the P1 guys say it saves a lot of mem, independent testing is showing a mix. What releases are the control setup? IS the New TLS released code? The 'control' setup is the ejabberd-xs package we ship for XS-0.5. The new TLS code is a patch we could consider 'beta' quality -- there's been no significnat QA on it. Questions about the methodology. In general - there are good notes on all of this in the archives of this list. 1 connection models 1 user? yes - it's a script called hyperactivity... more in the archive.. ;-) Does it just connect? yes does it share any activities? no but part of the test is to share activities using real XOs in parallel to hyperactivity being used. activities affect the outcome in XS in any way? Not much on the XS, but yes on the bandwidth / spectrum used. Joe (QA team) has posted about his experimental results on this. Have you tested with current shared roaster vs a roster grouping system that only allows say 30 or 50 people in any online users roaster at once? If not do you expect that to be an important factor? We don't have that yet -- as I mentioned at Sugarcamp, we're working on it based on mod_roster_odbc, postgres and moodle. And yes, we expect it to be a big factor, otherwise we'd do something else ;-) cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [ejabberd] ejabberd tests with old and new TLS code
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: minmedian 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 ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] [ejabberd] ejabberd tests with old and new TLS code
On Fri, Nov 21, 2008 at 6:54 PM, Douglas Bagnall [EMAIL PROTECTED] wrote: 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. Ah, you're right. Those early numbers stuck in my mind -- we had seen numbers suggesting 1MB which we thought had no shared roster, it turns out it did. Apologies about the confusion - and thanks for breaking down the numbers so. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] ejabberd tests with old and new TLS code
Caroline Meeks Martin Langhoff: What releases are the control setup? IS the New TLS released code? The 'control' setup is the ejabberd-xs package we ship for XS-0.5. The new TLS code is a patch we could consider 'beta' quality -- there's been no significnat QA on it. In case anyone does want to try it, the packages I used are patched: http://dev.laptop.org/~dbagnall/ejabberd-xs-2.0.1-12.fc9.olpc.src.rpm unpatched: http://dev.laptop.org/~dbagnall/ejabberd-xs-2.0.1-11.fc9.olpc.src.rpm yes - it's a script called hyperactivity... more in the archive.. ;-) Does it just connect? does it share any activities? Actually hyperactivity does create fake activities, though I am not sure to what extent it really shares them. Hopefully someone from Collabora can explain it better (I'm interested too). Douglas ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
