Mouse in the House

Posted by simone on May 13th, 2011

WatchMouse is mainly known for it’s great monitoring service, the quality of it’s checkpoint grid and it’s accurate testing methodology; no question about that. Though, WatchMouse bundles a few more services together with it’s main product, that are sometimes well hidden. One of these services is the Vulnerability Scanner and this is what I’d like to introduce with this blog post.

Most probably, your online business infrastructure includes a few web servers, maybe some ssh and ftp servers, definitely some web applications, web services and who knows what else! All of these services are usually well-guarded gateways to your business. On the other hand, they are just applications written by humans and, most probably, not bug free. Some of their bugs can cause vulnerabilities that hackers may discover and try to exploit with unknown consequences. I guess you are already aware of all this; your business is probably protected by firewalls and intrusion detection systems; you are also likely to have launched a few security tests and your sure you’re fine! Sure..but for how long?

If you take a look at this page you will see that vulnerabilities are discovered every day. You should be monitoring the security of your online business quite often if you really want to feel safe.

WatchMouse Vulnerability Scanning offers exactly that; we make sure we track all known vulnerabilities and we provide tests for each one. We do this by keeping a large database of vulnerabilities and we update it every day; then for each known vulnerability we install a scan module that can detect the new vulnerability and we silently introduce it into the next run of your scan-monitor. Take a look at this page for a list of all scan modules WatchMouse Vulnerability Scanner includes. You could think of our scanner as a hacker emulator.

Setting up a vulnerability scan monitor is quite easy. If you have a WatchMouse account and haven’t tried the Vulnerability Scanner yet, you can activate a trial here. Ten Scan Credits will be added to your existing account, allowing up to 10 standard scans.

Next you need to create a scan monitor; you can do that on the Vulnerability Scan Settings page. Click on the “Add scan” button at the bottom of the page and a simple form should appear. When setting up or editing a vulnerability scan, you can choose the type of scan to be performed (see field “Scan type”). Also, don’t forget to click on the little question marks next to each form element as they will provide some useful tips!
The available scan types are:

• Standard (available in 30 day trial)
• Intrusive
• Intrusive with Denial of Service attacks
• Standard – WEB (available in 30 day trial)
• Intrusive – WEB
• Intrusive with Denial of Service attacks – WEB

The scan types with the “WEB” suffix will scan only the web-server and web applications on your server for XSS and SQL Injection vulnerabilities.

Each scan type consumes a different amount of scan credits with “standard” needing only 1 scan credit. The check interval of your scan monitor can be set to once per week and up to once per day. If, for example, you scan a server once per week (say every Sunday) with a standard scan, then you would need about 4 credits per month. With the current credit prices, you can scan your server on a weekly basis for less than 15 US Dollars per month!

Finally, don’t forget to add an alert contact! That will be used to send alerts when new vulnerabilities are discovered!

After you save your scan monitor, you need to confirm it before you can really use it. This is a security procedure that ensures that no one other than you can test your servers using the WatchMouse Vulnerability Scanner. It requires you to add a confirmation ticket in a file and place that file in your root folder of your web server. For larger companies or for individuals that need to scan a large amount of servers, WatchMouse can pre-activate a fixed number of IP addresses if you provide us with papers that certify the ownership.
Right after you activate your monitor, you will be able to either launch scans directly through the console or wait until the scan scheduler picks it up. After the first run, you will get alerted (via the alert contact you’ve setup earlier) if the scanner detects any important issues. We classify the issues as “informational”, “warnings” or “holes” with the later two considered as important.

Finally, the reporting console provides all the tools you would need to learn and  manage all discovered issues. A live demo of this console can be seen here. So what are you waiting for? Go ahead a give it a try.

Written by Dimitris Balaouras

‘WatchMouse Weekly’ tweets and corresponding blog posts aims to be an introduction with tips and tricks for getting the most out of your WatchMouse monitoring. For all ‘WatchMouse Weekly’ blog posts go here.

Posted by mark on April 26th, 2011

Social networking sites are a global phenomenon. Millions now go online on a daily basis to engage in one or more social networks including Facebook, Twitter and LinkedIn.

