1 2 3 Previous Next

Web Performance Management

42 Posts

The Engineering team at WPM has recently built the capability to directly log tickets into Service-Now from the Advanced Alert scripts.

 

A sample script would look something like the following:

 

var client = neustar.httpClient();
var url = "API-URL";
var username = "USERNAME";
var password = "PASSWORD";
var contentType = "application/json";
var headers = {'Accept':'application/json'};
var data = {'col_1: val_1', 'col_2: val_2', 'col_3: val_3'};
httpResponse = client.post({'url':url,
                                                               'data':data,
                                                               'username':username,
                                                               'password':password,
                                                               'headers':headers,
                                                               'contentType':contentType });

Resulting in the following incident within your Service-Now portal

Incident-updated.PNG

 

To setup within WPM and verify

 

  1. Go to Advance Alerting tab replace existing script with attached one.
  2. Click on set input and hit validate. It will trigger alert and also create an incident in Service now.
  3. Inside alert mail you can see service now response JSON. Pick up incident number from response(Highlighted the same in following mail).
  4. Now login Service now with following credentials.
    • url= "API-URL"
    • username="USERNAME"
    • password="PASSWORD"
  5. Go to incident table and search for incident id.
  6. Incident table should show record for received JSON response incident number.

 

A sample email alert would like like

 

service-now-alert-1.png

The Advance Alerting APIs are documented here - http://docs.wpm.neustar.biz/alertpolicy-api/annotated.html

 

Please let us know if you have any questions.

Shane Barbetta

Portland Agent Update

Posted by Shane Barbetta Oct 15, 2015

We have updated hosting providers in Portland and provisioned new IPs.

 

OLD IP Address: 208.72.116.130   => New IP Address:  69.163.33.116

 

OLD IP Address: 208.72.116.131    => New IP Address: 69.163.33.117

 

New Service Provider for these IPs: 69.163.33.116 , 69.163.33.117 Pivotal Space

 

Old Service Provider for these IPs: 208.72.116.130 and 208.72.116.131 PDXhosting 

Greetings!

 

At the beginning of 2016 we'll be deprecating the BrowserMob (Selenium 1.0) test script API in lieu of our more current, actively-supported Selenium-WebDriver bridge. You may have some older scripts using the folowing.

 

var selenium = browserMob.openBrowser();

 

In order to switch to Selenium 2.0, change that line to...

 

var driver = test.openBrowser();
var selenium = driver.getSelenium();

 

There's a known bug with the legacy API that arose out our most recent release, and load tests using Selenium 1.0 are sometimes not performing transactions. If you run into this problem, please contact support@wpm.neustar.biz. We'll be patching the bug temporarily, but removing the API in it's entirety starting January 1st, 2016.

Shane Barbetta

Tampa Agent IP Update

Posted by Shane Barbetta Aug 29, 2015

We have updated the IP addresses for our Tampa agent hosts.

 

Old IP’s:                   New IP’s:

208.38.164.61     209.133.212.228

208.38.164.67     209.133.212.229

Shane Barbetta

New LA Agent IPs

Posted by Shane Barbetta Aug 7, 2015

We have upgraded our LA agents and assigned new IPs.

 

Old IP’s :                                  New IP’s:

199.188.146.133 ==> 104.200.135.183

199.188.146.138 ==> 104.200.135.184

199.188.146.143 ==> 104.200.135.185

199.188.146.148 ==> 104.200.135.186

199.188.146.153 ==> N/A

The REST API is an often underutilized feature that provides a powerful and versatile medium for managing scripts, monitors, load tests and various aspects of the WPM application. In the following repository I've assembled a simple Python client for creating REST calls and loading the response into an easily-parsed JSON object.

 

https://github.com/neustar/wpm_api_client

 

Installing the Client as a Package

 

The current packaged version (at the time of writing this post, 2.1) is registered with PyPi. Use the following to install and maintain your package with pip.

 

pip install wpm_api_client

 

The client is compatible with both Python 2 and 3.

 

Setup an API Connection

 

First we create a connection object using our API key and secret. This can be found by logging in to the WPM Home interface and navigating to My Account > Users > Manage User.

 

