v4.0.0

• Features
  • Redesign of the layout of the application. All views are now fully responsible and they use the full screen width. That's useful in particular for the charts. Form controls to configure chart data are now grouped and arranged in cards.
  • Introduced new Page Aggregation Chart. This chart aggregates arbitrary WebPagetest metrics by measured page. Means get visualized in bar charts.
  • This open source repository realizes a microservice to persist and visualize detailed webperformance waterfall data. One can explore metrics like load time or size in bytes for all the single waterfall resources interactively. The service can be integrated as detail analysis dashboard in OpenSpeedMonitor now.
  • Via context menu all the different WebPagetest views of a result can be accessed from chart.
  • One can mark different result data points in chart now. These points can be compared in WebPagetests timeframe/video comparison view.
  • In joblist the success rates of all measurement jobs get visualized.
  • We added Links to jump from measurement jobs in joblist to dashboards showing the results of the jobs.
  • Improved hover info shown in dashboard charts. It shows all data points of the same timestamp with colors of the series now.
• Minor changes
  • Rest API method resultsbetween now works with ID's of request parameters page, step, browser and location in addition to their names.
• Bugfixes
  • After login one gets redirected to requested page now.
  • All password data in web forms is masked now consistently.
  • Fixed page footer to the bottom of the page.
• Internals
  • Updated Twitter Bootstrap to version 3.
  • All 3rd party web assets are assembled via bower now.

v3.5.5

• One can set WebPagetest apikeys now in OpenSpeedMonitor. So you can use (private) WPT servers secured by apikey for your measurement.
• One can copy the script of a measurement job to clipboard now. If the script is parametrized by the job all parameters get replaced respective job settings.
• All the administration lists (menu >> Administration >> All Controller) are now filterable.
• We extended user management
  • If an smtp server is configured new users can register autonomously.
  • Users can be maintained by super users.
  • Roles can be maintained by super users.
• Links of new results data points now work for newest WebPagetest version.
• We extended the rest api in preparation of new detail analysis board which is in progress but not yet visible.

v3.5.4

• Bugfix REST API method resultsbetween: results for not csi job groups weren't delivered.
• Improved filter on batch activity view.
• Security bugfix.

v3.5.3

• Added filter functionality to list of batch activities.
• Increased number of lines to show on CRUD list views per default to 100.
• Clicking to Last Run link in job list led to an error on result list page. Fixed broken pagination.
• Update of grails asset-pipeline to fix error in uglyfying javascript.
• Fixed some minor bugs in javascript of Filter jobs accordion on result dashboard.

v3.5.2

• Added support for actual WebPagetest version with multistep capability.
• Integration of Bower for building of web assets.
• Bugfix: Javascript bug on csi configuration pages.
• Bugfix: Nightly calculation of CSI aggregations was broken. Aggregations for page, job group and CSI system aggregations weren't calculated correctly anymore. The fix marks all aggregations affected as outdated. During the next nightly calculation these aggregations will be calculated again correctly.

Update Grails 3

• We updated Grails framework from version 2.5 to version 3.1.
• That update implies an update of build from grails specific ant version gant to gradle build system.
• OpenSpeedMonitor now requires Java 8 instead of version 7.
• We wrote webdriver tests based on Geb for the most important pages/functionalities.
• OpenSpeedMonitor can now report JVM metrics like actual memory usage to arbitrary Graphite servers.
• Migrated build and deployment from CI Server Jenkins to Atlassians Bamboo (scripts under scripts/ci).
• Fixed some long time failing integration tests.

v3.4.5

Changes from previous release

• CSI Configurations

  The Customer Satisfaction index (CSI) is an aggregation which first converts load times into a percentage of users who would be satisfied by the load time. This version of OpenSpeedMonitor comes with a preset of five different mappings to translate load times into a percentage of satisfied users. You can assign one of these mappings to each of your measured pages. Furthermore you can extend the preset of mappings by uploading your own ones via CSV ex-/import.

  After translating the load times, resulting percentages get aggregated to an index. That aggregation implies building weighted means. The weighting factors (browser, internet connectivity, page and hour of day) and the previously mentioned mappings are now summarized to a CSI Configuration entity. You can configure multiple configurations and define which one to use calculating each of your CSI's. Here you can see the CSI configuration view of the OpenSpeedMonitor demo instance.

