memory cost of bidir

in Help Center
Hi, We are evaluating bidir.
I notice that the simple demo client will cost nearly 4M ram. and after implementing bidir in our app. the memory cost also increases nearly 4-5M ram.
Why bidir will increase so many RAM? can we reduce it? since the memory cost metrics is critical to our app.
Thanks
Kan
I notice that the simple demo client will cost nearly 4M ram. and after implementing bidir in our app. the memory cost also increases nearly 4-5M ram.
Why bidir will increase so many RAM? can we reduce it? since the memory cost metrics is critical to our app.
Thanks
Kan
0
Comments
I notice that the initial memory cost of bidir client is nearly 4M ram, but after running 1 hour, the memory decreased to 800K. very interesting!
can anyone explain the reason?
and i tries to run 2000 clients concurrently, and set Ice.ThreadPerConnection=1 property.
the server runs very well, untill the thread.cpp reports out of memory.
But I notice there is still memory available.
Any how, I really appreciate the performance of ICE bidir. It's a great work!
Thanks
Kan
as many guys told me the concurrent sockets opened by a process is limited by the OS.
I tested bidir demo in XP(SP1), and seems that 1024 is not the limit.
can anyone tell me the concrete maximum number for windows OS?
Kan
Why are you using thread per connection anyway?
I do not mean to use thread per connection anyway.
My primary purpose is to verify the concurrent connection limit of bidir.
Orignially I use Ice.ThreadPool.Server.Size=10. But I noticed that when the number of clients increased, the server will run low of thread pool.
that's why I use thread per connection instead.
Kan
If you need more than this many connected clients concurrently then you should rebuild Ice yourself and change the value of FD_SETSIZE in the compiler preprocessor flags.
Keep in mind that if your clients are busy your server will probably not be able to process that many clients at a time anyway...
Does it really matter for your application if the thread pool runs low on threads? The only situation where it does matter is if you use nested callbacks, because then it is possible that a call blocks indefinitely if not enough threads are available to service the nested callback.
If you don't have such nested callbacks, I recommend to simply disable this warning, or to set Ice.ThreadPool.Server.SizeMax to the same value as Ice.ThreadPool.Server.Size. See the user manual for further information.