import wpm_api
c = wpm_api.Client('my_api_key', 'my_secret')

 

Test the Connection

 

You can test your connection using the Who Am I? or Echo methods in the Load Testing API. Try the following.

 

account_info = c.load().who_am_i()
print account_info

Note: print(account_info) in Python 3.

 

The output will be a serialized JSON object, like so.

 

{u'data': {u'username': u'your_username'}, u'result': u'OK'}

Note: Python 3's print function is a bit nicer and will print out the deserialized JSON. It is a JSON object, nonetheless.

 

With this we could also do.

 

print account_info['data']['username']

 

Which will return, simply, 'your_username' as a string. Or...

 

import json
print json.dumps(account_info)

 

For a string containing the response's raw JSON output.

 

Some Additional Examples

 

Creating a New Basic Test Script and Adding It to a Monitor

 

The script endpoint method will generate a basic test script which monitors a given url. It requires 1 argument.

 

new_script = c.script().endpoint('https://home.wpm.neustar.biz/')
print new_script

 

Your response (new_script) will be an object containing the result ('OK') as well as a script 'data' object. To create a monitor, there is a sequence of optional arguments in addition to several optional keyword arguments, required being name, interval and locations. The test_script argument is required in non network-type monitors. Let's create a monitor named 'Example Monitor' using our new test script. We want it to run every 5 minutes from Washington, DC.

 

new_monitor = c.monitor().create('Example Monitor', 5, 'washingtondc', test_script=new_script['data']['script']['id'])

 

We now have an object with the id of our new service. If we wanted to edit that existing service, we would need to supply the ID to the monitoring API. For example, let's add a description.

 

print c.monitor(new_monitor['data']['items']['id']).update(description='An example monitor for home.wpm.neustar.biz')

 

Your output should look as follows.

 

{'data': {'items': {'updated': 'your_monitor_id'}}}

 

For a full list of monitoring methods check the Monitoring API docs or refer to the comments in monitor.py.

The Detroit, MI agent is back online with a new set of host IPs. Please update any necessary whitelists.

 

Again, we apologize for the inconvenience. If you have any questions, please contact the Web Performance Management support staff.

 

 

OLD IP: 162.217.178.68

NEW IP: 162.217.176.122

 

OLD IP: 162.217.178.69

NEW IP: 162.217.176.123

Monitoring from Detroit, MI is offline for maintenance until further notice.

 

We apologize for any inconvenience and will update this post when the service has been restored.

Shane Barbetta

WPM Home Maintenance

Posted by Shane Barbetta Feb 19, 2015

Greetings,

 

We are performing emergency maintenance on https://home.wpm.neustar.biz/ at this time and will update this post once connectivity has been restored.

 

Please note, monitors jobs and alerting are not affected and will continue to run as normal.

 

We deeply apologize for any inconvenience.

 

Shane Barbetta

Neustar Customer Support

Currently we are experiencing issues with on demand load testing. We are reviewing the issue at this time and are working to return services to normal as quickly as possible. We apologize for the inconvenience.

At this time the Salt Lake City agent is currently off line. We are working to restore the Salt Lake City agent to service as soon as possible.  We will provide an update once the Salt Lake City agent is available again.  We regret any inconvenience this may have caused.

We're currently experiencing temporary login issues with the WPM Home website. Monitoring and load testing applications are not affected. We will post a status update once service has been restored. We apologize for any inconvenience during this time.

At this time, the Buenos Aires agent is currently off line. We are working to restore the Buenos Aires agent to service as soon as possible.   Again, we do apologize for the inconvenience and appreciate your patience on this issue.  In addition, we will provide an update once the Buenos Airesagent is available again.

At this time the Paris agent is currently off line. We are working to restore the Paris agent to service as soon as possible.  We will provide an update once the Paris agent is available again.  We regret any inconvenience this may have caused.

Emulated Mobile Monitoring

Posted by Mark Watson Apr 22, 2013

We often get asked how WPM can monitor mobile websites.  The standard answer has been to script an HTTP request intercepter to change the User-Agent content header to be the same as a mobile browser.  This works in some cases, but has a number of drawbacks.

 

  • To the webpage's JavaScript the browser still appears to be Chrome or Firefox and may not trigger the loading or layout of the mobile website.
  • The features available to the webpage may be different from the mobile device.
  • The screen resolution and page layout don't match real devices.

 