• CSI Systems

  With this version we introduced CSI systems. You can assemble multiple Job Group CSI's within a CSI system. Each Job Group CSI associated to a CSI system gets a weight. For the system a CSI is being computed by building a weighted mean from the CSI's of the affected Job Groups. By choosing one of the two new options daily/weekly mean per CSI System you can visualize CSI Systems as a graph on CSI Dashboard.

  An example: You are measuring the performance of a responsive web application on different devices with different screen sizes. You have grouped all the measurements by breakpoints in different job groups. OpenSpeedMonitor calculated one CSI per breakpoint so far. Let's assume your applications supports three different breakpoints. With the new CSI system you can aggregate your three breakpoint CSI's to one system CSI. Each breakpoint can be of different interest for your application. You can weight the breakpoint CSI's accordingly in your CSI system. The system's CSI now represents the satisfaction of your users on all different breakpoints.

• CSI by visually complete times

  WebPagetest provides a measurand called visually complete time. This is the point in time after that nothing in the viewport of the browser changes visually until page is fully loaded. Up to now the customer satisfaction was caculated by WebPagetests doc complete time. With this release a second CSI is calculated based on visually complete time. You can visualize both CSI's on CSI Dashboard (see filter CSI Type).

• CSI values by internet connectivity

  On CSI Dashboard you can now choose which internet connectivity you want to see. This option is only available for hourly values because daily and weekly aggregations weight measurements by internet connctivity. The weights of all browser/connectivity combinations can be found on csi configuration view.

v3.3.0

Changes from previous release

• Intgerated Liquibase for automatic database updates. Removed Hibernates dbCreate configuration from all DataSources. From now on all scheme and/or data updates get applied via liquibase changelogs at startup, automatically.
• Arbitrary sets of jobs can now be saved as job sets in job list view. These sets can be used to undo or repeat updates like activation or deactivation for exact the same group of jobs.
• Added matrix view for visualisation of browser-connectivity-weights.
• Bugfix: NextRun in jobList is now correct when using german language.
• Bugfix: Legends of graphs on CSI- and EventResultDashboard are now correctly summarized for all cases.

Database updates

With this release we integrated Liquibase via database-migration plugin.

This release contains a root changelog with all the change sets to create the complete osm database for this release version: grails-app/migrations/changelog.groovy. If you start with a fresh installation without a legacy database you can just start your application, the scheme gets created automatically and the changelog get marked as applied in your database. On subsequent startups with the same osm version no database change sets get applied.

No more manual database updates from now on.

Initially update legacy database

If you have to update a legacy database of a previous osm version you will have to do the following steps once to update your database scheme to the actual state. Because your database can be in very different states dependent on the osm version you are running, nobody can guarantee these steps will lead to a valid database in all cases.
So if you care about your synthetic performance measurements results DUMP YOUR ACTUAL DATABASE before working out the following steps.

1. For documentation purposes you should create a liquibase changelog of your actual database and your actual domain classes before you start with the update. These changelogs can help to reproduce problems with the update.

   Within your version of OpenSpeedMonitor before updating the software:

   grails dbm-generate-gorm-changelog <date>-GORM-complete-changelog.groovy
   grails dbm-generate-changelog <date>-DATABASE-complete-changelog.groovy
   

   <date> should be replaced with an actual timestamp.

2. Update your version of OpenSpeedMonitor to this release version.

3. Create a changelog containing all changesets necessary to update your database to the latest domain class state:

   grails dbm-gorm-diff legacy.groovy
   

4. Add this changelog to your root changelog

   grails dbm-register-changelog legacy.groovy
   

5. Remove imports of all other (official) liquibase changelogs temporarily from root changelog. Root changelog should look like this:

   databaseChangeLog = {
       //include file: '2015-11-18-SCHEME-initial-liquibase.groovy'
       //include file: '2015-11-18-DATA-set-initial-csi-transformation.groovy'
       //include file: '2015-11-18-DATA-multiply-csi-values-by-100.groovy'
       include file: 'legacy.groovy'
   }
   

6. Apply changelog by running grails dbm-update. All the change sets necessary to update your legacy database scheme get applied to your database. Dependent on the age of your database scheme this can last a while.

7. After successful dbm-update your database scheme should be in sync with the domain classes/gorm now. Add the actual SCHEME liquibase changelog again. (Optional: Remove import of already applied legacy changelog from root changelog.) Root changelog should look like this:

   databaseChangeLog = {
       include file: '2015-11-18-SCHEME-initial-liquibase.groovy'
       //include file: '2015-11-18-DATA-set-initial-csi-transformation.groovy'
       //include file: '2015-11-18-DATA-multiply-csi-values-by-100.groovy'
   }
   

