Desktop vs Web view performance

[#1]

Hi,

I have an application with 10M rows. While, QV's performance is "almost" acceptable when I am in desktop view (running on an hp laptop with 8Gig of Ram), it really slows down when I switch to Web view. Worst yet, when I deploy the app to the production server which has 32Gig of Ram, hitting the application on the server from a web browser, performance just goes south - and one of my tables actually throws "memory exceeded" error message.

So, Can someone explain what could be going on here, and what do I need to know in order to maximize the performance for the end users hitting the app on the server with their browsers? Why on my laptop the desktop view is so much faster than the web view- where the data is being hit locally on my hard disk and there is no line latency variable in the picture.

[JonnyPoole]

Hi Dennis - what version and browser are you using ?   IE8 is very slow with the AJAX / Zero Footprint/ full browser version.  IE10 is ok and then Chrome and firefox are ok too.   IE8 is better with the plugin which you can install/download.

If we can resolve any browser issues we can move onto the data model, server specs etc...

[#3]

I am running it with chrome version 37.0.2062.124 m

IE9 built 1642 feels the same as chrome (with the same "exceeded memory" msg for one of my  tables).

[JonnyPoole]

You can try the IE plugin for better performance online .. it doesn't use the 'web view'. 

The 'Web View' or AJAX can really slow down if you have wide and deep straight tables or pivot tables (many columns and many rows) ... do you have that ? 

[#5]

Yes, my application has many long pivot and straight tables, in fact I don't have any charts. The "exceeded memory" message appear on a pivot table that has a rather complicated calculated dimension like below:

=Valuelist('$(=field1)', '$(=field2)','$(=field3)','$(=field4)')

and each row of the pivot table calculates expressions such as following:

=pick(

match(

Valuelist(

'$(=field1)', '$(=field2)', '$(=field3)','$(=field4))'

)

, '$(=field1)', '$(=field2)', '$(=field3)','$(=field4)'

)

, count({1<field1 = {'$(=field1)'}>} distinct fieldx)

, count({1<field2 = {'$(=field2)'}>} distinct fieldx)

, count({1<field3= {'$(=field3)'}>} distinct fieldx)

, count({1<field4= {'$(=field4)'}>} distinct fieldx)

What exactly is the IE plug in you're referring to please? It might be against  policy to install plug-ins , but I need to know what exactly is it.

thanks,

[JonnyPoole]

Its a thin client web viewer. You can enable the download on access point through a setting in the qlikview management console in the web server area.

[#7]

Ah, so it's something that needs to be enabled on the qlikview server, but not on users' IE, correct?

[JonnyPoole]

Not fully. 

You enable a setting on the server, and the link to download/install the plugin (on the users machine) shows up in access point:

To do that hit the QMC -> QlikView Web Server -> access point and there is checkbox to expose the download link.

Once you or a user have installed it, you have the option or setting a default preference to open the app in the thin client plugin (IE browser only). The performance will be better

alternatively or in parallel consider implementing large tabular views with checkboxes that the user must pick to see progressively more columns. As an example, look at the reports tab in this demo example.

http://us-d.demo.qlik.com/QvAJAXZfc/opendoc.htm?document=qvdocs%2FWhats%20New%20in%20QlikView11.qvw&...

[#9]

Calculated Dimension are generally degrade the performance, consider moving all these complex expression at the scripting. May be you can consider it for long term solution.

[#10]

Upgraded to latest SR8. The pivot table with calculated dimensions as stated above still fails in  ajax mode and throws: "Allocated Memory Exceeded." This error message appears even if I load only a few handful of records and limit the rows of the pivot table to only 1 row. Again, desktop mode has no problem with 10M rows. Ajax falls flat on its face - IE plug-in makes no difference.

Clearly, I have hit a deeply hidden bug in QV and experiencing the shortfalls of the QV ajax mode.