[bob_romijn]

Hi,

Currently we are facing major problems with the performance of OTM especially in the integration of messages.

We are using version 4.0 for this part and we are speaking about approximately 400,000 messages a day.

After a bit of investigation a strange thing is that the machine isn't doing too much in means of CPU usage etc.

In this forum I see some messages speaking about threads. I also did some minor things with this in version 5.0. My feeling is that we need to tune OTM a bit more using this.

Biggest problem here is that this feature is not really documented. I also asked Oracle for more info, but I can't get more then "Yes, you can tune the system with that.".

Does someone has experience or documentation about this which he/she wants to share?

Best regards,

Bob

[nick.polites]

Bob,

You’ll want to look at the event diagnostic page to see where the bottleneck may be. If after looking at the obvious from top on the app,web and database do not show excessive CPU/Load the diagnostic page is the next place to look. You can pull the event diag page at <<server_url>>/servlets/glog.webserver.event.EventDiagServlet (OTM 4.0) as a user with Admin level access. You’ll want to look at the process time of each thread and determine where to look for the issue. From there you can adjust the threads if needed, but you will then need to make the changes to the glog.properties file otherwise the changes will be reset on the next restart of OTM.

Nick

[miks]

You might want to check the size of the XML documents you are dealing with. For outbound transmissions, you can create you own XML profile, to include only the data that is relevant to your transmission. If you don't, by default, OTM will run many, may queries, needlessly to generate the document. Problems are further compounded if multiple documents are being generated at the same time. On the inbound side, all the XML crunching takes place on the app server, so lots of memory and CPU are a prerequisite there. If you have lots to use, then allocate a bunch of threads and monitor accordingly. If none of the above works, run your app server in console mode. When you experience your slowdown, hit ctrl-break, to get a thread dump of what is going on in the server. Often times, something totally unrelated can be the culprit, (Even an OTM Bug )

Hope this helps.

Mike

[cwarner]

Originally Posted by miks

You might want to check the size of the XML documents you are dealing with. For outbound transmissions, you can create you own XML profile, to include only the data that is relevant to your transmission. If you don't, by default, OTM will run many, may queries, needlessly to generate the document. Problems are further compounded if multiple documents are being generated at the same time. On the inbound side, all the XML crunching takes place on the app server, so lots of memory and CPU are a prerequisite there. If you have lots to use, then allocate a bunch of threads and monitor accordingly. If none of the above works, run your app server in console mode. When you experience your slowdown, hit ctrl-break, to get a thread dump of what is going on in the server. Often times, something totally unrelated can be the culprit, (Even an OTM Bug )

Hope this helps.

Mike

I agree with Mike, we had a long standing issue with this and had a hard time figuring out it was the XML. This is pretty much the same answer we got after looking at this for about three months. Good suggestion Mike.

Caleb

[bob_romijn]

Hi,

THanks for the replies. We are going to look at the XML for sure.

Regarding the threads, is there a limit in setting threads? What is the max, etc.

Best regards,

Bob

[nick.polites]

There isn't a limit on how many threads you can allocate to a process. However the higher you increase them the higher the risk that you will bottleneck a tier in terms of CPU. If you added lets say 25 agent threads, while you app server will see higher CPU/load the database server will no doubt max out and will cause the entire application to stop responding. You should increase between 2-3 threads at a time and run some performance tests to see what kind of impact will occur on all tiers.