In this post we’re going to discuss a few performance optimisations which can be made to Burp Suite, notably the Java Virtual Machine (JVM), which considerably increases performance and can drastically reduce the amount of time taken on an engagement.
Make sure that you are using the latest Java version available as the latest versions generally have better performance than any previous version, as well as the all important security patches, this is probably one of the biggest gains you can make.
TLDR – Apply the below config file, see Burp Suite performance increase by about 30%
We generally see better Burp Suite performance with the 64 bit JVM.
All these options have been tested on Windows only, although we see no reason why they should not work similarly on Linux and OSX systems, we would be interested to hear of any incompatibilities or other problems on other systems.
Before we delve into the specific options it’s worth noting every installation will be different, please be aware in certain situations these tweaks may reduce performance or even break the software. In most cases these settings can be applied as-is and will offer a considerable performance increase however please be responsible and back up all of your settings before applying. Feel free to benchmark this yourself and please report your findings back to us, we’re always interested in other experiences.
The Burp Suite Tweaks
Burp Suite is a Java application and as such, requires the JVM to run. The settings below can be applied either when spawning burp with the CLI or in the BurpSuitePro.vmoptions file which lives in “C:\Program File\BurpSuitePro\” on Windows. In our configuration file we only include known safe configurations although further optimisation is possible.
- server – Using server will make the application start up slower, however it will increase the overall performance of the application, this should be the default when using a 64 bit Java instance however it does not hurt to enable it anyway.
- Xms – Specifies the initial heap memory allocation, this shouldn’t be set to the same as Xmx to allow for smaller testing scenarios, and to avoid RAM wastage.
- Xmx – Specifies the maximum heap memory allocation for the JVM, often this should be 75% of your overall RAM, however be aware that using sizes over 16GB may actually reduce performance due to garbage collection having to clear a lot of space on each sweep.
- DisableExplicitGC – By default calls to System.gc() are enabled (-XX:-DisableExplicitGC). Use -XX:+DisableExplicitGC to disable calls to System.gc(). Note that the JVM still performs garbage collection when necessary.
- UseTLAB – This should have been enabled by default from earlier Java versions, but we force this to be sure it’s on. Uses thread-local object allocation blocks. This improves concurrency by reducing contention on the shared heap lock.
- UseThreadPriorities – Enabled thread priority, please see this excellent blog post for further information.
- AggressiveOpts – These will be enabled by default in newer Java versions, but we force this to be sure it’s on. These options enable additional optimisations in the compiler.
- UseFastAccessorMethods – This has been removed from later Java versions because it could generate bad JIT code, please benchmark yourself.
- UseLargePages – You may find this makes your system slower if you use a lot of memory because Windows will have to move memory around to make a contiguous portion of memory, this effect will be worse the longer the system has been running. To enable Large Page support on Windows you need to enable page locking on your system, You will find the option in the Group Policy editor, you will need to restart your system after applying this.
- OptimizeStringConcat – This should have been enabled by default from earlier Java versions, but we force this to be sure it’s on. These options enable additional optimisations in the compiler.
- ReservedCodeCacheSize – This controls the size of memory where JIT’d code is stored, make it larger just to be sure we’re storing as much code as we can.
- UseCodeCacheFlushing – This should have been enabled by default from earlier Java versions, but we force this to be sure it’s on.
- UseG1GC – This will instruct the JVM to use the new G1GC Garbage Collector, which should be more efficient than other garbage collectors in our testing. Other collectors may be better suited for your situation so please benchmark this yourself.
- UseSSE – Although there will probably be limited use for this option we enable it to provide any possible performance improvement, please make sure your CPU supports the SSE instructions set you pick.
- UseStringDeduplication – This option requires G1GC to be enabled for it to have any effect, it will make multiple identical strings in memory point to the same location, saving some memory.