Web Performance Management FAQ

What is Neustar Security Web Performance Management?

Neustar Security Web Performance Management (WPM) is a cloud-based service that provides monitoring and load testing of customer web sites/services/APIs. The service is based on the Selenium open source platform and uses JavaScript automated scripts. Customers can monitor/test for availability, SLA adherence, functionality, or other metrics using scripts they write themselves or by working with Neustar’s professional services team.

What format does WPM use for scripting?

Neustar Security WPM uses native JavaScript to drive Selenium and WebDriver scripts. This means a full JavaScript environment is available to both your scripts, giving you full control over what the browser executes on your website, web service, or API.

What if I don’t know how to code?

Neustar Security can provide professional services to get your monitor or load testing service up and running. Contact us for more information.

What do I need to get started with Selenium scripting?

Some very useful (but not necessary) tools for scripting include:

  • Firebug (http://getfirebug.com/)
  • Xpath Finder (https://addons.mozilla.org/en-us/firefox/addon/xpath-finder/)
  • Web Performance Management Local Validation Service
  • An IDE or text editor

Script validation failed, now what?

Every time you attempt to validate a Real browser user script, a screenshot is captured (Basic scripts do not generate screenshots) and the validation results are updated. To see the results, simply click the “View Validation Results” link from the script editor page. If there was a problem executing the script, or validation failed, a message will appear at the top of the results dialog along with the line number on which the error occurred. Use this information to debug your script and then retry validation.

You can add additional logging anywhere in your script using “log(‘message’)” These messages will show up at the bottom of the validation results dialog. Tip: log messages are useful for tracking variables and unique values as well as key execution points.

What is the process for converting an Real Browser User (RBU) script to a Basic script?

In order to covert a script from RBU to Basic, the RBU script must first be validated using either the online or local validator tool. Once validated, open the script in the Webmetrics-WPM online script editor and click “Generate Basic Script.” This will create a script that makes all the same requests as the validated RBU, but replayed as simple HTTP GET/POST requests instead of using a real browser. Converted scripts can be used for both website monitoring and load testing.

How long does the validation process allow a script to execute, what if more time is needed?

The validation process allows a maximum execution time of two minutes. However, there is no time limit on script execution in load tests. If you are attempting to validate a long-running script that is intended for load tests only, there are a couple of options available. The first is to look at the amount of pause time in the script. If the script is using long pause times, the “isValdation()” method can be used to reduce the amount of time spent paused during validation. Here is an example:

//Pause for 2 seconds in validation
test.pause(2000); }
//Pause for 20 seconds during load test

If, even after using "isValidation()" to reduce pause time, you’re still running past the two minute limit, you will need to use the local-validation service. As with a load test, there is no time limit for script execution when using the local-validator. Once you have verified the script works as expected on your local machine, upload the script and check the “Bypass Validation” option in the script editor. Finally, it’s advisable that you run a small load test to ensure the script behaves as expected.

My Basic script failed validation after converting from a valid RBU script. What happened?

Basic scripts are built from the recorded HTTP traffic generated during validation of the original RBU script. But as is often the case, the HTTP traffic might be different on every run of an RBU script (e.g. ads, ajax, etc.). Basic scripts replay the same requests every time, and expect the same response codes.

The most common error is the converted script expecting 3xx response codes, but seeing 200 instead (http://en.wikipedia.org/wiki/List_of_HTTP_status_codes).This is usually caused by ads, which originally redirected to register a unique impression. When the converted script attempts to replay the same request, it is caught by the ad server as a duplicate, and the response is altered to prevent additional (false) ad impressions. The fix is as simple as removing the faulty requests, or changing the expected response code to what was actually returned. For example:

c.get("http://example.com/ad?req=12345", 301); 

Change to:

c.get("http://example.com/ad?req=12345", 200);

The second most common issue is content from third party domains. The blacklist requests directive from the original RBU script will not be maintained in the Basic script. Our recommendation is to remove any third party requests from the script. Here is an example of requests that would be removed:

c.get("https://connect.facebook.net/en_US/all.js", 200);
c.get(https://ssl.google-analytics.com/ga.js", 200);

Under DDoS Attack? Relief Begins Here!