Archive for January 2011

Are Enterprise Cloud Platforms Pivoting Vertically?

Posted by Tom Lounibos on Jan 31, 2011. 1 Comment

Up until now Cloud Platforms have typically been defined as Public, Private, or Hybrid.   These descriptions, of course, are based almost entirely on the accessibility and ownership of the servers and not by the application in which they are being used.  This may all be changing in the coming months, especially for the enterprise market as “vertical” clouds begin to emerge. These new vertical platforms will continue to offer all the same capabilities that current private, public, and hybrid cloud platforms offer today, however they will also begin to offer more industry and application specific cloud services over a network of cloud providers.  Think of a Financial Services Cloud Platform (or even a Brokerage Platform) that may deliver a greater level of security around customer data. Or a US-based Health Care Cloud Platform that offers additional HIPPA compliance capabilities.

For our part, SOASTA has been building such a vertical cloud platform for the past three years and will be unleashing it (next week) for the first time with a brand new product announcement. This new SOASTA offering will be the largest Test Platform ever assembled, built exclusively for companies needing to quickly and affordably perform Load and Performance testing on their consumer facing web sites. It will provide a powerful illustration of how cloud computing has been vertically optimized by a specific application and not the other way around.

More and more vertical cloud implementations will be emerging in the coming months, and with them greater value in cloud computing, especially for those of you in the enterprise markets.

Performance Testing Mobile Devices

Posted by Dave Murphy on Jan 21, 2011. 1 Comment

Whether you’re talking about smartphones or tablets, the sales of mobile devices are skyrocketing. While Apple’s iPad and iPhone and Android dominate the news, and sales, there are a huge number of options. By their very nature they’re connected to the web, and use the Internet for much richer applications than just email and web browsing. Everything from games to video is available on these devices, putting a strain on bandwidth and the back end servers that are providing the content.

That makes performance testing very important and companies such as Netflix, Glu, Leapfrog, Capcom and more have come to SOASTA to make sure they can handle the load. So, how do we do it?

When testing any web application, whether browser-based or not, CloudTest captures, replays and reports on every message between the client and the application infrastructure. Unlike other tools, CloudTest’s unique recording does not depend on a browser plug-in to record web traffic, which also limits you to using the browsers for which you have plug-ins. Instead, we use a web proxy to record traffic. An agent, called Conductor, is installed on any system that you want to have act as a proxy. This can be the same laptop used to record browser-based traffic or a completely different system.

This means that all messages from any device (browser, phone, tablet, toy, etc) that you point to the proxy for web traffic can be recorded into a CloudTest test case. Once recorded, the requests can be parameterized, manipulated and otherwise massaged to create the complex usage patterns and high volumes of traffic needed for a load test.

Recording HTTP/HTTPS Traffic with SOASTA’s conductor agent acting as a proxy – regardless of the device, browser, application or operating system as long as it communicates over HTTP or HTTPS and supports a configurable proxy then CloudTest can record the traffic

In some cases, such as games running on the phone or tablet, the application is simply making web services calls. We record that message traffic just as easily as we do for any other application. CloudTest automatically parses WSDLs, has built-in OAuth support and features for making RESTful web services testing simple.

CloudTest is not testing the functional capabilities of the device. When we play the test back, we’re emulating the traffic just as the device would communicate to the infrastructure. This simulated load puts the same stress on the back end as the devices themselves would, at whatever levels of use you want to test.

CloudTest Analytics captures and displays in real-time the performance metrics on the message traffic, such as response times, bandwidth usage, error rates, time to first byte, etc. If monitoring is in place on the infrastructure we’ll also capture and display metrics such as CPU utilization, memory consumption, heap size and process counts on the same time-line as the performance metrics, helping our customers to quickly find the bottlenecks that might impact the user experience.

Join the forum discussion on this post

CDNs: Great for Performance, but not a Guarantee!

Posted by Robert Holcomb on Jan 06, 2011. Leave a Comment

Content Delivery Networks (or ‘CDNs’) provide a way to spread the static assets for a web application to different geographies and different networks to improve the performance of a web application.  The performance gains are primarily the result of assets being located closer to the end user and on faster network connections.  As a best practice, SOASTA recommends that web applications make use of CDNs whenever possible.  It is an easy way to improve the performance of a web application and the number of concurrent users a web application can support.

Some have the misconception that simply implementing a CDN for a web application eliminates the need to pay further attention to performance concerns.  That couldn’t be farther from the truth.  Implementing a CDN certainly improves the performance of an application.  However, all it does is move the needle.  Let’s say you have a site that can support 3,000 concurrent users before the application bogs down.  Adding a CDN to the mix will perhaps allow you to support 4,000 users before the application bogs down.  It just changes the point of failure – not eliminate it.  And that assumes that the delivery of static assets was the bottleneck in the first place.

A CDN does not help overcome performance issues at the application and database layers.  We’ve worked with many large, well-known web applications and found significant issues at the application and database layers – that weren’t mitigated by the use of Akamai, Internap, or some other CDN vendor.  Implementing a CDN won’t help you overcome a misconfigured java heap.  It won’t help you overcome garbage collection issues.  It won’t help you overcome indexing or other database bottlenecks.  It won’t help you overcome a misconfigured load balancer.  These are the issues that running a load and performance test utilizing real-world user scenarios will help uncover.

Based on the tens of thousands of tests SOASTA has executed, CDNs and static resources are rarely the point of failure in an application (unless the network is saturated because a CDN has not been implemented).  More often, the performance bottleneck is at another layer of the infrastructure: load balancer, firewalls, application, and database servers.  As a result, if you don’t run load and performance tests against your web application, you aren’t even testing the most likely places your web application will break.

Email Us!
Subscribe to our Feed!
Find us on Facebook
Follow our Tweets
See our pics