Frequently asked questions

Physical distance doesn't matter as much as connectivity speeds. See network benchmark: Production topology example. There are a number of factors that make comparisons of that nature difficult to determine. For example, firewalls, proxies, intrusion detection systems, available bandwidth etc. We have great bandwidth between our servers in Ottawa, Canada and the demo.testfire.net web application which is hosted in Texas, USA. Looking at network activity, we can see on average about 190kb/s. We have a similar site installed on our LAN where a scan shows on average 160 kb/s. In this case, distance makes no difference but bandwidth does.

Very important. Slow connectivity results in slow AppScan performance. The bigger pipe with as little latency as possible is ideal.

Very important. The recommended minimum system requirements are essential and depending on the number of users and scans being run additional DAS servers, RAM and CPUs will improve performance. View the system requirements: Hardware and software requirements.

Important for starting the scan and post processing, but once the scan is running, then the DAS is hosting the scan data until the scan is complete. Communication between Agent and DB is requesting job setting at the beginning, updating DB with job status and populate DB with scan result. Separating the machines by states or countries is not recommended especially for Control Center and DB. This can cause db timeouts. We suggest they be as "close" to each other as possible.

Very important for post processing and running reports. The amount of communication is highest when consuming reports.

We have not seen any difference using a VM vs. a physical machine in our lab.

No, AppScan® Enterprise adheres to the HTTP 1.1 standard. It should not significantly degrade web server performance and should not be deployed on the web server itself, but on a separate computer that can view the website and perform a scan from there. The reason it does not degrade performance is based on the fact that, just as any other visitor or crawler crawls the website, the web server sees this as only one user visiting the website. However, if you experience slow response times, you can limit the number of links that processes simultaneously or schedule scans after peak operating hours.

Traffic log hits will increase because every URL on the entire site is requested during scanning. However, the run should be recorded as only one visit to your site. Also, many usage analysis tools enable you to filter out these hits to not affect your traffic counts. You can also change the user agent that you are using when scanning so that you can easily filter it from your traffic statistics.

Yes. You need to specify the address of your proxy server in the Proxy settings of your system.

The agents should not be installed outside your LAN because they probably will not be able to see the database behind the firewall.

Yes. To access password protected pages you need to configure your user name and password in the Connection Options window. Secure Socket Layer (SSL) is a form of communication in an HTTP environment; when entering a secure area, the HTTP protocol will become an HTTPS protocol, showing that there is encryption in use.

Scanning performance (measured in links checked per minute) tends to diminish as the size of the website increases.

When scanning large websites, consider breaking the site up into smaller chunks and scanning each one separately. If you have a very powerful database server, consider breaking the scan up into a number of small jobs and running them simultaneously.