Home Page › Forums › BizTalk 2004 – BizTalk 2010 › Orchestration performance degradation
- This topic has 4 replies, 1 voice, and was last updated 9 years, 9 months ago by
community-content.
-
AuthorPosts
-
-
April 7, 2008 at 12:28 PM #19276
As I allow my orchestration to run, I notice the performace goes from about 2 seconds to make about 12 database calls (7 MSSQL and 5 Oracle) to several minutes. When I look at the Orchestration debugger, I see the message is being processed fine untill it reaches the first DB call (MSSQL in this case) and it takes 10 seconds from the start to the completion of the call. The query is quite simple and this orchestration has been running fine since January of this year. I just started seeing this behavior 4 days ago. Does anyone have any suggestions on what to look for?
-
April 7, 2008 at 1:57 PM #19277
HI Anon,
Well, to answer your question – there are many things that could wrong. I think we could use some more detail about your infrastructure before making any solid suggestions, including: CPU/RAM, server numbers, is BizTalk running on the same SQL Server? what apps are also connecting to the database? etc.
However If I were tackling this problem, I would look at the following (I’m sure others on this forum will be able to contribute more):
- Use SQL Profiler and check that the database query is reaching the Db in a timely fashion – i.e. is SQL Server being slow or BizTalk?;
- If you are using a SELECT statement, try wrapping it in a Stored Procedure – the stored proc will be compiled and the execution plan will not be recalculated with each call;
- Try re-building your indexes (you do have indexes right 😉 and updating your statistics;
- Use perfmon to determine whether there is other high-load operating on the DB during the time you are running your queries that may be causing processor or IO contention;
- If you are experiencing high CPU (I’ve read 50% plus but this always seems low to me), consider increasing CPU/RAM (consult perfmon)
- If you are experiencing high I/O, consider moving your database data and log files to separate disks so there is little or no IO contention
There is a bunch of good atricles online – simply Google ‘sql server performance’ – a few to get started with:
Hope that helps.
Cheers, Nick.
-
April 8, 2008 at 7:48 AM #19285
Thank you for all the replies. I was not sure if it was a BizTalk issue or not, and your answers help to focus my hunt. I found this morning that HAT was timingout and I did a quick Google for that issue and found the following:
http://www.tech-archive.net/Archive/BizTalk/microsoft.public.biztalk.server/2006-04/msg00040.html
Both of these indicate that it might be a DB issue, so I am enlisting the help of our DBA.
-
April 8, 2008 at 12:15 AM #19278
Anonymous,
why do you think this is a BizTalk problem? Superficially, your db calls are taking longer. Could some limit have been reached there? Or is the db machine in some way maxed out? Best would be if you could get a db expert ot look at it with you. Or at least point perfmon at it, or MOM.
John D.
-
April 8, 2008 at 4:26 AM #19282
database calls taking longer than expected can arise from network latency, I suggest you monitor the network I/O between the BizTalk server and SQL server.
Mike
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.