I am in the process of load testing WebI to validate the Business Objects server sizing strategy where 12 BusObjs or 30 WIQTs can run on an NT server. We have scaled up to 20 thin client refreshes (WIQTs) with no problem from a CPU or memory standpoint. However, we are seeing an increase in response time of 13 seconds for every 5 users added. So for a refresh that took 11 seconds with one user now takes 64 seconds with 20 users on average. Any tips?
We have scaled up to 20 thin client refreshes (WIQTs) with no problem from a
CPU or memory standpoint. However, we are seeing an increase in response time of 13 seconds for every 5 users added. <<
I cant help but think that is pretty good… what we found is that at some point you are sharing processor resources, and that you have to wait for a slice of the processor… 13 additional seconds doesn’t surprise me…
But, how many boxes, how many processors?
Good luck,
Brent
OM
Jodie wrote…
We have scaled up to 20 thin client refreshes (WIQTs) with no
problem from a
CPU or memory standpoint. However, we are seeing an increase in response
time of 13 seconds for every 5 users added. <<
Even if the CPU is not pinned? There is more CPU available so why do 25 users take an average of 80 seconds to refresh a report “of average complexity retrieving 300 rows” (quoted from the BO server sizing presentation).
I am running a master install, so I am a little stuck, but yes… I think you can control how each process hangs on to the processor, eg, number of seconds as a configuration option…
Anyone else have any inputs? The name of this param? I know I am not totally making this up… I hope : /
We have found and logged a case concerning the WIQT processes not utilizing the 2nd cpu fully. The best feedback I have received is that it will be fixed in SP3 for Webi 2.5. I am running dual 450-Xeon and the 0 cpu gets pegged while the other never goes higher than 7%.
Took much testing but we were able to help BO isolate the problem to get it fixed.
This is why you are feeling the additional seconds as you add more WIQT sessions.
Change is referenced as bug 36744…
Sincerely,
Tom Nather
Data Warehouse Group
Penske Logistics email:tom.nather@penske.com
Phone: 216-765-5787
Fax: 216-765-5666
Wow, that is VERY interesting - we knew that 2.0x was not great about using the CPUs (plural), but we were under the impression that 2.51 was better…
Thanks, I think.
Brent
We have found and logged a case concerning the WIQT processes not utilizing
the 2nd cpu fully. The best feedback I have received is that it will be
fixed in SP3 for Webi 2.5. I am running dual 450-Xeon and the 0 cpu gets
pegged while the other never goes higher than 7%.
Took much testing but we were able to help BO isolate the problem to get it
fixed.
This is why you are feeling the additional seconds as you add more WIQT
sessions.
This is really interesting and very closely describes the circumstances that we have noticed in our configuration. We have been talking to BO about performance and sizing in general but have heard nothing about a known bug and plans to fix in SP3, etc.
Can you post some details of the Bug and the proposed fix. I have looked at the BO tech support web site but have not been able to find any details (probably an operator problem!!).
Anything giving more detail would be useful.
Regards
Graham Boden
EDS
Tom wrote:
We have found and logged a case concerning the WIQT processes not
utilizing
the 2nd cpu fully. The best feedback I have received is that it will be fixed in SP3 for Webi 2.5. I am running dual 450-Xeon and the 0 cpu gets pegged while the other never goes higher than 7%.
Took much testing but we were able to help BO isolate the problem to get
it
fixed.
This is why you are feeling the additional seconds as you add more WIQT sessions.
Here is what has been fixed your guess on dates is as good as mine:
With this new behaviour, the WIQTs processes are no longer set to run on aspecific processor only but they are now managed by the system (Windows NT) in order to run either on the first or second processor (in the case of a biprocessors machine).
It should be implemented in the following Webi versions : - next minor release ( it should be called WebIntellingence 2.6) - next Webi 2.5 Service Pack (Webi 2.5 SP3) - next Webi 2.0 Service Pack (Webi 2.0 SP8)
This is all I know for now. They have been very good about working on this and it took awhile to pin down which process was giving the problem. I would rather wait and let them test it to make sure they have found the problem. If BO is seeing this make sure all your help desk techs refer to this case and its history.
Sincerely,
Tom Nather
Data Warehouse Group
Penske Logistics email:tom.nather@penske.com
Phone: 216-765-5787
Fax: 216-765-5666
2.5.1 is better and with this fix it can be that much better.
2.0 -> 2.5.1 we saw an decrease in reponse times of 30% and this is without the fix!! Keep in mind the 2.0x - 2.5.1 is worth the effort to convert just for what I mententioned above.
They were able to show all the bench marks at the users conference and they are right…
This problem is minor and I just stumbled on it while creating some statistics for management.
Sincerely,
Tom Nather
Data Warehouse Group
Penske Logistics email:tom.nather@penske.com
Phone: 216-765-5787
Fax: 216-765-5666