What’s the problem with that? With millions of site visitors and complicated web pages with exhausting amounts of content coming from multiple sources, these sites can slow to an Internet snail’s pace.

Why speed matters?

• Web visitors have really short attention spans and high expectations. They will abandon a website in nano-seconds if it lags.
• Google is now using load times as a factor in search placement. Believe it or not, this still matters even to the social network giants.
• “Bad will” or brand damage happens at the speed of light. Sites start to get sluggish, people talk, start tweeting and it’s all over the Internet.

So how are these sites stacking up? We recently monitored the page load time performance of a public profile page of 22 of the world’s top social sites using our real browser monitoring product. We tested these sites from April 6 through April, 20, 2011 using the combination of measuring a profile page using real browsers, which we believe gives us the best representation of actual performance from a real user’s perspective.

Fifty percent of the sites had slow load times. Facebook at 1091 milliseconds, blew away the competition by a long shot and had the fastest page load time during the reporting period, which is fairly impressive considering it also has the most traffic. Coming in last was the ailing MySpace at 7859 milliseconds followed closely by Friendster at 6473 milliseconds and Posterous at 5973 milliseconds.

We use two performance limits to decide if a website’s load time is good, ok or bad: two and four seconds, based on the research conducted by Akamai in 2009. Anything two seconds or under is considered good. Anything over four seconds is considered bad.

Facebook has set a standard and shows that speed can be achieved regardless of traffic and page complexity. Speed still isn’t a top priority for a lot of these very popular sites, and with 50% of the sites being too slow, there is still a lot of room for improvement.

• You can test any website using our free tool: http://loads.in/
• This survey is based on WatchMouse Real Browser Monitoring.
• The current status of all of the social network sites monitored can be seen here: http://social.downornot.com/

Posted by admin on April 6th, 2011

Along with the big list of protocols you can monitor using the WatchMouse service and its global infrastructure, you can also execute “transaction application” tests or as they are more commonly referred to, “functional” tests.

Before going through the steps on how to create and upload such a script to your WatchMouse account, lets briefly see what transaction application testing actually is.

Transaction Application Testing

On top of testing the availability and the performance of a website or web application (non-functional testing), you can also test the individual components of it such as, a login procedure, the results of a search in a form, an article submission and so on.

Transaction application testing differs from non-functional system testing in that, with transaction application testing you have to specify and test the functions that the web service is expected to perform.

Creating a transaction testing script

WatchMouse uses the JMeter scripting engine to run transaction application tests.  A JMeter script is like a browser which executes steps that test the functionality of a web application. Note however, that JMeter does not support all the actions supported by browsers, for example it doesn’t execute JavaScript functions.

To create a valid JMeter script we strongly suggest to use the Badboy windows application, which can be downloaded here, with Badboy you can easily:

• Record the actions you want your script to perform, in a browser environment
• Replay the actions you recorded to validate the script functionality
• Export the script to .jmx format, so you can open it with the JMeter application or
• Upload the script directly from Badboy to your WatchMouse account

Exporting your Badboy script to JMeter correctly might require some customization, due to a few differences between Badboy and JMeter execution:

• JMeter doesn’t execute JavaScript, so in order to simulate JavaScript functionality you might need to pass values (for example a session ID) from one call to the other, manually. You can do this by saving a specific value, after an HTTP request, in a variable and use this variable in subsequent HTTP requests.
• Badboy executes its actions in a linear fashion while JMeter needs to define a scope for every action (element). So for example, if you add an assertion element, to match a text which appears after a login procedure (i.e. the text “log out”), in JMeter you should add that element as a child of the login HTTP request rather than putting it after the request in the list of calls.
• Unlike Badboy, JMeter doesn’t download the embedded elements and assets of a web page (images, css and JavaScript included files etc.). It only tests the functionality of it. You can enable downloading of embedded elements by choosing the corresponding setting in the JMeter application.

Uploading your scripts to WatchMouse

To upload the script to your WatchMouse account you have to:

• Create a new monitor
• Choose “script” in the “type” dropbox
• Upload the script, using the upload form
• Save your monitor

The WatchMouse engine will check the validity of your script and then create the new monitor.

NOTE: Due to the number of calls a script monitor performs, WatchMouse has a default timeout of 20 seconds for these type of monitors. You can adjust the timeout, according to your script, in the monitor “expert mode” settings.

Getting Help from us

You can find a set of example scripts we have created for reference, which test different kinds of applications (SOAP, OAuth, HTTP authentication) here: WatchMouse JMeter repository

We are also happy to help to construct the scripts. Just send the script to helpdesk AT watchmouse.com along with a small description of the difficulties you are facing and we will fix the script for you.

We hope this post will help you understand, as we do in WatchMouse, the importance of transaction monitor testing and also the fun of creating such tests for you websites and web applications.

Post by Nikos Prodromidis: I am a QA Tester and Junior Developer at WatchMouse. I joined the team in June 2009. I find the process of making and understanding functional tests for web applications (i.e. scripting) very interesting and innovative, also I like learning and implementing new technologies.

‘WatchMouse Weekly’ tweets and corresponding blog posts aims to be an introduction with tips and tricks for getting the most out of your WatchMouse monitoring. For all ‘WatchMouse Weekly’ blog posts go here.

Posted by mark on April 1st, 2011

URL shorteners. Lots of people use them every day – including the team at WatchMouse. URL shorteners like bit.ly, Google’s goo.gl, Twitter’s t.co, and Facebook’s fb.me are widely used nowadays, but how reliable and how fast are they really?

We took a look at the pros and cons of URL shorteners in March 2010, and thought it only fair to see how URL shorteners are performing one year later.

And, what a difference a year makes! Last year, Facebook’s fb.me was at the bottom of the list in terms of speed, but this year fb.me tops our list joining Google’s goo.gl and BudURL with 100% uptime and a much improved loading speed.

Why (not) using URL Shorteners

There are some obvious pros and cons of URL shorteners.

On the plus side:

• URL shorteners obviously provide useful features like making a long URL shorter (e.g. so it fits easily in a Twitter message)
• They enable you to track and analyze clicks on a specific short URL
• Some URL shorteners like t.co and mcaf.ee also provide some browsing safety by analyzing the target URL for harmful website code or phishing attempts

But on the down side, URL shorteners also introduce:

• An additional single point of failure: when a URL shortener service is down (or corrupt) the link won’t work
• Additional load time for a page to fully load

URL Shorteners Uptime

WatchMouse monitored the most popular URL shorteners from February 24 – March 28, 2011 to find out how they are doing in terms of availability and speed. During that time we monitored 25 URL shorteners and collected the uptime and performance statistics. Uptime is an issue for URL shorteners because it has a direct impact on the uptime availability of the website that the URL shortener actually directs to. The uptime results are shown in the chart below:

Uptime is still clearly an issue for some of the URL shorteners, but what a difference a year makes! Last year Facebook’s fb.me landed at the lower regions of our list. Things have changed dramatically this year and now only fb.me, goo.gl, and BudURL scored a perfect 100%. And to be fair, Twitter’s t.co would also score a perfect 100% if they weren’t blocked from China, which is obviously out of their control.

According to our data, twurl.cc, tr.im and to. appear to be dead in the water and inactive with over 31 days of downtime. Digg.com racked up over 19 days of downtime, while snurl.com had over 14 hours of downtime, making them our worst performers and by far the slowest among the active URL shorteners.

URL Shorteners Speed

The performance results can be seen in the chart below:

Note that we left out the resolve time in this chart, please see the full report for a version with the resolve time included and what it means.

• lnkd.in is the slowest and adds over 700 milliseconds on average to the page load time after the click on a link (excluding the resolve time), which is really way too much for just a URL redirection. This substantially affects the user experience.
• goo.gl is super speedy and does a redirection in just about 100 milliseconds, which is really impressive we think.

Live URL Shortener Status Report

We continuously monitor URL shorteners and share the results publicly through our website portal. The real-time status of each of the sites and a seven-day history can be found at http://url-shorteners.public-website-status.com/. You can also receive Twitter alerts so you know immediately when URL shorteners go down by following http://twitter.com/url_shorteners.

URL Shortener Popularity

It’s not obvious to measure the popularity of URL shorteners, but traffic metric for the domain does give an indication:

This information comes from Alexa and was requested for the five most “famous” URL Shorteners.

Seeing that bit.ly is seeing way more traffic than the others we can conclude they are doing a very good job in terms of availability and speed.

[disclaimer: bit.ly and Twitter are WatchMouse customers]

Methodology and full report

The URL shorteners were checked every five minutes from one of the 58 WatchMouse global website monitoring stations. For each short URL, only the redirection was measured, not the actual loading of the target page. The redirection was expected to complete within four seconds without any errors (like when a server error occurred or if the expected target URL location was not found in the http header). If that time was exceeded, WatchMouse verified the results using another of its monitoring stations and the result was counted as unavailable.

The full report can be found here: Performance and Uptime of URL Shorteners.

What do you think? Have URL shorteners improved dramatically over the past year or is there still room for improvement? We welcome your feedback and comments!

Posted by simone on March 8th, 2011

I am sure that many of you reading this post already know what loads.in is. If you have used loads.in before then skip to the paragraph “Getting the most out of Loads.in”.

Quick Introduction to Loads.in

Loads.in is a service that gives you the ability to see how fast your (or any) website loads in a real browser from over 50 locations worldwide. You can read more and test our service by visiting loads.in You can also visit the post How Fast Does Your Website Load – Here and Abroad?

Getting the most out of Loads.in

So now you know how how many seconds it takes to load your site from locations all over the world. Loads.in also provides snapshots of the webpage as it loads. But, is that enough? Of course not, so we provide you with a waterfall chart for each result based on the browser profile. I believe that many of you may not really know how to read these waterfall charts so, stay turned to what follows. I advise you to load your site using loads.in, click on the waterfall chart icon and continue reading.

How to read a Waterfall Chart

Each row in a waterfall chart represents a different object such as text, image, CSS, JavaScript files. As you will see, there are some objects that load simultaneously, the number of simultaneous downloads depends on the browser’s settings. Remember that each browser renders a site differently. Using Loads.in you can verify your site’s load time using different browser profiles.

Each object requires time to be loaded which can be analyzed in the waterfall chart.

• The green bar represents the connect time, which is the time that the server needs to set up a TCP connection
• The bright pink bar represents the blocking time, which is the time taken while the object waits for another files to be completely downloaded
• The purple bar represents the waiting time, which is the time to first byte: the time until the browser receives the first byte of the object from server
• The bright purple bar represents the receiving time, which is the time the browser needs to receive the whole file

Additionally, there are two vertical lines:

• The blue vertical line shows “DOM is loaded”: when the unformatted text and HTML markup have being loaded
• The red vertical line shows “Page loaded”: when all assets of the page including images, CSS, JavaScript etc. have loaded but before the user’s JavaScript has been being executed

For a fast webpage you want:

1. As few rows as possible
2. The “DOM is loaded” and “Page loaded” vertical lines to occur as early as possible and be as close together as possible.

You can read more about understanding waterfall charts in these four articles:

• How to understand your site’s performance via waterfall chart
• Waterfalls 401: Advanced analysis for non-beginners
• How to read the AOL PageTest waterfall chart
• Firebug Net Panel Timings

Post by Ziogas Chris. I am the youngest (and most fun) web developer at WatchMouse. I started coding seriously when I was 15 years old and from then on, I’ve live & dream in this world. I always want to add new technologies to my back-pack and use it on new projects. I am pleased that WatchMouse helps me to search & learn new technologies.

Posted by simone on March 1st, 2011

Setting up a WatchMouse Public Status Page is a simple task performed from the WatchMouse website.  There are also a few nice articles that walk through the whole procedure and can be found at http://www.watchmouse.com/en/feature/public-status-page.html or download the User Manual here: http://www.watchmouse.com/assets/docs/WatchMouse_PSP_Guide.pdf.

