Re: POA threading - more details

Hi Dion,

Thank you for  answering promptly. 
Regarding the thread discrimination, I forgot to mention that I'm using JOB, 
so JTC is irrelevant. Still, is there any difference between 
Java-ORBacus-owned threads and outsider threads?
As for the thread pool question, I'd like to clarify and add data: in any 
system that uses more threads than the number of processors (in my case, 2 
processors and 500 threads in the pool), a client load being smaller or 
bigger than the thread pool (100 or 1000 concurrent requests in my case, 
respectively) but still larger than the number of processors should yield 
high throughput regardless of the thread pool size. Request latency would 
suffer when going to higher client load but throughput should actually 
improve up to a point. Only very big thread pool and client load can 
eventually cause throughput to drop because of context switching overhead.
However, in my tests using JOB, I see that using a client load of 100 or 1000 
with a thread pool of 500 cause throughput to drop compared to a client load 
of 500. However, my specific case may be more complex since the server 
threads do not run freely but are rather blocked at one point until their 
requests are sent away and replied, so this changes the rules. Thanks anyway.

Sincerely,
Erez Hadad


On Thursday 29 September 2005 21:41, Dion Picco wrote:
> Hi Erez,
>
> On Thu, Sep 29, 2005 at 08:25:48PM +0300, Erez Hadad wrote:
> > Hi Dion,
> >
> > Your answer does seem to be the right explanation. Thank you.
> > Still, because of the large throughput difference, I would just like  to
> > verify the following, so please bear with me: Does ORBacus discriminate
> > in any way between its own threads and "outsider" threads, e.g. in the
> > form of thread-local storage, priority, etc.?
> >
> > I have one more question regarding throughput using a thread pool:
> > Consider the following scenario (in JOB-4.1.3/JDK-1.4.2/Linux): A server
> > is processing multiple concurrent CPU-bound requests from remote clients
> > (non-collocated) using a thread pool model. Is it likely (and why) that
> > the server throughput would drop if the client load (number of concurrent
> > requests) is considerably lower or considerably higher than the thread
> > pool size? I noticed these phenomena in my tests.
> >
> > Best reagrds,
> > Erez Hadad
>
> Orbacus does differentiate its own JTC threads from non-JTC threads with
> regards to TSS.  Any threads making requests to the ORB MUST be JTC
> threads.  These JTC threads are implemented using the OS-specific
> mechanism however and are treated the same in the system.  The JTC is a
> great multi-threaded library that our customers can use for their own
> needs as its cross-platform and greatly simplifies many of the
> constructs needed for MT programming (as well as closly mimicking the
> Java implementation).
>
> If you have a thread-pool of size N, then it can only handle up to N
> requests at once.  The other thing to remember is that a single thread
> within the client can only invoke a single operation at once.  If my
> client only has 3 threads making requests but my thread-pool is size 10,
> then basically 7 threads are being unused in the thread-pool at all
> times.  Likewise if my client has 20 threads making requests, only 10
> can be serviced at a time due to the limit of the number of worker
> threads in the pool.  So if you drop the number of concurrent requests
> in your client, then the overall server throughput will drop since it
> has left-over worker threads being unused.  If you increase the workload
> in the client, then the thread-pool on the server should max out at some
> throughput above which it just cannot reach.
>
> In order to shed some more light though I would need to see some
> concrete data (calls/sec, bytes/sec, etc) to cross-reference.
>
> Cheers.
_______________________________________________
OB-Users Mailing List - [email protected]
http://mail.ooc.nf.ca/mailman/listinfo/ob-users
Visit our support FAQ before you send a message.
http://www.orbacus.com/faq/support.html