Warning: If in the last few days, you happened to hear an unearthly wail of pain, followed by a rather unprofessional string of profanity, I humbly ask your forgiveness. That was me, but I had fair cause. No, it wasn't hackers assaulting Facebook that triggered the outburst. Rather, the application I used to blog in real time did not save my article or any of my changes, so when I had a system interruption, two hours of work went down the drain. Hence my lapse, which made me ponder a few things about performance.
After my tantrum, the engineer in me kicked in and began troubleshooting my issue (I know, I’m sounding like phone support without hold music – bear with me). At some point, I lost contact with my blogging cloud application, and it occurred to me that performance breaks down into several segments.
From the application – from any cloud application to my desktop we are talking about four different potential bottlenecks – and measuring points – in the overall performance of a cloud application. These waypoints are Browser Performance, Network Performance, Cloud Infrastructure Performance, and Application Performance.
Cloud Infrastructure Performance to me means the performance of Amazon’s EC2, if I happened to be using it (in the case of my blogging, it was not). However if I were getting a SLA (service level agreement) to develop a cloud solution for my organization, I would want to quantify the performance of this vital cloud component when applicable.
The Browser: I did touch on this in my earlier review of Google Chrome 2.0, and its improvement in performance over the original Chrome. We often take the performance of the browser as a given. However a user of Google Chrome will tell you that there are significant differences between Chrome and Chrome 2.0, with the 30% improvement in performance. Firefox raises the ante with the release of Firefox 3.5. As more and more Web 2.0 applications utilize Java applets that demand resources, browsers that efficiently use those resources are of paramount importance. All browsers certainly are not created equal (as my recent testing trials involving IE7, Firefox, and Safari have proven), and that needs to be quantified.
Network Performance: When considering putting applications for an organization in the cloud, the network performance is the first non-browser bottleneck, if I'm directing myself outward from the user perspective. Wearing my SLA hat again, the development of a strong network infrastructure is a must, and really not subject to compromise. Think of this as a variation on the issue that caught some users unaware in the “Web 1.0” era. High-speed fiber/broadband service to a neighborhood - but no fiber into homes. Result: Questionable performance for the end user – because you are only as fast as your slowest link.
Application Performance: Let’s file this under “No Brainer”. Or is it? We do tend to take the performance of applications for granted these days. At least the ones we buy off the shelf. However, with applications in the cloud itself, "benign" memory leakage issues aren’t so benign anymore. A momentary application hang in the old client-server, or self-contained application paradigm – what happens if system resources are strained in the cloud? The Blue Screen Of Death is not an option. Application performance should be judged not just by usability of course, but by the ability to handle user needs when the network is slow and data in transit could be compromised.
As I stated at the beginning of this post, I lost information due to a system burp, and perhaps some misplaced confidence in the autosave capabilities of my cloud application. It was the second time it happened on this article alone/ At this moment, I’m writing this on MS-Word as a contingency. It is a fair question to ask for users such as myself doing editing work in the cloud: How are you protecting my real-time editing from disaster?
Performance. In four important components none of them trivial. Keep it in mind when testing - or using your application of choice.
Comments