Recently I suggested a developer meeting at
our company to address performance and scalability concerns for a Web- based
application we are developing. The application is hosted on a Windows 2000 server
farm with shared access to a RAID-based SQL Server 2000 installation. The front
end of the app is an IE 5.5 browser-based GUI that employs a lot of DHTML, XML
and XSLT to render the pages. Portions of the application also access an AS400
- based host running DB2. I though it would be useful to put up a generic version
of the performance tuning "hit list" that I came up with for the meeting.
Most of the items you'll see in the outline that follows are self - explanatory,
and almost all of the others can be found in the Microsoft documentation for
the particular product involved:
Performance
Tuning - Suggested Major Areas:
Operating System:
- Tuning of RAM
- "Application Server" settings for server boxes
- Disabling unnecessary services
- Hard drive speed / configuration
- Paging file configurations i.e. where, how big, how many
- Locations (and configuration) of IIS logs and SQL Server
Transaction Logs.
- Network throughput and TCP packet size tuning for the Intranet.
COM+:
- Server vs Library Applications (Performance)
- Placing congruent COM+ business objects into the same application
package�
- Resource Pooling vs. GetObjectContext() method for ASP and
within COM+ VB objects
- Application
Component Grouping - the middle-tier components
should be divided into time-dependent and time-independent services (i.e.
MSMQ, "service" type components)
- Look
into different ways to have asynchronous (background) or scheduled (services/
MSMQ) operation of long � running queries rather
than client having to wait for them to finish while trying to use the application.
- BaseAddress Allocation � All components
should have a unique DLL Base Address to avoid object creation contention
at the server level
- Correct Setting of VB Project Compile Settings to enable
maximum COM+ scalability ("Unattended Execution" and "Retained in Memory")
- Optimization at the code logic level (e.g., using the new
built-in "Split", "Join" and "Replace" functions vs.� older slow "looping"
hand-coded functions)
- Additional Compile-Time optimizations can speed up components
(where permissible):
- Optimize for fast code
- Assume no Aliasing
- Remove array bounds checks
- Remove Floating Point Error checks
- Allow Unrounded floating point operations
- Remove safe Pentium FDIV checks
Internet
Information Services:
- Use of Response.IsClientConnected
to minimize overhead on long-running queries
- COM objects are released earlier
if they do not use the OnEndPage method but use ObjectContext.SetComplete
instead.
- IIS Server Settings:
- ASPQueueConnectionTestTime
- ASPThreadGateEnabled
- ASPProcessorThreadMax
- ASPScriptEngineCacheMax
- ASPScriptFileCacheSize
- ASPRequestQueueMax
- ObjectCacheTTL Registry Setting (not present by
default)
- Setting of aggressive Connection Timeouts to combat
network latency
- Use of Process Throttling for certain applications
- Using HTTP KeepAlives
- Optimize DHTML and other page
� generating code to most efficiently use the IE5.5 browser�s capabilities
in the DOM / DHTML object model.
- Making sure Debugging is turned
off (locks down to single thread)
- Turn off ASP Session State for
pages / Apps that don�t use it or use a SQL Server Session Management
component instead
- Store log files on separate disks
and remove nonessential information
- Use CPU Throttling for rogue
out-of-process applications.
- Pooling of web applications with
ISM Application (isolation) protection settings � (Low, Medium, High)
- Synchronization of� IWAM_<machine>
Identity with COM+ (SyncIwam.vbs)
- Use of Terminal Services to remotely
administer servers.
- Monitoring and testing of Server
Performance with WCAT ("Homer"), HTTPMonitor and Network Monitor.
- Performance Counters and recorded
results reports
- Add <% @enablesessionstate=false %>at top of pages not using
session vars.
SQL Server Performance Tuning:
- Creation and tuning of proper indexes
for all tables
- Avoid storing of unnecessary logging
information in production mode
- Optimization of stored procedure queries
for speed
- Always use the adCmdStoredProc property
in ASP stored proc execution
- Use LookupTable object (Free �threaded)�
in Application Scope to cache frequently-used data
- If using COM+ components to access
SQL Server, make sure that SetComplete or SetAbort methods are called correctly
to release server resources. Make sure all connection objects are opened as
late as possible, and closed as early as possible, and set to "Nothing" to
release back to connection pool.
- Recordsets should be opened explicitly
and the correct "lowest resource use" properties set for the particular situation.
Recordsets should be closed and extinguished to free resources as soon as
possible.
- NT Windows Fibers
- Max Async IO
- Default Network Packet Size for SQL
Server
- MinMemoryPerQuery Setting
- PriorityBoost / TimeSlice / MaxWorkerThreads
service settings for SQL Server on dedicated machine
�Obviously, this is not a complete list by any means. But if
you are charged with performance tuning of a web - based application running
on Windows 2000 and using SQL Server as the data store, this should be a good
start!
Peter Bromberg is an independent consultant specializing in distributed .NET solutions
Inc. in Orlando and a co-developer of the NullSkull.com
developer website. He can be reached at info@eggheadcafe.com
|