Working on the shared environments or clustered environment is quite a challenge and getting the best performance out of the servers requires that we understand as how servers are been designed or maintained in the infrastructure. If during the load testing, we are continuously seeing a very high response time which continuously exceeds the SLA’s given to us, then it’s time probably we should start focusing on the shared environment aspects of the application.
Some of the question I often ask are as below,
- Is the Database the only application running on the server box? If it’s sharing the server box with other enterprise applications like web server etc. , then probably it cannot perform optimally.
- Does the Database memory/CPU/IO counters looks OK and they seems to align with hardware configuration of the server box.
- Is the hardware of the server box like BIOS, Disk Controller etc. is up to date with latest patches and latest software. (I Know Microsoft Supports recommend this step always in case of any performance issue and I whole heartedly agree to this approach).
- How often the virus scanning software is running in the server box. Quite often virus scanning software interrupts the smooth functioning of the database servers by interfering with database file system.Both are IO based application. It makes sense to exclude scanning of key database files to improve the performance of the database.
- Does the database server have regular maintenance window, how often is database maintenance done. Maintenance activities could include applying patches/server reboots etc.
Having the answers to these questions often helps in eliminating the various roots cause for the slow performance of the application. Once we have eliminated these causes and have confirmed that environment or server box seems to good and still we are seeing slowness in the application, then probably it makes sense to drill down the details of the individual database server configuration,
Quite often it happens that most of the servers are installed with default settings. We all love to click next and next and next button while installing any enterprise software.This habit installing enterprise software later on starts giving nightmare to everyone once the application goes live.Every setting is factory made settings.So it times makes sense to drill and find out those default settings of the servers.
So let’s assume that we have MSSQL 2008 as the database server and we need to know the various default configuration setting that is in place for MSSQL 2008 box like what’s the memory /connection/processor setting etc.,
Assuming that you have SQL Management Studio installed, all you need to do is follow the below steps,
- Connect to the Database server with Management Studio.
- Using object explorer of studio, right click on the server node and select properties from the context menu.
- Server property window will be visible to you. This window will have all the information with regard to connections/memory and various other settings that are in place for that database.
We should be able to see the something like below screen,
Another way of know the default setting is via system procedure sp_configure
SELECT * FROM sys.configurations
ORDER BY name ;
GO
or with
sp_configure
go
All these information will help us to correlate the high response time from the front end to the backend database and at times helps to scale application performance.When you run this procedure, it will show lot many information ,nearly 60+ settings that impacts the database.So in case if you feel any settings do not match with your application requirement then probably you need to talk to the DBA and explain him your reasoning as why that setting is impacting the performance of the applications.
For example, if the user connection value in database is set to 10 , and during your tests with 30 users, you see that response time are high, then probably highlighting this difference to the DBA might help assuming that at some point of time,it might happens that 10 connection might not be sufficient to serve the peak hour demands of the application.