Our solution to this is to use a custom browser, where we can have a high degree of control over the browser features and rendering.  We use a custom build of PhantomJS to emulate Android Chrome and iOS Safari.  The same WebDriver scripting API we use with Chrome and Firefox works with our emulated browsers, thanks to Ivan De Marino's excellent WebDriver implementation for PhantomJS.

 

This approach allows us to match the rendering of real devices quite closely.  Matching the rendering is necessary as it verifies that we are loading the same site and content as a real mobile device.

 

 

Here's example screenshots of google.com rendered with different device profiles:

 

google.com on iPhone

iPhone_screenshot.png

 

google.com on iPad

iPad_screenshot.png

google.com on desktop Chrome

chrome_screenshot.png

 

On the other hand, many sites do not have dedicated mobile content and display the essentially the same on Mobile devices as they do on desktops with larger screens.  In this case the device browser gives the web page a virtual screen width of 980 pixels to render into. The page is then scaled down to fit on the real device screen (Note: Or it could be scaled up depending on the native resolution of the device e.g. Retina iPad has a higher resolution than many desktops and the content is often scaled up so it doesn't appear too small).  The page may overflow the 980 pixel limit, if it does the content is cropped and the user must scroll the page to see the rest of the content.  Here's an example of a page rendered at a virtual screen width of 980:

 

apple.com on iPhone

iPhone_apple.png

 

apple.com on desktop Firefox

firefox_apple.png

 

 

Features

 

Here's a short feature list:

 

  • Android Chrome and iOS Safari can be emulated via several device profiles:
    • iPhone (Retina)
    • iPad (Retina)
    • iPad Mini
    • LG Optimus G
    • HTC Droid DNA
    • Samsung Galaxy S3
  • Screen layout & rendering match mobile devices.
  • Touch event support.
  • Emulated Mobile Monitoring is available from all locations.
  • Existing Selenium/WebDriver API is supported.

 

 

Walkthrough

 

All WPM accounts have access to Emulated Mobile Monitoring.

 

Writing your monitoring script follows the same workflow as existing desktop browser scripting.  To validate a script in a mobile browser, select the browser type from the browser drop down and click revalidate/validate.

 

script_editor.png

 

After the job validates, a screenshot of the webpage will be displayed (note this does not include the surrounding graphics of the mobile browser, the screenshot is equivalent to the browser in fullscreen mode).

 

Once the script has validated, it can now be used in a Monitor.  Either create a new Monitor or edit an existing one to bring up the Monitor Settings.  From here an emulated browser can be selected from the "Select Browser" drop down.

monitor.png

 

Note: Each sample costs four monitoring units just like regular browser monitoring.

 

Local Script Validator

 

Local Script Validator can be used to run the emulated mobile scripts locally.

 

 

Browser
Device
Opti´╗┐on
SafariiPhone 5iPhone5-emu
SafariiPad RetinaiPad-emu
SafariiPad MiniiPadMini-emu
ChromeLG Optimus G

OptimusG-emu

Chrome Samsung Galaxy S3SamsungS3-emu
ChromeHTC Droid DNADroidDNA-emu

 

E.g.

 

  validator -browser iPhone5-emu myscript.js

 

Limitations

 

  • Emulated Mobile browsers are not (yet) available for Load Testing.
  • Differing WebKit versions.  The version of WebKit in PhantomJS differs from the version on real devices.  This sometimes causes problems with some of the more recent WebKit features.  We are in process of upgrading to a newer WebKit version.  But for now the versions are:
    • PhantomJS WebKit: 534.34
    • iOS 6.1 Webkit: 536.26
    • Android 4.1.1 Webkit: 537.22 (534.30 builtin)
    • Android 4.2 Webkit: 537.22
  • Differing sets of plugins.
    • PhantomJS: None
    • iOs: QuickTime
    • Android: Flash, PDF reader.

 

Links

 

 

 


Filter Blog

By author: By date:
By tag: