Test Your Server Against the Heartbleed OpenSSL Vulnerability

April 8th, 2014
Posted in Tools, Tech

A major vulnerability in OpenSSL software was announced late yesterday, impacting all servers having the Heartbeat TLS extension enabled with OpenSSL versions states above.

The "heartbleed" vulnerability, has been already recorded as CVE-2014-0160. Further details can be found at http://heartbleed.com and https://www.openssl.org/news/secadv_20140407.txt.

The bug has already scared a lot of system administrators and site owners, and the one that we've done on WebSitePulse was to release a test against this vulnerability.

So, if you want to check whether your secure server is affected or not, please visit: http://www.websitepulse.com/heartbeat.php

Browser Full Page Test Tool Now Ready for Use

April 3rd, 2014
Posted in Tools

Not long after releasing our latest and most sophisticated monitoring level – the In-Browser Application Monitoring, we are happy to announce that it is now available as a free test tool.

So here’s a brief description of what the In-Browser level of monitoring is all about:

It simulates a real user “browser-like” experience. It is based on the Firefox “GECKO” engine and supports multiple simultaneous connections, JavaScript rendering and page component caching. The benefit is that we are able to detect performance issues connected to the code itself, the images and all other third-party embedded objects.

We developed our In-Browser Application Monitoring service further and created the Browser Full Page test that you can use at any time. This is how its main page looks like:

Click to Enlarge

To test a website URL, simply enter it in the field, click the Perform Test button and a loading animation will pop up.

Click to Enlarge

After the test is completed, a result screen will be provided:

Click to Enlarge

The tested URL and a timestamp of the test are the first things to appear on the page. An initial load screenshot is then provided as well as an option to see what the return load screenshot looks like. This is one of the unique features of the Browser Full Page test. It is initially simulating a first-time user experience and, immediately after that, a second test is performed to simulate a repeated user experience. Screenshots are then made and the collected data is reported.

Next is the WebSitePulse performance grade score that, in this case, is almost perfect – 99/100. Congratulations, Google! An information about the number of requests made and the total page size can be seen next to the score itself. First and return visit times are also displayed below.

Switching our attention to the Request Timeline below, we will notice a breakdown of all page components (3 in this case) and how long it took to load them on both the initial and return load tests. You can easily navigate through the timeline by clicking the Initial Load, Return Load and Both Combined buttons on top of the chart. Clicking the magnifying glass icons on the right will reveal the request and response headers for the selected element.

Click to Enlarge

Switching to the recommendations screen is easy - simply click the Recommendations button. Having mentioned that Google.com performed pretty well on our test, we can still hint improvements for its performance and responsiveness. Here is what we have to say for that one:

Click to Enlarge

You can also Tweet and share your results on Facebook or Google+. Or, if you still do not have an account with us, you can click the Start a FREE Trial button and set your site up for monitoring. You will get all of the functionality described above, plus tons more like several different types of alerts, takeover feature, 24/7 e-mail, chat and phone support, 40 locations around the world etc.

So, what is your WebSitePulse score?

What You Need to Know about In-browser Monitoring, Part 1

December 19th, 2013
Posted in Tools

Monitoring your website is not just a preemptive measure

We all know that companies invest a lot of funds and efforts to build up a good image of its products and services. A rock-solid corporate identity could be a great corner stone for gaining and increasing the public trust of your company’s current and prospective clients. Once you have established a good company name, the main goal of the management is to keep that name clean and safe. And they do it, or at least they try to do it the best they can. 

But what happens when your name, your brand and the whole company identity are placed on the Web – just under the lid of a server plugged into the Internet? A place where, a bunch of machines control the performance and availability of your brand name and pretty much decide your company’s future. What happens when the servers you rely on stop working? Or when the end user is unable to buy your product just because of a bad website performance or a broken router?

A couple of years ago I came upon an article where Forrester Research published their research data regarding website performance and speed. They pointed out that if the loading time of the page exceeds more than 2 seconds, the end users are more likely to move to another website. Keep in mind that this data was collected back in 2009. The technologies have developed a lot since then and everything loads much faster now. With each year of technological development, the Internet speed increases and with that - the expectations of the end users go up as well. According to the results of another research by Google, only 250ms difference in the loading time of a specific website is enough to make the end user close the tab.

Considering the above, you could conclude that the performance of your website is extremely important for you and your business and thus - monitoring your web assets is a must and not just a preemptive measure.

The monitoring tools can help not only your engineers but also the decision-makers to keep the reputation of your company safe in the digital world as part of a quality online marketing strategy. This way you achieve higher availability and improve the performance of the HTML code, jpgs, css frames and any other components of your web site.

But, as we already mentioned, the technology is developing with an incredible speed and so has the architecture of the websites. Most websites are no longer just HTML code, text content and jpgs. It is almost impossible to surf a website today which doesn’t have any scripts implemented in it. Most developers now widely use Javascript, AJAX calls, iFrames etc. All these tools provide additional functionalities to the applications, but unfortunately are hard to monitor with most ordinary monitoring tools. But why?

When the end user enters the desired address in the address bar of his browser and clicks "enter", the following happens:

  1. The browser breaks the address to its fundamentals: scheme, host, port, user, pass, path, query, fragment
  2. Then the host must be resolved
  3. If no issue occurs, the browser opens a TCP connection (there is an exchange of certificates in case the connection is secured)
  4. Once the connection is established, the browser sends a request to the server, as the request depends on the type of the protocol (request header)
  5. Then the browser receives a reply from the server split in two – response header and content.
  6. As soon as the browser gets the content starts visualizing it (the visualization includes re-creating of the content as any of the implemented scripts requirements are observed accordingly.)

