DCBase

ok, tested adchpp too:

http://home.arcor.de/blastbeat/hubstress/adchpp.JPG

ram usage seems fine, cpu usage grows with usercount

Ok but any crash? Or memory and cpu usage compared to the other hubsofts ?

tested on winxp amd3000+ 1gb ram
the test bots only connected to the hub and didnt receive any further messages
(with will cause full send buffers in worst case as in luadch happened)

peak cpu usage:
uhub: ~ 5 - 10%
adchpp: growing to ~ 50% at 3000 users
dshub: ~ 90%
luadch: ~ 70%

peak ram usage:
uhub: 6 mb
adchpp: 25 mb
dshub: 97 mb
luadch: 210 mb

notes:
- dshub dropped users after a while, which is in my opinion the correct behaviour, but the cpu was very high and dshub didnt react when i closed all connected test bots at once
- adchpp: it was only possible to connect about 10 bots in 2 - 3 seconds, it took a while to connect all 3000 users
- uhub was very fast but crashed; dj_offset said the win version is unstable at the moment
(so a test on *nix would be good)
- luadch consumed to much ram and at bot 1500 it took longer and longer to connect;
disconnecting all users at once caused i very high cpu/ram usage

Hmm thanks for testing. Although it would be interesting to see if the bots talk a little bit or search , how the softs are handling the problem...

yes i also thought about extending it. but the main impact seems to be login of users
because of broadcasted infs.
i suggest to strip as much inf parameters as possible and sending additional information only at request. for example the cid. normal users dont need it, some clients even dont show it

uhub has a limited_bandwidth configuration option, which strips off most of the INFs broadcasted.

Pietry wrote:Would be interesting to test ADCH++ as well...

r131 takes 2000 users with the hubstress tool without any problem

I'm also interested in chat delay, or with many DRES ( which are really a pain in the *** for the hubsoftware )....

Why is DRES so painful for hubs? They are direct messages and as such do not matter much for total send bandwidth (compared to broadcast messages).
Besides, it is low value information (relatively), so a hub should feel free to drop them in case of "emergency", when the alternative is to drop a user due to excessive send queue.

I have updated my adcrush utility, so now it will operate on 4 activity levels:
* 0 = polite
* 1 = normal
* 2 = agressive
* 3 = insane

It will connect an optional number of fake clients to an ADC hub, and perform these options "randomly" with random delay (length depending on activity level) for each client:
* connects and disconnects (randomly)
* send chat messages (BMSG, but only if enabled)
* send private messages (EMSG)
* send searches (BSCH or FSCH)
* send search results (DRES)
* send CTM or RCM messages
* send INF updates

I have had it hammer uhub at "insane" level with 3000 users overnight, and all I got was a *very* long log file.

I have a few more additions to make to it, and it will be released along with the next uhub release.