QlikView depends entirely on processor speed, processor cache performance, memory latency and memory throughput. This makes QlikView an ideal reference for Intel, who uses QlikView to show off the latest product improvements. It also adds to the challenge of adapting QlikView to cloud platforms such as Amazon Web Services, Mosso, Joyent, etc.
The problem is virtualization. Virtualization is valuable to customers and service providers, but it’s also a thief! It adds overhead for the processor, cache and memory–everything that impacts QlikView performance!
The cloud, as in real life, is ever changing. You have no idea how many people are sharing your hardware and what their load will be from second to second. I would bet that nearly all deployed QlikView servers spend most of their time idle and the rest of their time at peak processing power. In the cloud, the goal is to spend as little time as possible idle for which we sacrifice peak processing power. QlikView depends on peak processing power and that type of application will suffer the most in the cloud.
But exactly how much will it suffer? Success in the cloud will need to be measured by the end-user experience. The cost of being in the cloud is vigilant monitoring and smart responses. What’s the right way to monitor the end-user experience in a company that uses OCX vs. AJAX, or is spread out geographically? Will bringing up more servers in the cloud improve response time? Should every QlikView server deliver the same set of apps, or should each app be served by a dynamic set of servers? Similarly, do some apps need sub-second response time while others can wait?
One thing stays the same. If you deploy large QlikView data sets you’re already sensitive to response times and what to consider when designing an app. In the cloud, smaller apps will need to think about costly chart expressions, messy data models and design choices that work fine on dedicated servers.
Related posts:
Pingback: dedicated servers comparison | Digg hot tags
It will be interesting to see, with the projected rise of in-memory BI solutions, if providers’ SLAs will be able to meet the demands of moving applications like QlikView into the cloud…and what of network latency and bandwidth? If your throughput is iffy, I imagine that would be the bottleneck, rather than the cloud server’s processing power.
Thoughts?
Thanks, that’s a great point. In traditional services network (bandwidth, latency or both) is guaranteed but in the cloud, so far, we have no control.
DIM (direct in memory) BI is an iffy proposition as in the best possible scenario, you’re looking at 1TB of virtual memory on x64 systems at the most. So if I have a 50-100TB DW, what do I care about a cloud BI solution anyway? That being said, Panorama has a hybrid client/cloud offering that seems better suited to smaller mart cloud apps than QV.
Thanks for the comment. At those sizes, you are actually more interested in cloud solutions, but not necessarily in-memory. They offer massive parallelism that is dynamically allocated. This reduces hardware/software costs and management personnel.
Which Panorama offering were you thinking of? I’d like to look into it.
@Jonathan,
I don’t think that anyone is putting that much data into the cloud at this point anyways. QlikView’s database compresses the data a good bit, and has the ability to do partial reloads (a la MOLAP), but any company that has a DW that size isn’t using the cloud for their purposes. QlikView in the cloud would be best for a mid-size company that doesn’t want to purchase or maintain servers.