Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I'm wondering how do we benchmark the performance of qvw?
I have 4 millions rows, in 2 flat tables with sequential numbers as keys to link the 2 tables.
one for fact, one for dimensions.
When loading the chart with set analysis, i still see the hour glass. i wanted to remove the hour glass totally.
Does this mean going on a more powerful machine would help?
Could someone share your experience?
Thanks.
In general, my 4M row apps would never show an hourglass.
You must make sure that you have enough RAM on the desktop machine to not use virtual storage. Look at the Working Set size of qv.exe task in Windows Task Manager to see how much memory is required for your doc.
-Rob
Hi Rob,
When optimising the qvw, i'm working directly on the production server, so that i know the actual performance.
I have 64 gb RAM, 10 cores.
Thanks,
I agree. The QVW doesn't sound like it should be slow. How best is best is a tough question. I think comments made so far give a good strategy.
To this I would add using the Memory Statistics (Doc Properties/General tab) to understand what is happening in your virtual database. When you have a fact with 100+ columns you can easily experience problems. In recent QVWs I have seen any single field in the QVW that is larger than 200Mb will impact negatively on performance. If the big field is a key I autonumber() it and if it is data I look at breaking it into 2 fields.
When you analyse and discover that you really do need all 180 columns then you should try identify the most used columns for the initial analysis by a user. Keep those columns in the main table but drop out the rest into a secondary table.
I have only ever done this on QVWs larger than 4Gb - saved uncompressed. Good luck, Adam
As has been said before, 4 million rows is not a lot, but in truth, it's not the number of rows, but the amount of data. The content of the fields matters. Do you have any particularly long fields? How unique is your data? If you have long comment fields, for example, they will not be compressed in RAM. Here are some of the things to look at:
Hope this helps a bit.