LinTong, 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 forth.
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. Regards, Eddie On Wed, May 19, 2010 at 4:36 AM, LinTong <[email protected]> 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.. >
