… and points beyond

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.

My apologies for the code that was posted here. Copying and pasting broke the code. Download a ZIP of the code here.

I have expanded on the demo code that was floating around at Qonnections 2008. That code included an ASP page that made the requests using system objects and will not work outside IIS.

What about getting rid of IIS entirely? There are some changes we need to make. We want a ticket for a user other than the one making the request (GetTicketForMe). To do that QVHTTP requires POST instead of GET. The username, contained in XML, is passed as the body of the POST request. The requester must be authenticated as a member of the QlikView Administrators group.

To play with the test page:

• Be sure that the IIS website is stopped and QlikView HTTP Service is started.
• Copy the code below into an HTML file and save it in the QVHTTP base directory. For QV 8.2, this is C:\Program Files\QlikView\Examples\QvsHtmlWebpages\.
• Switch the QV Server to use DMS instead of NTFS authentication. Edit the metadata and add a username to a QV application.
• Load the demo page in IE or Firefox. For example, http://QVServer/qlikview/FileName.html.
• Fill in the name of the app you want to load and the user ID for the ticket request.
• Press the buttons to load the app using a requested ticket.
• The requester must be authenticated as a member of the QlikView Administrators group.
• A ticket will be issued and either displayed or used to request the app.

Each time you press a button, a ticket request is made. The QV Server issues a new ticket even if you request the same user ID again. User IDs are not case sensitive.

Unfortunately, this is not a complete implementation. Behind the scenes, the QV HTTP Server and your browser negotiated an NTLM authentication. This may have been transparent depending in your Windows network, but otherwise you were asked to provide the user & pass of a member of the QlikView Administrators group.

The point is that NTLM authentication is something supported by your browser and that the software issuing the POST request needs to handle NTLM authentication. There are resources that describe NTLM authentication in detail if you want to implement your own. There are tools (such as WGET) that support POST requests and NTLM authentication and can be scripted, though I have yet to try it. Indications from QlikTech are that they will add a more flexible option to authenticate the requester in upcoming versions.

I’ll be trying to do a scripted ticket request using a utility like WGET in the future. I’ll let you know how it goes.

Again, my thanks to Henric Cronstrom, Dan English, Ingemar Carlo, Johan Jeansson and Claus at QlikTech.

My apologies for the code that was posted here. Copying and pasting broke the code. Download a ZIP of the code here.