The good news is that all these steps are executed with the blink of an eye and the end user gets the results as soon as the page is completely loaded in front of him. However, the implemented scripts in the content are impossible for monitoring with the ordinary monitoring tools because in their essence, the traditional monitoring tools are scripts programmed to execute the steps above without having the possibility to visualize the received from the server content. Why? Simply because they do not have an engine (as the browser has) which to de-compile the received content.

All this should not make you think that the traditional monitoring tools are not effective. Of course they are. It just depends on what you are using them for.

And when the situation requires monitoring of a website full of scripts, the best solution is In-browser monitoring.

In Part 2 I will explain to you how the in-browser monitoring works and how it can be of help to you.

 

What Is a Traceroute Test?

March 7th, 2013
Posted in Tools, WebSitePulse News

If you're having issues with your network connection, you may need to investigate exactly where the problem is occurring. Maybe your data packets are getting stopped right out of the gate, or maybe it's just a particular route that they're taking that is causing the issues.

A traceroute test shows the exact path that you're taking when you're trying to connect to a specific IP. This information tells you exactly where the breakdown happens, and it can aid you in trying to fix it.

Most operating systems have this tool available:

Mac OS X based systems access this tool through Network Utilities or by using terminal to send a traceroute command.

Windows provides this tool through the command line with the command tracert.

Most Linux-based distributions use the traceroute or the similar tracepath tool to provide you with this information. If you don't want to bother with going through the operating system tools, or if you aren't sure how to navigate a command line or terminal, web-based traceroute tests are available.

For example, WebSitePulse offers a website test through its site. This test performs a traceroute test and shows you every hop that a particular data packet takes to try to reach its destination. No matter where you access this test from, the exact process the computer performs during a traceroute is identical. It creates a number of ICMP echo request packets sent to a specific host or IP address. These packets are sent to the host by a path determined by the router, with alternative hops used if a particular connection times out. You receive specific information on the routers that the data has been sent through, as well as how long it takes for the data to go through. This measure of time is denoted with a response time value. Traceroute tools which use TCP or UDP packets instead of ICMP for their testing are also available.

Note that the route that the packets take may vary every time you try to access a specific host. The routers look for the most efficient path, which may change over time or during different times of the day due to network traffic.

If you identify a problem with the particular route that the data takes, you have a few options on how to fix it. Sometimes entire networks go down temporarily, which makes it difficult to reach a particular portion of the web. Other times the issue is just with the path, and retrying the connection fixes the problem. You can use this information to figure out whether a host is fully down or if the path was just taking you through connections that were not currently working. No matter what specific need you have for it, a traceroute test is a very handy tool to have when you're running into network problems. Whether you're an end user, or a network admin, chances are you're going to be using this tool quite often.

Traceroute testing has a number of parameters you can adjust to fine-tune the diagnostic usefulness of it. You can change the packet types to deal with firewalls, use additional protocols, change the wait-time per hop to see if increasing the timeout time will create a successful connection, and other features. This tool helps to fix bad routing tables and high ping. Even if you don't think you're ever going to use a traceroute test, it's good to know that it's handy if you need it. It’s best to the web-based kind, and since it’s not platform-specific it means you can bring it up on any operating system you want.

Check out the video to get an idea of how the test is performed:

Now, try out the traceroute test tool yourself:

Free Website Test tools by WebSitePulse

How to measure website response time?

November 28th, 2012
Posted in Tools, Tech

Everyone who operates an online business understands the importance of having fast website response times. When webpages are simple to perceive, the user will spend more time on your pages, and are much more likely to spend money while they are there.

The "end user", or the client, or buyer who visits your website, is the entire reason your website was built, and having a deep understanding of how to influence their behavior while on your website can be critical to your business's success.

Fast website response times can also be critical to influencing buying behavior, as your website performance is often judged as a reflection of the quality and competence of your business skills.

To guarantee the fastest possible response times consistently, it is critical to make your measurements of your websites performance in the same way the end user perceives it. Continuous measuring with testing tools also helps flush problems to your attention as soon as they arise.

The questions to keep in mind while building and testing the website for its highest quality, and keeping it operating at its peak performance capacity are:

 

  • How do I measure the customers response time experience?
  • What tools are available to make the measurement process simple, automated and accurate?

What to measure and how to do it

Response time is commonly considered to be the amount of time that passes between when the user requests the first byte of information until the last byte of every image, style sheet or java file scripts are delivered to them.

website response time test result

Network analysis tools are designed specifically for this. Using these tools makes it possible to:

  • See the downloads within an accurate timeline view
  • Follow illustrations that accurately demonstrate what is happening for users
  • When browsers start analyzing response times for content of requested html documents:
  • How can an effective determination of how much time it takes for the first embedded images to download be made?
  • Do you measure the time from the first request for information and the delivery time to the very last request made for website information?

Measuring more than just HTTP traffic

Browsers are used for more than simply accessing resources from servers. Document object models are also built to maintain necessary document downloads. Elements are then attached to the document model -- then styles are applied to them according to definitions in the style sheets. The JavaScript is then used during differing points when triggered by events like on-loading and on-clicking. This triggers document object-models to be delivered to the screen.

Stopwatch measuring vs. tool supported measuring

Some use a stopwatch to measure page loading time. It is also sometimes used to measure the time till the page becomes responsive. The watch-measured numbers are placed in a spreadsheet. This makes it possible to determine performance values. This is not the most accurate method, needles to say, there is also a big margin for error.

Conclusion

Using professional website response time measuring tools enables automated web website performance measuring. They are highly effective for manual and automated testing environments. Continuously measuring web website performance in the browser allows the ability to focus on end-user performance. In the end it will determine the success of your website.