How tp find the size of RAM.

[#1]

Hi All,

I have a doubt in finding the RAM size and other things. I don't know exactly how much RAM we need in order to run the qlik document properly so that System should not hang up.

I have 7 years of data in my production server. I want to know how to find the size of the RAM for 7 years data.

What are the factors consider before predicting the size of RAM?.

Give me your valuable suggestions..

Thanks,

Raghu.

[rwunderlich]

The "Qlikview Optimizer" application, available in the Share Qlikviews section can be used to estimate the RAM requirements for a QV document.

Some tips on tuning the RAM requirements of your QV document can be found here:

http://qlikviewnotes.blogspot.com/2008/05/when-less-data-means-more-ram.html
http://qlikviewnotes.blogspot.com/2008/05/memory-sizes-for-data-types.html

I have found that while QVS can use virtual memory, the performance will usually be poor if QVS is paging. Meaning, provide enough RAM to hold your document so the QVS task will not spill into the paging file.

-Rob

[Oleg_Troyansky]

Here are a few "rules of thumb". Some of them might be a bit old, so use with caution...

• If you already loaded your data into a QVW, check the size of the QVW. *TYPICALLY* it takes 3-4 times the size of the document, in order to open the document in RAM for a single user. For example, if your QVW file size is 100 MB, it will take approx. 300-400 MB in RAM.
• Each additional user *TYPICALLY* adds 10-15% overhead to the number above. Therefore, 10 concurrent users will at least double the required amount of RAM.
• If INPUTFIELDs are used in the app, the amount of extra RAM per user seems to be much higher than 10-15% - I'm guessing because the INPUTFIELD values are being stored for each active user (whether they are used or not).

cheers,

Oleg

[#4]

Thanks to everyone for your valuable points.

I have one questions to Oleg, as you said "each additional user adds 10-15 % to the number. So 10 concurrent users will at least double the required amount of RAM". As i understood from the above statement that Qlik document kept at the server, each person open up the document from the server consumes 10 - 15 %. Whether my understanding is right?

I have another question using Ajax based web pages consume the same memory of RAM?

Thanks,

Raghu.

[Oleg_Troyansky]

Raghu,

yes, that's the benchmark... It's not a "precise sciense" - it depends a lot on your applications, number of selection fields and layout states that need to be saved etc... I don't think that client version (AJAX vs. Java etc...) matters much. What matters is the amount of things that need to be saved per user. The more complex and versatile your application is, the more stuff will have to be saved for each user.

Oleg

[#6]

Good morning Oleg,

Based on your experience, whatis the impactof the inputfields in the memory usage of a qvw on a server ?

Thanks

Philippe

[Oleg_Troyansky]

The impact of INPUTFIELD can be HUGE!!! Keep in mind, that QlikVIew server will allocate and keep blocks of memory for all the possible INPUTFIELD values for each user that access the document, whether or not the user entered anything in the INPUTFIELD.

Example 1: Input field is a part of the table with 100 rows.

No problem, QlikView Server will store 100 values per user - no big deal.

Example 2: Input Field is a part of the transactional table with 10 mil. rows.

Huge problem - QlikView will have to store 10 mil. values for each user accessing the document.

My recommendation is to limit access to QVW documents with INPUTFILEDS to those users that truly need the specific functionality. For example, you might have a 100 users interested in Sales Analysis application, but only 5 people will need to use Sales Forecasting feature (implemented with INPUTFILEDs). As much as we'd like to serve both needs with a single document, I'd recommend separating Sales Analysis and Sales Forecasting into 2 separate documents and limiting access to the Forecasting doc.

This is not proved by any scientific analysis, just a result of several observations...

regards,