Wiki Navigation

Changes between Version 7 and Version 8 of dchub

v7	v8
7	7	First functional version's implementation was four-hour job, and results were fantastic. Although up to March 2008. design was three threads per client, it performed flawlessly for ''more than four years worth of uptime''. As objective was stress testing, priority to change that design came only lately (early 2008.) when I've started working on some new ideas on handling big number of clients with single server.
8	8
9		Currently [dchub://dc.balcan.net:412 dchub] serves 120-190 clients with CPU usage under 1.5% and memory usage cca 70MB. Somewhat high memory usage is due to current RTCollector.m3 design where each thread gets his own pages for allocation and also a bit conservative major collections. As this is still small usage in this age, I think speed of allocations and flawless execution far overweight this "inconvenience". Thread stacks are set bu ulimit to 64kB per thread.
	9	Currently [dchub://dc.balcan.net:412 dchub] serves 120-190 clients with CPU usage under 1.5% and memory usage cca 70MB. Somewhat high memory usage is due to current RTCollector.m3 design where each thread gets its own pages for allocation and also a bit conservative major collections. As this is still small usage in this age, I think speed of allocations and flawless execution far overweight this "inconvenience". Thread stacks are set with ulimit to 64kB per thread.
10	10
11	11	[source:trunk/m3/dchub Source] will be available.