The Cloud is STILL too slow!
Posted
by harry.foxwell(at)oracle.com
on Oracle Blogs
See other posts from Oracle Blogs
or by harry.foxwell(at)oracle.com
Published on Wed, 16 Mar 2011 12:01:25 -0500
Indexed on
2011/03/17
0:16 UTC
Read the original article
Hit count: 445
Filed under:
If you've been in the computing industry sufficiently long enough to remember dialup modems and other "ancient" technologies, you might be tempted to marvel at today's wonderfully powerful multicore PCs, ginormous disks, and blazingly fast networks. Wow, you're in Internet Nirvana, right! Well, no, not by a long shot.
Considering the exponentially growing expectations of what the Web, that is, "the Cloud", is supposed to provide, today's Web/Cloud services are still way too slow.
Already we are seeing cloud-enabled consumer devices that are stressing even the most advanced public network services. Like the iPad and its competitors, ever more powerful smart-phones, and an imminent hoard of special purpose gadgets such as the proposed "cloud camera" (see http://gdgt.com/discuss/it-time-cloud-camera-found-out-cnr/ ).
And at the same time that the number and type of cloud services are growing, user tolerance for even the slightest of download delays is rapidly decreasing. Ten years ago Web developers followed the "8-Second Rule", (average time a typical Web user would tolerate for a page to download and render). Not anymore; now it's less than 3 seconds, and only a bit longer for mobile devices (see http://www.technologyreview.com/files/54902/GoogleSpeed_charts.pdf). How spoiled we've become!
Google, among others, recognizes this problem and is working to encourage the development of a faster Web (see http://www.technologyreview.com/web/32338/). They, along with their competitors and ISPs, will have to encourage and support significantly better Web performance in order to provide the types of services envisioned for the Cloud. How will they do this? Through the development of faster components, better use of caching technologies, and the really tough one - exploiting parallelism. Not that parallel technologies like multicore processors are hard to build...we already have them. It's just that we're not that good yet at using them effectively. And if we don't get better, users will abandon cloud-based services...in less than 3 seconds.
Considering the exponentially growing expectations of what the Web, that is, "the Cloud", is supposed to provide, today's Web/Cloud services are still way too slow.
Already we are seeing cloud-enabled consumer devices that are stressing even the most advanced public network services. Like the iPad and its competitors, ever more powerful smart-phones, and an imminent hoard of special purpose gadgets such as the proposed "cloud camera" (see http://gdgt.com/discuss/it-time-cloud-camera-found-out-cnr/ ).
And at the same time that the number and type of cloud services are growing, user tolerance for even the slightest of download delays is rapidly decreasing. Ten years ago Web developers followed the "8-Second Rule", (average time a typical Web user would tolerate for a page to download and render). Not anymore; now it's less than 3 seconds, and only a bit longer for mobile devices (see http://www.technologyreview.com/files/54902/GoogleSpeed_charts.pdf). How spoiled we've become!
Google, among others, recognizes this problem and is working to encourage the development of a faster Web (see http://www.technologyreview.com/web/32338/). They, along with their competitors and ISPs, will have to encourage and support significantly better Web performance in order to provide the types of services envisioned for the Cloud. How will they do this? Through the development of faster components, better use of caching technologies, and the really tough one - exploiting parallelism. Not that parallel technologies like multicore processors are hard to build...we already have them. It's just that we're not that good yet at using them effectively. And if we don't get better, users will abandon cloud-based services...in less than 3 seconds.
© Oracle Blogs or respective owner