What might not be obvious is the logic behind the Public Status Page that indicates performance issues or a service disruption. In this post, I will reveal this little secret and show you how to tweak the algorithm.

Two parameters are predominantly taken into account when measuring the performance of a monitor: “first limit” and “second limit”. Both those parameters can be configured in the monitor setup pages under the “monitoring” dashboard, after switching to the “expert mode”.

If the total time of a public monitor stays below the first limit, the server is performing well. If it totals to a value between the first and second limit, the server is considered to perform poorly. Above the second limit, the performance is considered bad.

A WatchMouse Public Status Page uses both these parameters to identify performance issues and service disruptions.
For the history, it compares the average total time of each day with those parameters. The current performance measurement is based on exponential weighted average of most recent check results.

Setting up these parameters correctly is very important for your Public Status Page. Having them too low will result in a Public Status Page that continuously indicates performance issues whereas having them them too high will hide performance issues from your visitors which, they will eventually find out anyway.
If you haven’t already tuned these parameters, I’d strongly recommend that you do so after considering the following tips:

• Get to know your monitors; check the performance charts under the “reports” dashboard.
• Set the first limit slightly higher than the average total time of your monitors.
• Set the second limit close to the total time it takes to load during a high traffic period.

For example: if you see that the average page load for a specific monitor is 4 seconds, set the first performance limit to 5000ms and the second limit to 8000ms. You can always check your Public Status Page to ensure the performance icons reflect what you had in mind. If not, you now know how to fix it!

For any questions or assistance just leave a comment or contact us through the help desk.

Post by Dimitris Balaouras. I’m the Lead Programmer at WatchMouse. I joined this great team of nerds back in 2006 and I have remained a true fan of WatchMouse ever since. Passionate about software engineering, I enjoy programming more than anything. I’m based in Greece and recently moved from the crowded Athens to Larisa, a small town in Northern Greece where I can code in peace

Posted by mark on February 17th, 2011

Ever wonder how fast your website (or any other website) loads from different locations around the world? Especially if your site relies in part on third party content, the user experience at various cities can be very different indeed!

Using our WatchMouse Performance Monitoring service API, Loads.in is a convenient webmaster tool that allows you to measure just how fast a website loads in a real browser from over 50 locations worldwide – on every continent except Antarctica!

Websites can be particularly susceptible to slow page load speeds when they need to load a high amount of components (images, JavaScript, third party content) to render the complete page.

The free, Loads.in tool checks your site utilizing a real browser, and provides snapshots and waterfall charts for each check.  A selection of browser profiles is available too, and include Safari, Chrome, Internet Explorer and Firefox

Simply enter the full URL of the page you want to check in Loads.in, and the page is retrieved by a browser at a random location. For each subsequent check you can choose a specific location*.

The Loads.in results presented include:

• The page load time of the website
• Snapshots at different times during the loading of the page
• Errors or warnings if they occur
• A complete timing breakdown of all elements of your page in a “waterfall chart”
• The option to download the timing results in the HTTP Archive (HAR) format

*Locations include: Amsterdam, Antwerp, Cologne, Copenhagen, Dublin, Glasgow, Groningen, Lille, Lisbon, London, Madrid, Manchester, Munich, Oslo, Padova, Paris, Stockholm, Zurich, Bucharest, Kharkov (Ukraine), Krakow, Moscow, Vilnius (Lithuania), Melbourne, Sydney, Cape Town, Bangkok, Haifa (Israel), Jakarta, Kuala Lampur, Mumbai, Nagano, Shanghai, Singapore, Guadalajara, Vancouver, Austin, Chicago, Dallas, Florida and NYC.

Check it out and let us know what you think. We value your feedback and hope you find Loads.In to be a useful tool and resource.

Happy Monitoring,

Mark Pors
CTO & co-founder

Posted by mark on February 11th, 2011

Monitor metrics vs. User satisfaction

Monitoring the performance of your website pages generates lots of interesting metrics like resolve time, connect time, time to first byte, DOM-ready, first visual (in real browser monitors) and many more.

