views:

248

answers:

2

Hello everyone,

We are building an extranet loan status check website using ASP.NET MVC with a WCF backend. Its a pretty standard design with the MVC site using a WCF service reference to get customer objects. The ervice uses an Oracle backend + http binding, and won't be hosted on the same server as the MVC site (so we can't use tcp binding to reduce latency).

The problem we encountered is that every call to the service is resulting in a 7-8s response time which is unacceptable for an extranet site and much higher than the 2s magic mark. The service method(s) call 12 stored procedures to create the customer object. The database is, unfortunately, denormalized (we can't change it as its also used by other inhouse production systems) so most of the calls are basic select statements which populate the customer object and its associated objects. The service proxy is properly opened and closed/disposed in the MVC actions so there are no instances of any service connection leaks. A new client proxy is created for every request (i.e., we are not using the singleton pattern for the service).

Any ideas how we can speed this up ?

Thanks

+1  A: 

It sounds like you already know where the problem is - it's the database.

I've never heard of a WCF operation taking more than a fraction of a second to set up and tear down, excluding any logic inside. So even if you could shave off 1-2 seconds of latency (which is probably an optimistic estimate), that doesn't really help if the database operation takes 5-6 seconds by itself.

Honestly? Running 12 stored procedures to create a customer is completely off-the-wall. The purpose of a stored procedure is to encapsulate all of the logic necessary to perform a complex database operation. The very first thing you need to do is change this to be one stored procedure - then if it's still slow, profile the database to see what's taking so long and fix it accordingly. Usually poor database performance is due to one or more missing indexes.

Aaronaught
Thanks for the response. The reason we have 12 stored procedures is because the customer information resides in different tables (address, loan rates, etc) and each one needs to be queried - so you recommend to pull all info from multiple tables in one stored proc ?
fjxx
@fjxx: You can start with putting the logic into one stored proc. But more likely you don't need to query 12 separate tables individually, you can do it with a single set of joins. And even then, 8 seconds sounds like too much - you probably don't have some or any of the tables indexed properly.
Aaronaught
A: 

Until you accurately measure what is really happening, don't be too quick to assume where the bottleneck is.

You really need to do an Oracle extended SQL trace to see where that slowness is coming from. Anything other than that is mostly guesswork. Here is a paper from Cary Millsap (of Method R and formerly of Hotsos) that you can download that details doing this:

http://method-r.com/downloads/doc_details/10-for-developers-making-friends-with-the-oracle-database-cary-millsap

Dougman
Thanks everyone for the replies.We found the resolution to this performance issue. For 10 out of our 12 stored procedures, we were using the LOWER oracle sql function on the indexed field. Once we removed that, our service response time went down from 8s to less than 2s.
fjxx