Postscript

While I was writing this article, I realized that no one really knows how fast WebObjects really can go on a set of hardware, and therefore how much you need to budget to support X number of users. Part of this is that there aren't any benchmarks. A few people have given out rules of thumb like "a user spends 10 seconds on average reading a page", but no one knows where these rules come from. Nor do they seem to take into account that if the user is on a 56K modem, it might take them a few seconds to download the page in the first place, which lowers your page per minute count quite a bit. So that has led to another article, "Proposed WO Benchmark".

If there aren't any benchmarks, where did the numbers in your article come from? Well, pretty much, they're educated guesses based on my experience with deploying web applications and from talking to other WO developers on the Internet. In general, I've been overly conservative, in practice you may find that you can get much better performance out of a given web application then the numbers in this article would lead you to believe. One of my reviewers was Geert Clemmensen from FrontLine, he finds that with FrontBase, he can get pretty good TPM numbers out of a G3 macintosh.

Since the point of my article is to start small, and buy more stuff as you need it, whether its a WO license, a high-end Solaris box, or just more RAM for your database server, it doesn't really matter what the numbers are.

Comments on the Article

After I wrote the first draft of this article, I submitted it to various people on the network for peer review. The comments I got back were so interesting that I decided to add them to this article as an appendix.

First off, Geert B. Clemmensen the president of Frontline Software which makes FrontBase, made an interesting point about EOF. EOF generally does its database requests on primary keys! That means that EOF queries tend to be already optimized for quick database access. Not surprisingly, Geert is quite proud of FrontBase and was quick to provide me some real numbers to show just how fast FrontBase can be on Apple's hardware. Based on his numbers, it seems as if you would never have to switch to Oracle on Solaris at all! Geert has written an article about how to scale FrontBase that gives some handy tips on optimizing performance for FrontBase but many of his points apply to all databases. Anyway, you can read his article here.

David Neumann at Apple had some comments on my numbers for implementing the original Dell online store:

The first store was built in WO 1.0. I built the demo core in 4 calendar weeks. Not all that times was spent on Dell. I still had SE duties. But April, May, and 1/2 of June went by before they deployed it. I spent a week and a half each month after April just tweaking when it became obvious they were going to actually deploy the demo app. I was the only developer. there was an HTML guy and DBA guy and a manager guy. So it's hard to quantify but 6 weeks seems accurate. You can see that no more than 2.5 calendar months went by between start and deployment. Starting on Halloween night we rewrote the app in WO 3.0/EOF 2.0. That deployed on December 7th (a month and a week later). This time a developer, Kevin Koym also worked on it. I did the Configurator, Shopping Cart, speed tuning, and reporting pages; Kevin did the check out pages. But there were 2 people that time working for those 38 days. Kevin stayed on and added further stuff such as multiple store fronts for different customers and performance enhancements in the leak dept. About $750million went through that store from June96 to November97 when they finally pulled the plug.

WO Licensing tricks #1

Apple has a hole in their licensing scheme between the 100 and unlimited levels. You can usually work around this by talking with your Apple representative, but for the purpose of this article I relied on a trick. The trick is this: When users initially connect to your web site at "www.mysite.com", you redirect them to one of the other WO application servers, generally running at "www1.mysite.com" and "www2.mysite.com". This will distribute your load so that you can run WO in 50 tpm increments just by buying more MOSXS servers.

Now if you have the unlimited WO license (either the 25 or 50K variant) WO will do this load balancing for you automatically, but this allows you to "bridge" that hole in their licensing scheme. (Which isn't really a hole, because your Apple rep could probably sell you a 314 TPM license if you whined enough. )

WO Licensing tricks #2

This may not be clear in the article, but when running WO on the backup machine, you don't have to buy a license for that second machine, until you're actually using it as a server. That is, that machine is a backup machine so it uses its 50 tpm license. If your other machine goes down, you switch the licenses. That is, your backup machine becomes your primary machine (with the big license), and your primary machine becomes the backup machine (once it gets fixed). That way, you don't have to buy two licenses. Later on, if you use that machine as a server, and then you have to buy it a better WO license of course