New article
Recently updated
Investigating Performance Issues: Information Gathering
Who is this article for?Users, IT Administrators and Support colleagues investigating performance issues.
Performance issues, where a part of a system starts to run slowly, are often complex to investigate. The root cause can relate to all kinds of factors, including ones outside of the application itself. Often, we will be wanting to compare various sources of information, including user reports, configuration information and logs. It can be difficult to know where to begin.
This article describes a starting position for investigating slow performance.
Understanding the application behaviour
When investigating, the first thing to do is understand what 'slow' means in this context. Is it always slow? Only sometimes? For a few people or everyone? On all screens in the application or just some?
In addition, user expectation is crucial - what someone describes as 'slow' might in fact be reasonable, for example the running of a large and complex report.
In order to progress we need to understand exactly what is happening. This means that we must ask a number of questions to help us understand the behaviour of the application, and this in turn can help us focus our efforts.
So for example:
- Is the performance issue impacting all users?
- If not all users, then does it affect a particular group of people? For example, only people in a particular location
- Are there specific actions that are slow? For example:
- Is it slow to load, but once there everything is as normal?
- Is one particular screen or activity a problem?
- What kind of response times are we talking about?
- Can we identify any patterns? For example:
- Does this occur at particular time(s) of day?
- Are there regional / per office variations?
- Does it seem to be triggered by a specific application event?
- Is it consistent & repeatable?
- When did it start to happen / what changed?
- Has there been an update to the application?
- Are you aware of any changes in the infrastructure or on the servers?
2. Understanding the system
As well as understanding the behaviour in the application, we can start to get an overview of the system. Some of this will require input from the IT team:
- What version of the application is in use?
- How is the client deployed to users? (ClickOnce, or via MSI)
- Are IIS and SQL Server on the same server, or separate servers?
- Are the servers physical or virtual, and if virtual then what is the virtualisation platform?
- Where are the servers located?
- What OS is being used for the server(s), and the client PC's?
3. Gathering information (configuration, logging)
We will want to get some basic system information, and this will require IT's assistance:
Application service configuration
| Information | How to find |
| The application service config |
Normally found on the application server at: \inetpub\wwwroot\PentanaPRD\Service, this file is called Web.config
Note that this file might contain a database user/password, so please check and mask with ***** |
| The Robot service config |
Normally found on the application server at: \Program Files (x86)\Pentana\ServerRobot\PentanaPRD, this is called ServerRobot.txt, this file is called Pentana.Tng.ServerRobot.RobotService.exe.config
|
| The client config |
Normally found on the application server at: \inetpub\wwwroot\PentanaPRD\Client\XtraDeploy, this file is called vision.exe.config.xml
(Note that if the client is deployed via MSI then we would want to see the file vision.exe.config from that deployment) |
| The WebService config |
Normally found on the application server at: \inetpub\wwwroot\PentanaPRD\WebService, this file is called Web.config
|
| The WebUI config |
Normally found on the application server at: \inetpub\wwwroot\PentanaPRD\WebUI, this file is called Web.config
Note that this file might contain a database user/password, so please check and mask with ***** |
Logs from the application server
| Information | How to find |
| The application service log file | Normally found on the application server at inetpub\wwwroot\PentanaPRD\Service, this is called PentanaTngService.log |
| The Robot log file | Normally found on the application server at: \Program Files (x86)\Pentana\ServerRobot\PentanaPRD, this is usually called ServerRobot.txt |
| IIS logs for site, for the last 7 days | These are the standard IIS logs for the application server, normally found at a path like \inetpub\logs\LogFiles\W3SVC1 |
4. Gathering information (configuration, logging)
Logs from the database server
| Information | How to find |
| SQL Server event/error log | Found on the database server, normally at a path like \Program Files\Microsoft SQL Server\MSSQLxx.MSSQLSERVER\MSSQL\Log. The files are called ERRORLOG.* |
Information about the database
Sometimes we will also want to know some basic information about the database:
| Information | How to find |
| Application system information | At the database, run the attached script Ideagen Internal Audit (Aura) - query for system information.sql |
| Information relating to index fragmentation | At the database, run the attached script SQL Server - Check fragmentation across all indexes.sql |
| SQL Server's record of expensive queries | At the database, run the attached script SQL Server - Pinal Dave's Expensive Queries.sql |
| SQL Server's index recommendations | At the database, run the attached script SQL Server - Find Missing Indexes (RedGate).sql |
Note: The scripts relating to database indexes are simply outputs from the SQL Server engine, they are not necessarily useful within the context of the application, but might help us understand performance bottlenecks.
Once we have available the information shown above we can analyse and begin to plan further diagnostic activities.
A note on sharing files
This information will consist of a number of large files. If files are to be shared with Ideagen, it will be better to use a file sharing system such as Dropoff rather than use email.
Diagnostic scripts
Attached below are the diagnostic scripts referenced above.