Performance Analysis in Invicti

What Action to Take

Server Performance  

Log in to the target web application’s server and database server to ensure that the CPU load is in the expected range. If it’s unexpectedly high, stop the scan until it’s back to the normal CPU load. Then test different engines and URLs separately to identify which part of the application is causing the problem, and fix it.

Connection Between You and the Target Application

If your internet connection, or the connection between Invicti’s system and the target web server, is slow, your scan will be quite slow. Invicti carries out lots of requests. So, if the target application’s response time is slow, there is not much you can do (other than finding a faster connection or optimizing your scan settings).

There are a couple of ways to do this:

• Visit the website and see if it’s obviously slow
• Use Fiddler to look at response times
• View the information in Invicti’s Request/Response tab (see Viewing the HTTP Request and Responses of an Issue)

Alternatively, scan our test application at http://aspnet.testsparker.com/ to help gather information about the network performance. If your scan performance is good for http://aspnet.testsparker.com/, but bad for your application, it means it's either the connection or something specific to the target application. For other test environments, please visit www.testsparker.com.

Client-Side Performance Issues

The easiest way to check for this is to open your computer's Task Manager and watch Invicti’s CPU usage. If it’s too high during the Crawling stage, do the following:

1. Open Invicti Standard
2. From the Home tab (while a scan is running), select Scan Policy Editor. 
3. Select JavaScript. 
4. Deselect Analyze JavaScript / AJAX. (Please note that, in order to change this setting, a new policy should be created or one of the default policies should be cloned because Invicti’s default policies are read-only).

This will speed up the scan, though it’ll decrease the crawling coverage if the website includes lots of JavaScript and AJAX code.  

If CPU usage is also high during the Attacking phase, and if this is not happening in any other website, it’s possible that Invicti can’t handle a certain code in that web application. Please report this to us, so we can investigate the problem in detail and address it, or offer you a solution. You can also check the Scan Performance and Slowest Pages nodes in the Knowledge Base panel to see how different security check engines are behaving.

URL Rewrite Configuration  

If your website has extensive URL Rewrites, you can configure it manually (see How to Configure URL Rewrite Rules in Invicti)

Heuristic URL Rewrite is generally good enough, but it might not pick up your rules as quickly as manual configuration.

Scan Policy Optimization  

Ensure that you have optimized the policy with the optimization wizard for your environment (see Automatically Optimize Scan Policies for Quicker and More Efficient Scans).

DOM-Based Cross Site Scripting (XSS) Checks  

DOM XSS can be extremely slow, especially in large, complex pages. After optimization, you can disable this in your Scan Policy. You can do this by going to Scan Policy Editor and unchecking Cross-site Scripting (DOM Based) (see Automatically Optimize Scan Policies for Quicker and More Efficient Scans).

Also, remember to select this optimized policy in the Start a New Website or Web Service Scan dialog, when starting the scan.

Overall, these should help you fix the performance issues, and we are also happy to take a look at your scan or website to suggest a more precise configuration.

Number of links crawled

The Crawled URLs List report will help you to diagnose performance issues. For example, if there are dozens of similar repeating requests with the same set of POST parameters, the Recurring Parameters option would help eliminate those redundant requests.

For further information, see Lists.