[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	-

       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.


On 25 Sep, Marcel Ruff wrote:
> Peter Antman wrote:
>>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
>>What would the tradof/effect be of having (focus on Corba):
>>a) 20 000 XmlBlaster connections with one subscription each (same VM),
>>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
> 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 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