In our development environment we have one dedicated Trading Networks server for B2B integration . We are lately facing one problem after configuring the Broker . Whenever we have a huge number of documents getting processed resulting into lots of service execution task the memory usage reaches upto 95-97 % in an average for quite a few hours . And in this duration we are experiencing a IS-Broker connection flicker . Every 5 minutes or so its complaining like unable connect to broker and starting to poll then pushes the doctypes . Is there anyway in which we can get rid of this connection issue ? We have broker server hosted on a different machine and we are using 6.1 version . Any response would be highly appreciated .
I assume you have processing rules or processes that are pushing the documents from TN to the Broker?
If so, then there are a number of performance options you have available on both the Broker and the IS/dispatcher side.
Can you give us some more detail on the implementation - specifically, how documents are flowing through to the Broker, where they go after the Broker (adapter service for example), average size of the documents, and how many is “huge”?
Well …I’ll try to explain more . Its not that we are pusing documents from TN to broker . We have service execution logging (mainly for tracking) to a database . Now these logging details for each of the service are collected in a specific IS/Doc format and they are published to the broker . While subscription we insert the details from the document to the database .
Documents are in average 150-200 KB and by huge i mean a situation when 15K+ documents are pending for processing . Hope I was able to my scenario .
Though the scenario you anticipated is not exactly we have I would also be glad to know what are all the performance tuning techniques you were talking about and available on both the Broker and the IS/dispatcher side.
Hmmm - the question “why?” occurs to me, preceded only by “what the heck?”
I’ll assume you have solid reasons for this particular arrangement.
Performance tuning for pub-sub boils down to three basic areas: publishing service/IS dispatcher, Broker, subscribing IS dispatcher/trigger/service.
In my experience, rarely is the Broker to blame for any pub-sub performance problems. In most cases, it is a subscribing serial trigger passing documents to an jdbc insert service, and that service or database is unable to keep up. As a result, the trigger doesn’t pull more documents from the broker until its queue gets below the refill level, and they end up stacking up on the broker.
There are far too many things to tune to list them all here, but I’ve attached a document I wrote for wmusers last year that may cover many of them. I have not reviewed that document for errors/omissions lately, but it should be a good start for you.
In addition to reviewing the document, take a look at your trigger queues in the Broker during your peak times. Check to see if they have large numbers of documents and are depleted very slowly. This is an indicator of the problem I described above. PubSub Scalability Considerations for wmusers.doc (89.5 KB)
