Is your SQL select statement using "select * from" or are you just selecting the required rows?
Using "select *" can be slower if you are loading a lot of columns that are then not loaded into QlikView.
Try just selecting the rows you need in SQL.
Also depending on the drivers, OLEDB (ADO) connections can be faster than ODBC.
I would also monitor the memory usage and CPU usage both when the server is running normally servicing user requests and when a reload is running. With Publisher on box3, then this server should be handling the reload overhead.
How many cpu cores are on each server and what speed?
How much ram on each server?
How many network cards on each server and what is the speed of the network connection to each server and to the SQL database where you are extracting the data?
Thanks for the response.
I am using "select *" in the query.But, the same query is running fine on other boxes 1 & 2.
I am only facing performance issue in box 3.
RAM on box 3 is 16 GB,
RAM on box 1 and box 2 is 64 GB.
Box 1,2, and 3 are in production environment.
In dev environment, Devbox 1 has just 8 GB RAM but the performance on the same database is fine.
1) Do you think that 16 GB RAM is making the performance slow? But, it works fine on 8 GB RAM in dev.
2) Is there any restriction that Qlikview Desktop/Developer cannot be installed in the same box as Qlikview Publisher? Will it affect performance in any way?
I have a similiar problem here with me.
All developers have a QlikView designer installed in their own machines.
We made one script with database access to everyone test in each environment. All machines have similiar configurations. (Windows 10, 8GB RAM, Same network conection)
In 2 of 3, the Qlikview script have a expect performance, running in a few seconds, but in the 3rd we noticed slowness.
Even if this post is old, the problem still happening.
Someone with ideas?
What is your OS?
I have a similar issue, and was looking here in QlikView community the answer, but was unsucessful.
Hoply, I found this article in Microsoft Forum who solved my problem. Maybe this could be yours to. The ODBC tracing option.
I believe because i use Windows 10, and it has HD usage overloaded problems.
When I disabled the "when to trace" option, the disk usage don't go to 99%, and instantly the database load increased.
I hope this could be useful to someone.
Have you tried the data load using an OLEDB connection rather that ODBC?
Is there any performance difference?
I prefer to use OLEDB rather than ODBC, as the connection string is embedded in the application and avoids the need to setup identical ODBC DSNs on each developer's machine and server. That said with some systems ODBC is the only option.