Re: POA threading - more details

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


On Thursday 29 September 2005 19:30, Dion Picco wrote:
> Hi Erez,
>
> On Thu, Sep 29, 2005 at 10:27:34AM +0300, Erez Hadad wrote:
> > Hi,
> >
> > I've encountered a strange phenomenon related to POA threading: I have a
> > multi-threaded client that issues synchronous (e.g. not oneway) requests
> > to a collocated server.
> > At first, I used a POA with a thread pool in the server, using ORBacus
> > policies. Then, I decided that since the client is already multithreaded
> > and each thread issues synchronous invocations, then I should use the
> > client's thread to perform the collocated request inside the server as
> > well, to save thread resources. I implemented this by switching the POA
> > threading policy to dispatch_same_thread.
> > The problem is, I got a considerably lower throughput when using the
> > client's threads than when using a separate thread pool for the POA.
> > Seems as if an "outsider" thread is required to do some additional
> > processing compare to a "home" thread.
> > Can you explain why?
> >
> > PS: I'm using ORBacus for Java 4.1.3, JDK1.4.2, Linux
> > PPS: The client issues dynamic invocations (DII) - just synchronous, not
> > deferred or oneway.
> >
> > Redgards,
> > Erez Hadad
>
> Let me give you some background into how Orbacus sets up a request...
> - There is a base class StubImplBase which is the base stub class for
>   static clients
> - From StubImplBase is derived a MarshalStubImpl and a DirectStubImpl.
> - The MarshalStubImpl is used to marshal/unmarshal a request/reply and
>   transfer it to the wire
> - The DirectStubImpl is actually a direct reference to the Servant
>   implementation that exists in the POA.  It allows the static request
>   to avoid marshaling and invokes directly on this servant.  This is how
>   colocation is achieved and its very fast.
>
> We chose this method of implementing collocation due to its incredible
> speed.  Marshaling and 'on-the-wire' is completely avoided.  The
> downside is that collocation is not possible with DII since it would
> require knowledge of the stub/skeleton agreement in order to avoid
> marshaling and perform direct invocations.  Orbix on the other hand (and
> take this with a grain of salt as I don't intimately know the inner
> details of the Orbix source) uses some other method (perhaps
> PortableInterceptors and Anys) that is slower in the static stub case
> but allows it to utilize collocation with DII.  So its slower but more
> general (still faster than operating throw the TCP-stack of the OS).
>
> So with that knowledge I think its fairly obvious why you are seeing
> some more performance loss with your server now that you've switched
> from the thread-pool model.  You now essentially have a single receiver
> thread in your server that receives a request, invokes it, returns the
> reply and repeats.  With the thread-pool model you had a receiver thread
> that received the message, queued it up, and went back to receiving
> while some of the thread-pool workers invoked and replied.  In other
> words, much more concurrent.
>
> (For a more complete picture, see my article on Orbacus concurrency
> models on www.orbzone.org.  It is a good overview of some of the
> server-side concurrency models in Orbacus).
>
> 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