for those of you out there dealing with bigger deployments, how many servers would you recommend at a minimum (processors) for this type of community? 90% of our users will be using 5i reports only (we are not using very many webi reports at all)… considerable more resource intensive i know.
we have some hardware (and cost) constraints and right now i’m looking at 2 servers (a quad 900mhz and a dual 1.3 ghz both with 2 gb’s RAM)… will that suffice?
OK Webi sizing and all the “Alchemy” that goes with it.
Forget everything you read so far about sizing there is only one relevant number to do proper sizing.
Take the peak usage of your user: End of month, Quarter, … what ever it is.
How many people will need access at this time at the same time to the server ??
This is the number you are looking for and you want to service after that everything else should be fine and you will probably have some spare resources.
How do you figure out how many you really have ??
Well lets assume you 1500 employees and they have to submit a report at the end of the month (the 1st of the month 1st thing in the morning)
Well you will have 1500 people logging into webi and refreshing the report at 8am.
Once you spread this you will get to 200,300 users or more
For Webi take the following
Every CPU can handle 25-100 WIQT’s
Every CPU can handle 5-40 Busobj
Now divide your number by the number us processes by CPU.
As for RAM 512MB per CPU (More is a waste of money it is not well used by Webi and NT)
Disk if they only refresh count 50MB for every active user
If the store documents count 100MB for every user defined.
If you have to choose between clock-speed and L2 Cache go for the cache
Other big issue: Can your back-end database cope with this load ? (we killed Oracle with 180 concurrent Webi users on a 1CPU Webi server)
40 BusObj processes per CPU? That seems like a lot to me. In the “old days” of slower processors and whatnot, they suggested 3-5 Busobj processes per CPU. Are these the new numbers that BusObj quotes?
I just don’t see any way that I’m going to load 160 full client refreshes on a four processor box. At least not under NT… are these Unix numbers?
I would be really interested to hear more validation on where these numbers are coming from. Klaus, can you provide more details? Thanks.
There is NO WAY you’d ever get 40 Busobj.exe on a processor.
I think 5-10 is realistic.
However, 2.7.1 has done ALOT as far as memory management is concerned. From what I can tell, you can get alot more processes on a server now. 40 per processor is still too high.
These numbers are from a Benchmark effort back in 1999 while working at Business Objects. I organized an unofficial benchmark week.
I invited to Switzerland the Webi experts from : The states, France and Germany.
BO will never accept any of these numbers since they are not from the product group.
As for the users I would agree the standard number we use for Full Client is 5-15 (it all depends on the reports you have)
For one client we did a test of a very large document and it took Webi on an 8 cpu machine over 1hour (this was the only user).
As for Unix we have not seen that it is that much more scalable than on NT. You get slightly more users but nothing dramatic.
If you compare the Benchmark for SUN or IBM and Compaq NT You see that the numbers are rather close and the difference does not justify the price tag of UNIX.
Klaus,
I am really impressed with your depth of knowledge here, so please allow me to ask a question or 2.
Doesn’t the BOManager process only use 1 processor at a time? You stated that a large document on a server with 8 processor took an hour. Wouldn’t it have take about the same time with 4 or 2 or 1 processor?
The “Official” sizing stuff claims that SOLARIS can handle 20-30 Busobj processses per CPU and that Windows 2K can handle 5-10. Why do you think the numbers are so far off?
The reason I ask these is not to find fault with your opinions. I’m just confused. We have been doing some stress testing at client sites and have found the SOLARIS version of 2.7 to be quite a bit more scalable that the same software on Windows 2K. Perhaps some of the differences will be alleviated by the changes relating to the memory management of the BUSOBJ process on Windows.
Answer 1 : We never had more than 1 BOManager for any of the Webi Server or Clusters I setup. As far as I remember BOManager process runs on all available processors.
The same goes for busobj.exe if you have a dual processor it will open your reports faster than on a single CPU Machine. I have a few Power users for BO who have Dual Xeon Workstations just of BO reports and 1GB of Ram (they have many calculations, …)
2 Why are the UNIX Numbers larger ?? I don’t know and can only guess.
Unix is supposed to be made for large deployments so the number has to be larger. (Also by default Unix has a better multi-threading than NT)
The other case is how do you justify the price difference between Unix NT if the numbers are too close the are difficult to justify.
I agree with you the Unix version keeps on getting better. But in my personal opinion BO is still a PC software company. They are getting better but it will take some time.
I just read through the BO Published Benchmarks (could not find the one for NT)
Some interesting comment about the benchmark
For SUN :
Use 16 CPU max for Webi (on the E10K they had 4 webi servers)
64 x CPU 400 mhz 1GB Ram CPU (But the table shows only 2x16 what happened to the others???
Users by CPU 31. There are no details about the type of reports they refreshed (FC or TC ??)
For IBM:
24CPU 96GB Ram
41 FC by CPU (I agree this is pretty good)
Comment about Impact of very fast Disks on system (we where all guessing that this was important)
General comment. The benchmarks are interesting but of limited use since the have may different activities (we are all looking for the worst case)
For their test 80% view Corporate Documents and 20% refresh them.
This means your repository and network is as important as the Webiserver.
It gives some estimates. If you compare this to the numbers I quote they are 100% of Users refreshing at the same time FC or TC documents. I guess the numbers are not that far of you just have to read the fine print and try to understand what they try to demonstrate with the test.
“NEVER TRUST A STATISTIC UNLESS YOU FAKED IT”
More interesting why do you think there are no extensive NT Benchmarks ?? NT is in market share the most commonly used OS for server (I did not say it was the best)
Our very unofficial results have been pretty consistent. 5-7 BUSOBJ per CPU and things are OK on Windows. More than that and stability can be compromised. However in 2.7.1 we can about 10 per CPU.
On Solaris, we don’t have much trouble with 20 BUSOBJ per CPU.
So for 4 processors we can get 28 full-client refreshes on Windows 2K and up to 80 on UNIX (Solaris).
I know there are other things to consider, but full-client refreshes seems to be the biggest issue.
Why do you think the Call it Webi. It was supposed to be webi reports only. And that is the way it started in Webi 1.0. They added FC as an after thought and it is still a pain.
I agree with you the numbers you state are what we use for the definition of Servers. But as you say it all depends on the other components of the hardware.
A server is not only Mhz and Ram for the same specifications the price can be from 1 to 5 (and if you spend 5 you will see that webi on NT is actualy not as bad).
We have Webi running on 100,000$ NT Server and they are fast and powerfull.
This is a fascinating thread This has got me thinking about processers, busobj.exes and wiqts. Going back a few years I think - think - a Pentium 2 400Mhz was supposed to be able to cope with 4 busobj.exes absolute max. I’ve read that the P3 Xeon 700Mhz was rated as 5 as a baseline but you could experiement with more. Now we are in the realms of P4 2Ghz are we saying that the very latest Intel-type processor will only rate say 6 or 7 as a baseline but can be experimented with - up to 10 or even 15?
The Global Deployment Guide states:
The following parameters, based on a Compaq Proliant 8500R server with 8 CPU
PIII 550 MHz and 4Gb RAM, were used to develop capacity planning design
criteria:
• Assumed Max number of BusObj per processor: 8
• Assumed Max number of WIQT per processor: 25
The L2 cache stuff is interesting - I must read up on this. Thanks folks 8)
I made some comments along these lines in another topic somewhere. Maybe an ambitious moderator will look for it a post a link. Link Here - Nick 9/13/2002
Anyway, the reason (I believe) that Unix gets better benchmark scores than NT is that they have a true “background” process for processing REP documents. In the NT environment, we have a major liability in that the “background” busobj.exe is essentially the same as the foreground process that users use. In other words, this background process has all of the overhead of error checking, an interface, and all the baggage that a regular windows app has. Under Unix, the “bolight” service was written from the beginning as a background process. One would hope that it was written to be efficient at its designed task, and that none of the extra “baggage” like an interface was included.
That is my primary explanation as to why Unix numbers are always quoted higher than NT. I am really REALLY hoping for a true background process for the next major release under NT. There’s no reason (other than it was convenient) to continue to use busobj.exe to process REP files under NT. My two cents.
I agree with Nick; this has been a fascinating discussion. And - if you don’t mind the Bob plug - much easier to keep track of when contained in a single topic than scattered across multiple emails.
I need to fuel the fire a bit more. Perhaps Klaus can help us more.
I’ve been led to believe that the processors don’t really matter much anyway. The number of them matters, but the power of them doesn’t.
We’ve seen that systems that appear to be maxed out have plenty of processing horsepower left. The problem appears to be in the way Windows has to deal with the sessions. That’s why the change in the way the interactive and non-interactive heaps are set is so valuable. Less heap per session mean more sessions.
Now you might actually be able to max out a machine.
The problem has nothing to do With CPU but webi and how it was written.
Dave is right Full-Client webi on NT was not supposed to be there and was added in version 2. And they reused all the existing client busobj.exe
Heap size, Bo manager tuning … will help but the problem is still the same they turned a client exe in a server process and they did not build all the things required for a real server process. Things like multi-threading, …
At the time I showed Webi to one of the expert of our client and in 20 minutes he came up with 2 pages on how to improve webi. Need less to say that this was ignored.
What really makes a difference however on Windows is all the things around and inside the CPU. Because some as better at working with the limitations of NT and Webi. This is why XEON is still the processor of choice.
Have not tried Itanium (No customer was willing to buy me one)
so this all having been said - how do we generally feel about a BO implementation in terms of NT vs. UNIX (solaris)? i know they had some stability problems in the UNIX version back in the past that are supposedly resolved… but it’s sounding like UNIX would be the platform of choice given the option???
The UNIX version does work. Lots of BIG customers in the states are using it. HP-UX is the most difficult to get working, but once you get there you’re OK.
Solaris is the easiest and can handle the most users.
AIX is gaining ground. There are some pretty big AIX implementations going on.
Although it is more expensive, you can get more users on it. The current licensing agreement allows for 1000 named users on UNIX and 500 on Windows. So, you get twice the capacity for about 1.5 times the price. Yes the hardware is more expensive, but it is also more reliable.
That said. I, once again, agree with Klaus. I still would go with Windows to start and only move towards UNIX if you really plan to support a ton of users. It’s simply easier to work with on Windows and MUCH easier to get help.