uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie Epstein <eaepst...@gmail.com>
Subject Re: the performance of UIMA AS
Date Wed, 19 May 2010 23:00:38 GMT

When you say "similar to Fig 4", are you actually running a CPM with
the MeetingDetectorTAE configured as a remote component? The CPM
calls remote components synchronously, meaning only one CAS is
sent at a time. Using a synchronous client, the remote annotator
is not doing any processing the entire time each CAS is being serialized,
deserialized, and transmitted via the broker to the remote service back and

Since the MeetingDetectorTAE has 3 delegates, if deployed
asynchronously it should be able to process 3 CASes concurrently, and
so the client sending CASes to the MeetingDetectorTAE queue should
have at least 3 outstanding CASes at a time. The RunRemoteAsyncAE
application has the ability to have multiple CASes outstanding to a queue.

Of course for this application with dummy analytics, virtually all the CPU
cycles are going to serialization. Using a separate RemoteRoomNumber
service compounds the problem, doubling the serialization work. Note
that the configuration in Fig 5 avoids all serialization of each document.

There is also an optimization to serialization that can be used to reduce
that overhead by 2-3x or more, depending on the data, using binary
serialization to UIMA AS services. The drawback of this approach is
that both client and service must have identical type systems.


On Wed, May 19, 2010 at 4:36 AM, LinTong <pcu84424@gmail.com> wrote:
> To Eddie
> I have read all the document about UIMA AS I can find, including
> handbook"UIMA Asynchronous Scaleout", readme and website. And I tried
> different performance parameters mentioned in the handbook for tuning.
> Unfortunately they do not help. Could you please tell me some other
> documents or tutorials I can follow? BTW, my approach is similar as
> Fig. 4 on website. I know there might be bottleneck if services are
> remote. But it is just a test and I don't know why the performance is
> so poor..

View raw message