[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster-devel] Connections/CallbackServer/Subscriptions
Some initial finding on a stress test wich tests
a) Many subscribers in one connection.
b) Many subscribers with one connection each.
Here are the first result with 500 subscriptions ;-)
Server memory per subscription consumed
IOR SOCKET RMI XMLRPC
oneCon manyCon oneCon manyCon oneCon manyCon oneCon manyCon
100 2631 27484
500 1785 26602 1081 18346 1041 22658 452 -
Logins/sec
IOR SOCKET RMI XMLRPC
oneCon manyCon oneCon manyCon oneCon manyCon oneCon manyCon
100 124 2
500 142 2 7 0 167 2 99 -
Message/second updated
IOR SOCKET RMI XMLRPC
oneCon manyCon oneCon manyCon oneCon manyCon oneCon manyCon
100 35 27
500 20 2 11 0 21 2 - -
Pretty interesting. The XMLRPC did not run at all. And the most
effective seems to actully be to have many subscriptions on one Corba
connections, with RMI as a competitor. I will do larger test, the just
take sooooo long to complete.
//Peter
On 25 Sep, Marcel Ruff wrote:
> Peter Antman wrote:
>
>>Hi,
>>I am sort of tinkering around with a possible subscription pool of a
>>sort (a base for implenting Baster MDB:s), but I can not come to grip
>>with the tradeoff between having one connection for each subscription or
>>one connection for every subscription.
>>
>>Say this. We have a lot of "clients"/entities who are only subscribing
>>on a particular query. Each query is unique. Say we have 20 000 such
>>queries/entities/subscriber.
>>
>>What would the tradof/effect be of having (focus on Corba):
>>
>>a) 20 000 XmlBlaster connections with one subscription each (same VM),
>>or
>>b) One XmlBlaster connection with 20 000 subscriptions.
>>
> b) has far less memory consumption, but you should definitely write a little
> HelloWorld.java trying it!
> It is probably a good idea to compare it with the SOCKET protocol,
> (or the connectionless XmlRpc or RMI)
> it probably handles the situation with less memory footprint.
>
>>
>>For Corba i would guess that the outgoing connection
>>(XmlBlasterConnection) is not that important, but it is how the callback
>>server works.
>>
>>With 20 000 connections, is there also 20 000 callback servers
>>instantiated?
>>
> Yes, on client side there are 20 000 servers active (if it is split to
> 20 000 clients on many computers it shouldn't be a problem on client side).
>
> On server side, we have a small number object instances per callback doing
> the client connection (see protocol/corba/CallbackCorbaDriver.java)
>
>>
>>With 20 000 subscriptions in one connections, does the callback server
>>handle that amount of potentail callback invokations?
>>
> It definitely should, if there are problems we need to improve the code.
>
>>
>>Would there be anything to gain to create some sort of algoritm that at
>>certain breakpoints created a new connection, say we would allow 1000
>>subscribers per connection, or (from a corba perspektive) would there be
>>absolutely no gain in doing so (the handling of the callback is not
>>locked/synchronized in any place, but are totae stateless, so that
>>invocatations in the same VM could verry well be handled by only one ans
>>the same callback server)?
>>
>>Hm, hope I made my case clear ;-)
>>
> Yes, but you need to test the various setups to have reliable
> results, probably we should add your stress tests to the testsuite under
> xmlBlaster/testsuite/src/java/org/xmlBlaster/test/stress
> Every test reports some informations like consumed memory per suscribe
> or performance issues etc.
>
> It is not a basic task what you are doing - but it will help
> xmlBlaster to be more robust,
>
> Marcel
>
>>
>>//Peter
>>
>>
>
--
------------------------------------------------------------
Peter Antman Chief Systems Architect, Business Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------