topic Re: Desktop vs Web view performance in QlikView

Desktop vs Web view performance

Mon, 26 Jan 2026 18:19:17 GMT

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.

Re: Desktop vs Web view performance

JonnyPoole — Fri, 10 Oct 2014 19:51:31 GMT

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...

Re: Desktop vs Web view performance

Fri, 10 Oct 2014 20:07:36 GMT

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).

Re: Desktop vs Web view performance

JonnyPoole — Fri, 10 Oct 2014 20:26:33 GMT

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 ?

Re: Desktop vs Web view performance

Fri, 10 Oct 2014 21:18:40 GMT

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,

Re: Desktop vs Web view performance

JonnyPoole — Fri, 10 Oct 2014 22:15:22 GMT

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.

Re: Desktop vs Web view performance

Fri, 10 Oct 2014 23:34:32 GMT

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

Re: Desktop vs Web view performance

JonnyPoole — Sat, 11 Oct 2014 00:46:18 GMT

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&host=demo11

Re: Desktop vs Web view performance

Sat, 11 Oct 2014 08:02:26 GMT

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.

Re: Desktop vs Web view performance

Tue, 14 Oct 2014 00:48:33 GMT

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.

Re: Desktop vs Web view performance

JonnyPoole — Tue, 14 Oct 2014 14:43:07 GMT

When you say the following, does that mean that using the IE-Plugin results in the same error ? same performance issue ? . Also when you upgraded to SR8 was that the desktop and server version ?

" IE plug-in makes no difference."

Re: Desktop vs Web view performance

Wed, 15 Oct 2014 04:59:07 GMT

Hi Jonathan,

Thanks for sticking with my problem. Yes, I upgraded both my desktop and server to SR8 level. I then downloaded and installed the plug-in in IE9. For the most part, I do see some performance improvement with most of my tables (I also implemented the approach in the demo app you suggested above). But, one of my pivot tables just does not want to work and throws that "Allocated Memory Exceeded." error message. I am not sure if this error is data volume related- as I explained, it fails with even limited number of pivot rows and very light imported data.

Re: Desktop vs Web view performance

jonathandienst — Wed, 15 Oct 2014 05:34:23 GMT

Dennis

As a previous poster pointed out, calculated dimensions can be performance killers. When combined with the valuelist and a pick/match structure like you have, I expect that performance hit to be magnified.

But it sounds to me like you may have a problem in your data structure as 10m rows is not a very large model and your hardware should cope with that. Examples would be large tables with low or zero cardinality association, which results in very large temporary tables when performing calculations, or expressions that span too many tables, as well as multiple page jumps (eg an field in table A and another field in table B with the association indirectly through table C).

Perhaps you could post some more detail about your data structure and the actual expression used.

HTH

Jonathan

Re: Re: Desktop vs Web view performance

Wed, 15 Oct 2014 23:50:52 GMT

Hi,

Attached please find a qvw application that has the data model that I use in my real app. I have used dummy data here to make it simple to follow. As you can see the amount of data loaded is very minimum). This application runs in the desktop version of QV, but if you upload it to the server and run in ajax mode, the 'Customer Pairing Report' table fails to render.

Here is brief description of the model:

Customer table: the fact table

All other tables: lookup tables

Please let me know your thoughts.

Re: Desktop vs Web view performance

SergeyMak — Thu, 16 Oct 2014 01:28:45 GMT

Hi Dennis,

It looks over complicated. I think it's possible to make it easier.

Could you describe what are you trying to calculate there? What are the requirements?

Firs of all, I think, you can join all INFILED tables to Customer Lookup and Category lookup to subcategory lookup.

You don't need third normal form in QlikVIew

Regards,

Sergey

Re: Desktop vs Web view performance

Thu, 16 Oct 2014 02:10:45 GMT

Here is what the table suppose to calculate.

If user select a customer from the Customer list box, the pivot table calculates the expressions for that customer as one of the dimensions (highlighted in green in the table). Let's say he selects Customer E. This customer has a 'Size' field value of 1M. Then, the table should calculate the expressions across all customers who have the same 'Size' field value (1M) as the second dimension (1M highlighted in yellow in the table).

The listbox titled 'Customer Pairing View' simply replaces the second dimension (Size in this case), with its current selection. So if user selects 'Ownership' from this list box, the pivot table's second dimension would be 'Public' - which is the Ownership field value of Customer E. This is to allow benchmarking a selected customer (Customer E) against all other customers who have the same Size, or the same Ownership, or the same Geography dimensions.

The Pairs listbox determines which PAIR values to show in the pivot table - this is just to extend/limit the depth of the pivot by the user.

Hope this is clear.

Re: Re: Desktop vs Web view performance

SergeyMak — Thu, 16 Oct 2014 02:58:53 GMT

So, I simplified your calculations.

Check if it's correct, than delete all your calculated list boxes and table and try it on the server.

PFA

P.S. you have an issue with Geography because keys are not 1 and 2, bur west and east.

Nad as I told it's better to join dimension tables. It's better do not have normalised model

Re: Desktop vs Web view performance

Thu, 16 Oct 2014 04:08:29 GMT

Hi,

Thanks for your effort. Looks like a working straight table is better than a not working pivot table. I still wished I could tell what is going on with the pivot table here.

I also went ahead and took your advise in regards to denormalization.

One question:

In your expressions you have this:

count({$<customer_name,size={$(='"' & Only(size) & '"')}>} distinct customer_name)

but the following expression seems to work as well:

count({$<customer_name,size={$(=size)}>} customer_name)

what does this syntax do exactly: {$(='"' & Only(size) & '"')} vs this one: {$(=size)}>}

Re: Desktop vs Web view performance

SergeyMak — Thu, 16 Oct 2014 05:01:44 GMT

if your size is numeric you can use {$(=size)}, but just to avoid misunderstanding it's better to use Only(size), because size in this case is translating automatically to Only(size)

if the value is string, like your geofield, you can't just put $(=size), you have to use quotes. So in case $(='"' & Only(size) & '"') it's just string concatenation to get {"<size_value>"}

Re: Desktop vs Web view performance

SergeyMak — Thu, 16 Oct 2014 05:07:14 GMT

I have to add that I got rid of your aggregated dimensions as well and totally rewrote your expressions. So you can try to use it like Pivot Table.

With your pivot table it's just overcomplicated. I don't think that it's good way to develop applications. I always strive to make the expressions simple as it possible, because complicated expressions always affect the performance.

Regards,

Sergey