8. Now, you can mark the actual SCHEME liquibase changelog as already applied. Otherwise it will run with the next start of OpenSpeedMonitor again, failing because all the db artefacts already exist.

   grails dbm-changelog-sync
   

9. Add the two DATA liquibase changelogs again:

   databaseChangeLog = {
       include file: '2015-11-18-SCHEME-initial-liquibase.groovy'
       include file: '2015-11-18-DATA-set-initial-csi-transformation.groovy'
       include file: '2015-11-18-DATA-multiply-csi-values-by-100.groovy'
   }
   

   They apply some data updates necessary to run the actual version of OpenSpeedMonitor and will run with the next start of the application.

You are ready to go now - No more manual database updates from now on.

v3.2.2

Changes from version 3.2.0

• Bugfix: Percent of users who would be satisfied with a measurement result is called Customer satisfaction (CS) in OpenSpeedMonitor. For each result CS is calculated by rank for now (algorithm will be switched to a mapping soon). Proof whether it could be calculated for a concrete result was switched to mapping algorithm already. So when no mapping exists no CS was calculated.

Manual db updates

No updates necessary.

v3.2.0

Changes from previous minor version

• Chart legends on dashboards are reorganized to make dashboards more clear. Therefore parts of graph labels which are common to all graphs get listed above the chart. Just label parts which are different for the graphs mark them in chart legend.
• Jobs configured to run with a custom internet connectivity will get a custom connectivity name now. You can set that name in job edit/create GUI.
• In result dashboard you can choose the graphs to show by internet connectivity now. You can choose single predefined connectivities, custom connectivities or measurements without traffic shaping at all.
• Added new Job Scheduling view to show all the locations/job queues for all WPT servers. Scheduled jobs and usage rate are visualized with d3.js.
• Added visualizations for customer satisfaction index weights.
• Update Grails framework to version 2.5.0.
• Update several Grails plugins to match default for grails version 2.5.
• Refactored asset loading with asset pipeline plugin.
• Completely removed long time deprecated proprietary charting library Highcharts.

Manual db updates

The following changes have to be implemented manually if you want to use an existing database from the previous OpenSpeedMonitor minor version. Grails/Hibernates dbCreate/hbm2ddl feature doesn't manage these changes automatically.

All following SQL scripts got tested with MySQL database.

Schema updates

No schema updates necessary from previous minor version.

Data updates

Change saved user passwords

Spring security core plugin got updated from version 1.2 to version 2.0 with this release. Used hash algorithm to store passwords in db has changed from sha-256 to sha-512. If your MySQL server has been configured with SSL support you can set the new hashes with this SQL statement:

update user set password=SHA2('[user-password]',512) where id=[user-id];

Otherwise you will have to use another tool to create sha-512 hashes of your passwords. With openssl for example:

$ printf [user-password] | openssl dgst -sha512

Then you can change password hash in database:

update user set password=[user-password-hash] where id=[user-id];

Add Connectivity to Event results

In event result dashboard, results to show in chart can be limited by internet connectivity now. This connectivity is persisted for every incoming result with this version of OpenSpeedMonitor.
So to show results measured with a previous OpenSpeedMonitor version correctly, you will have to add this connectivity to exisiting results.

1. Add custom connectivity names in jobs with a custom connectivity.

   For these Jobs a name for the custom connectivity has to be defined now. So you need to add these names manually. With select id,label from job where custom_connectivity_profile=1; you get all affected jobs. You can add names for the custom connectivity for the jobs in OpenSpeedMonitors job/edit view of respective jobs.

2. Set connectivity for event results measured with a custom connectivity

   update event_result er 
   inner join job_result jr on er.job_result_id=jr.id
   inner join job j on jr.job_id=j.id
   set er.custom_connectivity_name=j.custom_connectivity_name
   where j.connectivity_profile_id is null and cast(j.no_traffic_shaping_at_all as unsigned)=0;
   

3. Set connectivity for event results measured with a predefined connectivity

   update event_result er 
   inner join job_result jr on er.job_result_id=jr.id
   inner join job j on jr.job_id=j.id
   set er.connectivity_profile_id=j.connectivity_profile_id, er.no_traffic_shaping_at_all=0
   where j.connectivity_profile_id is not null;
   

4. Set connectivity for event results measured without traffic shaping at all

   update event_result er 
   inner join job_result jr on er.job_result_id=jr.id
   inner join job j on jr.job_id=j.id
   set er.no_traffic_shaping_at_all=1
   where cast(j.no_traffic_shaping_at_all as unsigned)=1;