Deployment and Performances

[Piggy]

Hi all,

I am having a very strange performances problem with a webapplication after
deployment on the production server.
The following is the scenario:

1. My development environment: very quick responses
2. Testing environment (very poor hardware): acceptable response times
3. Production environment (very high resources: 4xCPU + 32 GB RAM): response
times are simply not acceptable at all. Note: this is the setup phase, so no
users load on the machine.

Trying to investigate I checked to be sure the code is identical in the
testing and production environment (precompiled locally and after copied to
the target sites).
Also, the IIS configuration (machine.config) is identical in the Testing and
Production environments, and are both set to the setup defaults.
I decided not to modify anything before having the full picture of the issue
- and I will set the min and max Thread parameters only when this initial
performances difference will be explained.

Using both Fiddler and the IIS trace logs I found a huge difference in the
"time-taken" (IIS logs) and elapsed time between the "ServerGotRequest" and
"ServerBeginResponse" values (Fiddler).

The Testing environment results to be from 2 to 3 times faster then the
Production environment in spite of the resources of the 2 platforms:
From 3 to 5 seconds per page in the Testing environment, the performance
falls to
12-15 seconds at least in the Production environment.

The application architecture is quite simple:
Security
1. Windows authentication (with impersonation)
2. Roles managed using the "AspNetWindowsTokenRoleProvider"
Data
1. SQL Server 2005 SP3 Std
2. Hardcoded databinding
3. very limited use of Dynamic Data (just for administrative configuration
pages).

Since the application is the same and the IIS config is the same, can
anybody suggest me what is likely to affect so negatively the performances?

Thank you very much in advance
Alberto

 

[Thomas Sun [MSFT]]

Hi Alberto,

If we create a simple ASP.NET web application and deploy it on production
server, does it have the same issue?

In addition, a log will be very useful for the trouble-shooting. You can
measure your .NET Application performance, such as Response time or
latency, Throughput, Resource utilization, etc, and then tune it.

For the multiple CPUs on server, you can follow the recommended setting of
Machine.config on server for ASP.NET on Improving ASP.NET Performance
article.

For more information about Measuring .NET Application Performance, see
http://msdn.microsoft.com/en-us/library/ms998579.aspx

For more information about Tuning .NET Application Performance, see
http://msdn.microsoft.com/en-us/library/ms998583.aspx

For more information Improving ASP.NET Performance, see
http://msdn.microsoft.com/en-us/library/ms998549.aspx


I look forward to receiving your test results.



Best Regards,
Thomas Sun

Microsoft Online Partner Support

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

With newsgroups, MSDN subscribers enjoy unlimited, free support as opposed
to the limited number of phone-based technical support incidents. Complex
issues or server-down situations are not recommended for the newsgroups.
Issues of this nature are best handled working with a Microsoft Support
Engineer using one of your phone-based incidents.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Mr. Arnold]

Hi Alberto,

If we create a simple ASP.NET web application and deploy it on production
server, does it have the same issue?

In addition, a log will be very useful for the trouble-shooting. You can
measure your .NET Application performance, such as Response time or
latency, Throughput, Resource utilization, etc, and then tune it.

For the multiple CPUs on server, you can follow the recommended setting of
Machine.config on server for ASP.NET on Improving ASP.NET Performance
article.

For more information about Measuring .NET Application Performance, see
http://msdn.microsoft.com/en-us/library/ms998579.aspx

For more information about Tuning .NET Application Performance, see
http://msdn.microsoft.com/en-us/library/ms998583.aspx

For more information Improving ASP.NET Performance, see
http://msdn.microsoft.com/en-us/library/ms998549.aspx

I am forwarding this to my job email. We were told by the client that the
Web site we develop and support for them is too slow, and they want it
faster.

And what we got as developers from our tech guy was some BS survey about
what we thought the problems are and what we could do to improve
performance.


__________ Information from ESET NOD32 Antivirus, version of virus signature database 4782 (20100118) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

 

[bthumber]

This sound like a problem I had once before. Check page if you are loading
tables on the page_load using Dataset. Or load large amount of data on a page
when it opens, this will slow things down quite a bit. If that is the case
try a datareader.

 

[Thomas Sun [MSFT]]

Hi Bthumber and Arnold,

Thanks for your response.

To improve performance of application, I think it would be better that we
find out what the bottleneck is and then modify the code or configuration.

Just like bthumber said that we can use DataReader instead of DataSet to
improve performance if there is any performance issue on retrieving data
from database.

If you have any question, please feel free to let me know.

Thanks.


Best Regards,
Thomas Sun

Microsoft Online Partner Support

 

[Piggy]

Hi All,

thank you very much for your suggestion, I have been busy with other
projects, but in the last days I took the time to dig into the problem.

First of all, my "disappointment" was generated not from the performances in
general, but from the huge gap of performances between my local (and testing)
environment and the production machine.

I must say the production infrastructure is provided by a third party
company which in my judgement is very very poor (but is highly trusted by the
customer), therefore I was reluctant to start a serious troubleshooting
activity.

After activating the default tracing of the webapp:
the only (huge) bottleneck was related to the Page load activities.
So I set a couple of custom trace points (trace.write) in the code finding
my initial idea was right:
the bottleneck was (is) a call to a function which performs a very simple
LDAP query: on my development environment it takes 0.00x seconds, while on
the production server it takes about 10-15 seconds (returning the correct
result in both cases).
By optimizing the call to the function (just call once when session starts)
and storing the result into the session variables, I solved all the
performance issues, falling from 20 seconds to about 1 or less for each
request (after the first).

Thank you very much for the suggestions, I hope my feedback will help others
with same problems.

Alberto