Cloudlook is a simple, free and fast way to monitor the performance of a web server in the cloud. Just drop in a PHP file and Cloudlook will instantly measure your server's speed. Once Cloudlook is installed, your server will be checked automatically every 5 minutes, with the results displayed on a simple chart.
After you sign up, Cloudlook provides you a PHP script to place in the website that your cloud server is hosting. Cloudlook communicates with that script at regular intervals to test your server's performance and health. No other configuration is required.
When testing the speed of a personal computer or dedicated web server, a one-time benchmark is sufficient to measure that computer's performance. The CPU, memory and disk will always work at the measured speed, unless they are under a heavy load that you are aware of.
But things are different in the cloud. You will generally be sharing a host server with other users, whose presence is hidden from you by that server's hypervisor. The performance of your cloud instance can vary drastically, due only to the behavior of these other users.
By monitoring cloud instances over an extended time period, Cloudlook can accurately measure average performance as well as the variability of that performance. Both statistics are vital in order to understand the true characteristics of a server in the cloud.
Yes and no. The amount of memory and disk is specified exactly. But the performance of your instance's CPU, memory and disk is generally not specified. These resources are shared between all of the cloud instances running on a particular host server. So their performance will depend greatly on the load generated by the other users who are sharing your host.
Cloudlook requires PHP 5 running under web serving software such as Apache, nginx or IIS. Your website does not need to use PHP in order for Cloudlook to work, so long as you have PHP installed and configured correctly. In fact, your server need not be hosting a real website at all, so long as it responds to incoming HTTP requests related to Cloudlook.
Below is a technical explanation of how we calculate Cloudlook's performance measurements using PHP. You are also invited to read the source code of the Cloudlook PHP script.
PHP's built-in functions are written in C and compiled to run natively on the host system's processor. For example, if a PHP script calls the function md5 to calculate an MD5 checksum, the calculation is actually performed by the compiled C code in ext/standard/md5.c.
By poring over the PHP sources and testing over 60 versions of PHP, we've identified three core PHP functions which spend a long time in compiled C code and perform consistently over all versions of PHP 5. These functions are crc32, sha1 and levenshtein.
Cloudlook measures the speed of repeatedly calling these functions in a tight loop. By using long input strings, it minimizes the time spent in PHP's bytecode interpreter, whose performance can vary across PHP versions. The measured speed is mapped to the equivalent clock speed of an Intel Core i7 processor, which was benchmarked separately on dedicated hardware.
Concurrency refers to the number of CPUs (or CPU cores) which are available to a cloud instance for parallel processing. Cloudlook measures concurrency by sending multiple HTTP requests to the Cloudlook script at the same time. Each request triggers a batch of CPU tests to be performed in a fixed time window. The aggregate performance of these tests is compared to the instance's single-threaded performance in order to calculate its concurrency.
Cloudlook creates a string in memory which is long enough to saturate the caches of all modern CPUs. It then uses PHP's substr function to repeatedly copy consecutive small windows from that string into a new region of memory. The copying is performed within the PHP internals by _estrndup in Zend/zend_alloc.c, which in turns calls the optimized C function memcpy.
If you choose to perform disk benchmarking, Cloudlook builds files in the temporary directory of your web server to be used for sequential and/or random access benchmarking. To avoid the results being skewed by caches, the files must be larger than the total amount of memory available to the operating system.
For the sequential disk benchmark, Cloudlook tests the rate of reading data from the benchmark files in a round-robin sequence, following the same order in which the data was written out. In combination with the large total file size, this ensures that the operating system page cache is constantly flushed by new data, and so cannot interfere with the benchmark's results.
For the random disk benchmark, 4KB blocks are read from the benchmark files in quasi-random order, so the disk must always seek to a new location before reading the next block. Cloudlook distributes the requests using a fibonacci hash function in order to maximize the time between adjacent blocks being read. If necessary this step size is adjusted to ensure that each 4KB block is read from the files once in rotation before the cycle begins again.
Because placing a single PHP file on a server is a very simple method of installation. No root access, no compiling, no daemons, no strange protocols and no need to reconfigure your firewall. Just drop it in and you're ready to go. As a bonus, you can read the PHP source code to see exactly what we're doing, and check your web logs to see how often we're doing it.
By default, Cloudlook performs a short burst (up to two seconds) of activity on your instance once every five minutes. Overall, this is less than 1% of your instance's capacity. During those two seconds your server may perform slower than usual, but other activities will not be interrupted.
You can change your Cloudlook settings at any time to pause monitoring of your server. Or just remove the Cloudlook PHP file from your web directory – our systems will soon notice the 404 errors and stop sending requests your way.
Cloudlook was created by Gideon Greenspan and Michael Rozantsev, due to their frustration at the highly variable performance observed in cloud computing instances. We also wanted to compare the price/performance of public cloud providers to decide where to host our projects.
Please contact us here. We would love to hear your feedback, good or bad.