Sep 15 2015
This release includes several bug fixes for mPulse:
97169 Update product tour welcome screen to 14 Day Trial
96619 Page-load mismatch issue on What-if Dashboard
96080 Network Errors metric should be available to Web domains as well as Mobile (if in the template)
95775 Fail with 400 and descriptive JSON when an invalid parameter is found
95518 Single aggregated value for multiple page groups in the Query API
94089 Session length should be shown with decimals
87758 JSON API response is invalid for data series
For more information about the fixes for Query API, see mPulse Query API.
Aug 28 2015
This release includes several bug fixes for mPulse:
96645: Alert with "On a specific date and time" does not fire after the date/time changes
96578: Don't set manufacturer to "Apple" for desktops
96500: Alert is cleared even when the condition is still met
95489: Alert filters on OS Family and Browser Family do not work
91683: Changing (every time interval) alert start date/time does not trigger it again
Continue with Update
As of SOASTA 55.14, you can continue updating the system if you have background procedures marked as busy.
The new Continue anyway button has been added to the following About SOASTA CloudTest & TouchTest (build) screen:
You will need the following:
Find more information on how to setup Azure, click here
Add 'vhds' container on Storage
name = vdhs
Access = Public Container
Copy image files
By default, mPulse captures full page loads, not Ajax requests (XMLHttpRequest) from a loaded page. However, you can easily enable mPulse to retrieve and display Ajax requests.
To enable XHR:
To filter XHR beacons in dashboards XHR:
App Admins can define dimensions to track on each beacon. Beacon-level dimensions can be defined using one of six supported pattern-matching techniques, or value types found in the Configure Apps box, Advanced view, Dimensions tab.
SOASTA recommends defining dimensions on value types that have relatively few possible values. With that in mind, a good example is a dimension used to track free and paid users on a domain.
Dashboard performance may decrease if a custom dimension returns more than 100 unique values. So, categorical dimensions work well because they can only return a limited number of possible values.
Identity-tracking dimensions, however, are riskier for performance because they can return millions of unique values. Displaying a list of 1 million values in a dashboard will take longer to load and analyze than a list of 100 values. Examples include: user ID, session ID, and username.
Tenants are each limited to 10 custom dimensions.
Within individual dimensions, an alias map can be used to create user-friendly values for display in dashboards.
The App Administrator can use any of the following Value Source techniques to define a dimension:
No matter which type you choose, the value is extracted on the client side (inside the browser).
Some custom dimensions only apply to a portion of your website. In those cases, you can limit the set of URLs for which the dimension value will be extracted, using the "URL Pattern" input. For example, if a custom dimension only applies to the online store portion of your site, the URL pattern might be
Note that URL patterns are not regular expressions. Their syntax is limited to asterisk wildcards.
Dimensions may be of three (user facing) types:
In some cases, the actual value extracted at runtime is not the value that you want to display in dashboards. For example, let’s say you’re setting up an "Account Type" dimension, whose values are "Free", "Pro", or "Enterprise". The value will be extracted from a cookie, but it turns out that the cookie uses internal codes, like "f", "p"and "e".
You can define an Alias Maps to translate the internal values collected in the browser to "user-friendly" values that will be shown in the mPulse dashboard and alert UIs.
For example, a simple Alias Map for user authentication status plus user type might be defined using the following user-defined values and aliases (with the numeric dimension type):
For the map defined above, mPulse will get the numeric value and place it on the beacon, save that value to the database, and then display the user-friendly alias in dashboards (e.g. as Logged Out, Logged In Lite User, etc.).
XPath matching works similarly to the matching presented in mPulse via the Metrics tab and can also be filtered by URL pattern. When this value source is selected, define an Xpath from which to match.
For example, a news site might create a custom dimension called "Market Vertical," which uses XPath to pull the type of news content that the user is currently viewing.
URL matching works similarly to the matching presented in mPulse via the Page Groups tab and can also be filtered by pattern.
For example, an ecommerce site might create a custom dimension called "Product Type" that uses a Regex capture group to pull the product type from a URL, and a replacement value to capture the specific product value, such as hammer.
Query Parameter matching works similarly to the matching presented in mPulse via the Page Groups tab. When this value source is selected, define a query string parameter from which to match. The URL used here must have a query string (e.g., a "?" that precedes the non-hierarchical data that follows).
For example, the Query Parameter value source can be used to pull the value of the common query parameter, referrer.
Cookie matching works similarly to the matching presented in mPulse via the Page Groups tab.
For example, many e-tailers store the marketing campaign value(s) that resulted in a web site hit. Using the Cookie value source to define a custom dimension, we can extract that information from a cookie named details, and then get the campaign name using a replacement value.
User Agent matching works similarly to the matching presented in mPulse via the Page Groups tab.
For example, a physical retailer may have specialty in-store kiosks whose user agents (e.g. browsers) are identified by a kiosk-code such as "kiosk-code:5869:". In such a case, mPulse can capture this user-agent string from their internal site's instrumentation.
The SOASTA mPulse™ service relies on the mPulse Boomerang. In general, the latest mPulse feature set will require the Boomerang developer alongside those features. The mPulse team also works hard to ensure that mPulse can work seamlessly with earlier Boomerangs. The following Boomerang Support Policy presents update guidelines, including posted expiration dates for each Boomerang version listed.
SOASTA will notify customers running an older Boomerang version of any necessary Boomerang updates at least one month prior to the retirement date of that version. After notification, and whenever an old version is retired, apps running that version will be migrated to the latest GA version.
Customers are encouraged to work with us to schedule an upgrade to any latest GA version prior to the migration date.
In general, the latest GA version will always be necessary to experience the latest Boomerang/mPulse features, and so users are encouraged to schedule an upgrade at their earliest opportunity.
The latest GA version will be supported for a full year after the latest GA version release. At that time, we will require you to upgrade to a newer version in order for us to continue to process your beacon traffic. The mPulse team will follow up with additional communications as the end-of-life date for any Boomerang version approaches.
Every loaded Composition has an "Alpha" (or controlling) Maestro also sometimes known as the "Main" Maestro.
This Alpha is not a hard-coded server, but is chosen from among the Maestro servers involved in the Composition. The Main Maestro is the server that you don't want rebooting unless necessary, and don't want to crash, as it will leave the other servers (known as the "Remote" servers) orphaned.
Users can force the Alpha Maestro to be a specific server by choosing it in the Play Options box, Maestro drop-down (accessible from the Composition Editor's Etc (…) drop-down menu.
Using the Play Options box, users can override various settings about the Composition including the Main Maestro in use. Note that these changes are not persisted, they are for this play only. Once the Composition Editor is closed, Play Options settings are gone.
By specifying a Maestro here, when the Composition is loaded, CloudTest will try to load it there, rather than searching for the first suitable server that it can find based upon the configuration of Tracks in the Composition.
The Alpha server must be one that the Composition would normally play on, because the Alpha server is not strictly just a "controller" it also plays one Track itself, just like any other server. Accordingly, the server specified using Play Options must be among those that the Composition is already configured to play on. For example, if the Composition's Tracks specify that they are to played in Location 1, then the user can't force the Alpha to be on a server in Location 2.
If a new Alpha server is specified, then if it is successfully loaded on the server you specified, that server will become the Alpha.
The only reason I can see for doing this is if you know some server or location is generally more stable or reliable than others, and therefore you want the Alpha to be there. Or perhaps because you don't want to search Player Status to find the Alpha (although that is not that difficult).
For example, in the following shot the Composition is set up to play Tracks on servers A2, A3, A4, and A5.
Use the following steps to update the list of monitored servers from a build:
<Hosts><!–– INSERT host XML here ––></Hosts>
Dynamic Host Monitoring
1. Do the above steps
2. By default Monitoring requires Conductor. To override that you need to do the following
On the appliance(CTMain), edit the file (or) if you don’t have one create it.
$sudo vi $JBOSS_HOME/server/all/conf/props/soasta.propertie
Add the below line and save the file
3. Create a parameter in Jenkins as pass the server name[s]. For example below the "Monitor_Hostname" parameter contains multiple server names by comma separated
4. The below Shell script splits the Monitor_Hostname[s] by comma and append the respective xml tag in the exported Monitor Server Groups XML
5. Make sure the shell script and exported Monitor Group xml files are in the Jenkins’s workspace. See example below
6. Call the shell script in Jenkins, Import the modified XML before play the composition
7. Jenkins executes the shell script, imports and executes the composition
8. Here is the sample dashboard
The mPulse™ Boomerang AngularJS plugin allows users to automatically monitor their Single Page App's (SPA) navigations beyond the initial page load.
In SPA apps, only the first page that the visitor loads is a full navigation. All subsequent navigations are handled by frameworks like AngularJS, where it dynamically pulls in the content it needs to render the new page, without doing a full navigation.
Boomerang works well in the traditional, non-SPA scenario, where a full navigation occurs. On each page load, it tracks performance information about the entire page load experience. However, in SPA scenarios like AngularJS, only the first page triggers a full navigation. Thus, any subsequent pages your AngularJS visitors see to do not get tracked by Boomerang.
With the Boomerang AngularJS Plugin, Boomerang is able to track all of the SPA navigations beyond the first, initial navigation.
To do so, the Boomerang AngularJS plugin listens for several life cycle events from AngularJS, such as
$routeChangeStart. Once it gets notified of these events, the Boomerang AngularJS plugin starts monitoring the page's markup (DOM) for changes. If any of these changes trigger a download, such as an XHR, a new image (IMG) getting inserted, or new CSS (LINK) being fetched, then the Boomerang AngularJS plugin monitors those resources as well. Only once all of these new resources have been fetched does Boomerang AngularJS consider the SPA navigation to be complete.
The following code snippet initializes the plugin and should be placed in your Angular app or module startup.
The Boomerang AngularJS plugin does not require any additional instrumentation of your app, its clicks or URLs, nor does it require any additional directives or markup changes.
If you do not have run block:
Add the following lines for code as well the Integration Code mentioned above.
If you have a run block, but no rootScope dependency:
Add the following lines of code, insert '$rootscope', and the Integration Code mentioned above.
If you have a run block, with a rootScope dependency, but not the integration code:
Add the following lines of code, and then insert the Integration Code mentioned above.
If your app or site includes both AngularJS and non-AngularJS pages, page-level overrides help to ensure non-AngularJS requests are not ignored. Page-level overrides alllow you to insert stand-alone snippets to programmaitcally monitor both Angular and non-Angular pages.
If all of your pages are setup using AngularJS,
If most of your pages are setup using AngularJS,
If only one or a few of your pages are setup using AngularJS,
The Boomerang AngularJS plugin gathers ResourceTiming data for all SPA navigations. ResourceTiming data contains performance metrics about all of the resources (IMG, CSS, etc) that were downloaded to construct the page (in supporting browsers). This data is used in the Waterfall dashboards.
Users should note that the Resource Timing API in use in browsers enforces an upper limit of 150 resources tracked. While this upper limit can be manipulated by the developer in order to track more resources (
window.performance.setResourceTimingBufferSize()), there are likely performance tradeoffs, and SOASTA doesn't attempt to make such impactful changes for the user.
For this reason, SOASTA provides the following additional code examples, which can be used to set and/or refresh the ResourceTiming buffer after each Boomerang beacon in order to ensure that beacons beyond the initial 150 are retrieved.
Because mPulse doesn't evaluate beacons until right before the beacon is set, Page Groups, Timers, and Metrics are tracked in SPAs using the same methods available in non-SPA apps (e.g. XPath, Regex, etc.).
Similarly, sessions are tracked the same in SPA apps as in non-SPA apps. The session length will increase every time the route changes and the session will be kept alive as long as user actions occur.
Applying the MakeAppTouchTestable utility to your Android or iOS project will make the following OS-specific project changes.
The MakeAppTouchTestable utility makes the following Android project changes when an app is made TouchTestable:
post_compile_touchtestBuilder to the project's Build steps – in order to instrument compiled classes.
/custom_rules.xml– in order to instrument compiled classes when built via ant.
intent-filterso that TouchTestAgent can launch the app for recording/playback
The MakeAppTouchTestable utility makes the following iOS project changes when an app is made TouchTestable:
URL Typeto the info.plist file in order to launch the app for recording and playback
Test Suite results contain a distinct master/child relationship that doesn't exist in results where no Launch Composition is involved.
For example, if Composition A contains a clip element that launches Composition B, then when Composition A runs it has a "child" result (from Composition B). Use the following steps to export the entire "Test Suite" result.
As usual, importing a test result relies on the existence of relevant test objects in the Import environment. It is a good practice to export the entire Test Composition with all of its dependant objects and import that into the new instance prior to attempting to import a test result.
Users can assign custom names to CloudTest's out-of-the-box metrics via the System Resources Selection page of the monitor wizard.
The new metric label is used in the coresponding Widget Title bar (e.g. JBoss will override the default title "Per Process CPU Percentage" in this example).
Users can now create Cloud Provider Accounts and launch Grids for the QingCloud vendor. QingCloud provides data centers in the U.S., Africa, Asia Pacific, and Europe.
Use the following steps to enter your valid QingCloud credentials as a CloudTest Pro Cloud Provider Account
The completed item appears in the Cloud Provider Accounts list in Central
When the Cloud Provider Account is saved, a new set of locations for QingCloud will be automatically created, if they do not already exist.
These locations must be specified during Grid Manager configuration of grids (as described below)
TFor more information about Locations, refer to Using Locations
Additionally, CloudTest creates all of the Server Classes supported by the QingCloud vendor.
SOASTA Instance Type
8 GB total RAM and 2 CPU cores
16 GB total RAM and 4 CPU cores
16 GB of RAM and 2 CPU cores
32 GB of RAM and 4 CPU cores
64 GB of RAM and 8 CPU cores
8 GB of RAM and 8 CPU cores
16 GB of RAM and 8 CPU cores
These Server Instance Types can be used in either Results Server or Test Server instances
Once a QingCloud Provider Account has been created for use with CloudTest, you are ready to create a grid that will provision servers via that cloud vendor
The Step 2 Server Instances page appears.
The Step 3 Summary and Deploy Tear Down page appears. Click the Deploy Instances button to begin launching servers.
Custom Commands can be used to create Custom Monitors in supported environments (all except Windows—support for which will be provided in the near future). Using this technique provides the ability to monitor runtime metrics (e.g. metrics whose value is not known ahead of time).
Custom Command monitors utilize an inline process call (entered into the provided Monitors box, text entry field) that executes a command inline or can refer to an external Shell Script accessible within the given environment.
Custom Command monitors require an agent, SOASTA Conductor, be in use as part of command configuration. This configuration is done using the existing Monitor UI, which now includes the Custom Command field, as well as a new Enable Custom Commands for Monitoring box is found in the SOASTA Conductor field, which appears in the Conductor Capabilities section under Allow Monitoring.
Both the Allow monitoring box, and the Enable Custom Commands for Monitoring opt-in box must be checked for subsequent monitor setup to succeed.
Once the opt-in boxes in the relevant SOASTA Conductor are checked, the remaining portion of the Monitor configuration follows the same workflow found in the setup of SOASTA-provided monitors.
Additionally, ensure that the Monitor Server Group's Connection Type has been set to the Conductor in use for the given host (e.g. as opposed to SSH).
If you're not yet familiar with CloudTest's extensive monitoring capabilities, refer to Creating Monitor Server Groups and Creating a Monitor before proceeding.
For example, create a shell script called apache_shared_mem. This script will get the sum of shared memory for apache processes on the given machine.
The Name (Optional) value appears on the Monitor dashboard (as noted above).
With the advent of the Globe Dashboard in this release, SOASTA is also introducing Activity Arcs; an exciting new, geo-spatial depiction of real load tests, in real time. Activity Arcs depict the flow of server data. from different data centers against the target site(s).
An Activity Arc depicts real-time data flow combining color (for error rate), width (for bandwidth), as well as other arc attributes including animation, gradient length, speed, height, and shape, in order to provide powerful visual reinforcement of the data flow in the test composition and in its result.
Two new System Dashboards—Globe Dashboard and the Dynamic Globe, display Activity Arcs. The Globe can also be added to new custom dashboards. Large screen displays are recommended and are the preferred vehicle for display of all SOASTA Globes.
The Globe Dashboard presents the test composition's data stream in one dramatic, three-dimensional, WebGL-based global format with fly-to animation, and other Globe features readily available by drop-down settings.
The Globe System Dashboard presents the CloudTest Globe in a wide layout where it can be combined with other widgets while also functioning as a background.
CloudTest users should note that the Globe's Settings are found in the upper right drop-down panels rather than in the Dashboard Editor lower panel.
Arc animation is enabled by default and can be disabled in the Globe's Activity Arc panel (covered in the following section).
Use the Widget-on-Widget Layout and Edge Constraints procedure to add Charts to your own custom Globe Dashboard.
Set your custom Dashboard Theme to Dark to improve the blending between your widget-on-widget layout and the Globe's Starfield.
The Dynamic Globe System Dashboard combines the Globe and Dynamic Ramp Controller into an exciting new, geo-spatial depiction of real load tests, in real time.
In the Dynamic Globe Dashboard, an Activity Arc depicts the flow of data from the different data centers (e.g. cloud vendors) where load servers run against the target site. Once play is clicked in cloud-based load tests, or while reviewing results, the Globe shows an arc from any cloud-based data centers in use in the test.
Using the Globe as its background this new System Dashboard also presents the Average Response Time and Send Rate widgets. The Dynamic Ramp Controller in use in this System Dashboard has its top charts suppressed (e.g. via the widget's lower panel settings).
For CloudTest, a new Activity Arcs panel appears that was not found in the prior mPulse-only version of the Globe widget. Clicking the Arc icon on the Globe toolbar drops down the panel.
The Activity Arcs panel is divided into two main control tabs for Arc and Pulse—the Arc Controls panel displays by default. Additional settings for labels and markers appear at the top of the panel.
The Global Activity dashboard displays labels and markers that clearly identify data centers and target sites where the data flow begins and ends.
A Flyout Label is a two-line label that allows for a pair of text data fields (above and below.
A Pinpoint Marker is a 3D marker shown as a billboard (e.g. facing camera) that represents an origin or terminal point of the relevant portion of the data flow (e.g. the geo location of a Data Center or other data point).
When displayed on the currently visible portion of the Globe, markers and labels appear on the Globe surface (e.g. similarly to how they display while in 2D Mercator view).
As the Globe rotates, the markers and labels are presented as if floating in space.
The error basis for Arc Color can be changed from Error Rate to
The default Arc Color settings can be modified in custom dashboards by adjusting the maximum value of the error ranges shown below.
Arc Animation is a subtle pulse effect on the arc layer (solid component) that is noticeable when the pulses layer is off. The Enable Arc Animation box is checked by default. Disable if you do not wish to see arc animation at all.
Use the following Arc Control sliders to customize your arcs:
Arc Visibility – Use this slider to control the arc's opacity
Arc Width (Bandwidth) – Use this slider to control the arc's width with respect to bandwidth in the test composition
Arc Gradient Length – Use this slider to adjust the arc's "squircle" length
Arc Speed – Use this slider to control the arc's growth on creation and following subtle pulses along its length.
Arc Height – Use this slider to control arc height (e.g. the height in relation to the 3D globe or 2D map view
Arc Shape – Use this slider to control arc shape (e.g. odd or even)
Click the Pulse Controls panel for additional settings. Pulse controls allow the user to experiment with different pulse frequencies, offsets, speeds (based on message rate), random variance and length. Pulses account for a great deal of the effects along the arc line, from a pure linear effect, to smaller pulses.
The default pulse color settings shown below can be modified (just as in other Globe settings).
Pulse Control sliders are factor sliders, which is to say that they pertain to the message rate attached to pulse speed. The relative speed differences are scaled.
Use the following Pulse Control sliders to customize your arcs:
Pulse Visibility – Use this slider to control the pulse's opacity
Pulse Width (Bandwidth) – Use this slider to control the pulse's width
Pulse Length – Use this slider to control the pulse's "squircle" length. The slider is a factor the relative speed differences are just scaled.
Pulse Speed – Use this slider to control the pulse's speed.
Pulse Frequency – Use this slider to control how frequently the pulse occurs.
The Enable Pulse Animation box is checked by default. Disable if you do not wish to see arc animation.
In addition to the Activity Arcs panel (covered in the Dynamic Globe Dashboard section below), CloudTest shares additional settings with the Globe Dashboard found in mPulse. The Globe toolbar panels are (from left to right) Favorite Locations, Activity Arcs, Globe Style, and General Settings.
Click the Star icon to access location settings in the Location drop-down.
To rotate the globe at a steady rate, click Rotate. The globe background rotates along with the globe itself for increased realism.
Globe Style settings are found in the Globe dropdown. Choose from among the Base Imagery globes shown in the Globe Style drop-down.
General Settings are found under the Gear icon.Check/uncheck the Display Legend to toggle the legend on the Globe surface
Alignment — Set widget alignment to left, right, or center by selecting a radio button.
Rotation Speed — Use the rotation speed to control the rate at which the globe spins.
Gamma Correction — Use gamma correction to control the dark to light range of the Globe display itself. This setting is useful when your work environment is darker or lighter than the average setting, such as is common in corporate "NOCs" (i.e. network operation centers that require low lighting levels).
Imagery — Use Imagery settings to control night (on/off), toggle cloud animations, or to use a quicker Intro sequence (on Globe launch).
Labels — Use Labels to toggle place name labels (check/uncheck). City labels are not shown by default. Check Show city labels if you prefer to show them. Additional labels will display on zoom.
Background — Select a background for the globe itself. Choose from among Starfield (shows a black background in a field of stars), White, Black (with no stars), and Transparent (for combining with other charts and interpolating data).
Projection — Sets the base imagery for the globe itself. Use Projection to select between 3D Globe view and 2D Columbus (e.g. "flat earth" map projection) modes. Projection permits the user to view al' of the Earth as if projected onto a flat surface as is common on two-dimensional maps.
Visuals — Check Show Sun to add our local star to the Globe visual background.
Borders — Check Show country borders or State and region to enable border display at those levels. Note that state and region borders are only applicable to one country at a time. Check any Country in the list to enable it. Check State and region for and then check the box for one or more countries to show internal political borders such as states or provinces.
In CloudTest, the Globe Legend presents CloudTest Activity, including visual cues for:
The defaults shown in the CloudTest Activity Legend can be adjusted in the Activity Arcs panel (detailed below) in any custom dashboard.
The Global Activity System Dashboard, as well as the Globe widget, is fully filterable in the manner of all other SOASTA dashboards and widgets. Use the default Filter controls (shown in the breadcrumb along the dashboard top) to apply time windows, or, add more filters where necessary in custom dashboards.
The Cloud Test, Globe widget features the same transparent control panel found in its mPulse cousin. For Globe-specific settings, these controls present easy, inline control, and preclude the necessity of lower-panel settings. The legend appears in the lower left and controls are in the top-right corner.
In its default state, the Globe spins, clearly and accurately showing the current solar terminator point between night and day as well as clearly representing the twilight zone, or moving line, between the two. Click to stop the globe's rotation and use gestures to zoom. Alternately, click one of the fly-to locations on the Legend to move to it.
For cloud instances running on AWS, please tear down the Test Environment and redeploy with the latest new build.
For CloudTest Appliance instances, please contact firstname.lastname@example.org for assistance updating non-automated builds. Please provide us a contact name, phone number and email address to work with, and the proposed target date for the upgrade. In preparation for the upgrade, this contact should be able to SSH to the appliance and the appliance should be able to reach the following three locations: cloudtestmanager.soasta.com port 80, cdn.soasta.com port 80, and soastaftp.soasta.com port 21.
© 2015 SOASTA. All Rights Reserved. Privacy & Legal