These metrics:

• provide insight in what might cause a page being slow,
• shows page load time trends over time,
• can trigger alerts in case of a temporary performance drops,
• show the effect of request originating from different geographical locations, etc, etc.

What these numbers do not say is how this affects the user satisfaction of  visitors of your website. This is where the Apdex comes in.

The Application Performance Index (Apdex)

The purpose of the Apdex score is to convert performance metrics into insights about user satisfaction. It allows you to specify a threshold that indicates whether your service is operating satisfactory or not.

See the Apdex website for further information and exact definitions.

WatchMouse and the Apdex score

Next to the WatchMouse Site Performance Index, which combines page load time and downtime in a single metric, we recently introduced the Apdex as a new chart type. Both metrics are also available in the custom PDF reports.

The charts below show the Apdex for one page over time:

The charts can also be used to compare Apdex scores between pages:

These charts can now be interpreted as showing the fraction of satisfied visitors on your site: 0 = no users satisfied, 1 = all users satisfied

Note: To make sure that the Apdex chart is based on valid assumptions, the monitor or monitors you use should fulfil the following condition:

Time-out > First limit * 4

The time-out and first limit can be set in the expert mode of you monitor settings. By default the settings will be Apdex compliant, and a warning will be shown if the settings are not Apdex compliant.

What’s next?

The Apdex charts in the WatchMouse reporting are just a first step in reporting customer satisfaction in terms of performance. Now what I would like to know…

• Are the new Apdex charts useful for you?
• How will you use them in your organisation?
• What else would you like to see related to Apdex?

Please let us know in the comments!

Mark Pors
CTO & co-founder

Posted by stan on December 28th, 2010

We monitored and tested the leading shopping websites in six different countries to see how they fared in the lead up to and during the holiday shopping weeks.

The 300-plus websites we tested in the United States, United Kingdom, Spain, Germany, Belgium, and The Netherlands performed quite well overall. The country with the most sites in the 100% uptime category was Germany with 33% of the 30 tested sites experiencing no downtime during the reporting period. Coming in second was the United Kingdom with 31% of the 89 websites experiencing 100% uptime, followed by Spain with 29% of 17 websites and the United States with 27% of 100 sites with no downtime. The Netherlands had only 12% of the 91 sites tested with 100% uptime, while Belgium sites performed worst of all with only 10% of the 83 sites tested with 100% uptime.

You can read the full performance reports and view a list of the websites monitored in each country by clicking on the following: United States, United Kingdom, Spain, Germany, Belgium, and The Netherlands. You can also view the current live health of each of the 327 websites we monitored, by visiting the Public Status Pages for each country: United States, United Kingdom, Spain, Germany, Belgium, and The Netherlands.

Happy Holidays and we look forward to sharing more monitoring news in 2011!

The WatchMouse Team

Posted by mark on November 23rd, 2010

Cloud computing has made it easy to build applications that run reliably even under a heavy load, and developers need to know if and when the cloud, and thus their application, is having problems.
We’re very pleased to announce today that we’ve acquired Cloud Status for iPhone, an application originally created by Alasdair Allan, noted author, software programmer and expert iOS developer. Our collaboration and acquisition of the Cloud Status for iPhone app has allowed us to not only add new features in the latest version 4.4 release, but also to make the app available for FREE to the developer community and IT departments around the world who depend on cloud based services to run their businesses.

The Cloud Status for iPhone version 4.4 release includes the following features:

• FREE to download
• Support for iOS4
• Support and reporting for Amazon Web Services, Google App Engine, Google Apps, Microsoft Windows Azure, and Rackspace Cloud
• Fully supported retina display in iPhone 4

Each of the supported cloud services has a separate page and details the status for the various services provided. A quick read indicator denotes the status for each service: the status for the service is good, there is a problem with the service, or the service is down. Clicking on each service component provides further information as to the current status of that component, and any problems it might be experiencing.

We greatly respect and admire the work of Alasdair Allen on the iOS platform, and we plan to work with him in the future to create additional applications that will support other WatchMouse performance monitoring services.

For more information click here.