Timing initial startup in an ASP.NET application

We had a similar issue, and I don't know if our experience will help you. Fortunately, this happened at a time when we were first investigating Service Oriented Architecture, so we were very interested in how using web services affects performance compared to other methods of getting data.

I'm not saying that our results will be helpful to you, but possibly the methodology.

We actually spent two full 8 hour days doing nothing but testing different connection scenarios, We were particularly curious about the added bandwidth associated with getting data via XML as opposed to as binary data. We fully expected a performance degradation simply from getting XML data, which we assumed would be more bytes across the network.

I won't go into the results, as that was a 10 page document in itself, but we DID find an interesting lag that occurred when we were getting data from a web service written in a .Net language that was accessing data on the iSeries (AS/400, System i, or whatever the new term is these days). Just like you described, the first call to get data took a while, but subsequent calls were quicker.

It turned out that the type of connection we were using (ODBC provided by Microsoft) was the culprit in our case by looking at the network packets.

We measured the network packets between the client and the web service, and also between the web service and the iSeries (data store) and we found that the lag was happening because the first time the web service made a connection to the iSeries, several unnecessary packets were being sent back and forth.

In a nutshell, the Windows side would send a connection request, wait a few milliseconds, then send another one. meanwhile, the iSeries was just slow to respond, so in the first attempt to connect, there were four calls to connect from the Windows side to the iSeries side, and then four responses from the iSeries, which were ignored by the Windows side (because the Windows side of the connection had given up). Finally after 4-6 attempts, a connection was established. After that, the connection must have been pooled, because subsequent connections within a short time were quick. However, if time elapsed (we never did determine how long was needed for this to happen), the slow initial connection resurfaced.

SO, after all of that long spew, @Aggelos Mpimpoudis had suggested profiling your own code. My suggestion would be to find someone who has experience and tools for analyzing Network packets and analyze the entire process. You may be able to trace down the culprit that way.

Incidentally, our problem got better after we switched to connecting to the iSeries using the Ibm.Data.Db2.iseries instead of the System.Data.Odbc driver AND after we had enough web services written that frequency of calls to the iSeries was enough to keep the pooled connection open.

The problem with that is that he's trying to measure time *outside* the code he's written.

John Fisher 2009-09-12 01:30:57

Not necessarily,,, Part of the lag could be in his own code

David Stratton 2009-09-12 02:09:17

He wants to measure the whole process, so measuring part of it isn't quite enough.

John Fisher 2009-09-13 17:40:27

IIS's performance is somehow proven, so it must be something with the code. But there should be a holistic approach indeed, as John says.

Aggelos Mpimpoudis 2009-09-13 23:43:00

ansaurus

tags:

views:

answers:

Timing initial startup in an ASP.NET application

related questions