Re: Performance Experience

On Jul 15, 2004, at 11:37 AM, David Holt wrote:

> Hello,
>
> Well, it is coming close to the time to deploy our first WebObjects 
> app. We have a G4 450 with MacOSX 10.2 server and 1GB of RAM. Stock 60 
> GB HD. We'd be using WebObjects 5.2 as the app server, unless there is 
> a better way. Our internet connection is a static IP ADSL account that 
> advertises "up to 1.0 mbps" upload speed.

   You should investigate co-location. Its usually a much better deal.

> Can anyone give me any idea what sort of performance we can expect 
> from this set up?

   Marketocracy (www.marketocracy.com) had something similar to this at 
one point, though we always had several G4/450s.

   What we found was that while it was adequate, the G4 450s aren't 
really designed to run 24/7 for years on end, and start to fail. So 
gradually we've been replacing them with XServes.

> How many simultaneous users would we be able to support?

No way to answer that question. 1-1,000,000 depending on your 
application.

In our case, we tend to be database limited instead of CPU limited on 
the app servers, so their CPU has lots of idle time. The database CPU 
is more heavily loaded, but database machines tend to be I/O bound so 
our XServe G5 really cranks with FrontBase mainly because we could put 
8GB into it.

  If you're not database limited (perhaps your entire website is 
preloaded into application memory), then every WebObjects page boils 
down to a giant printf.

  Lets say it takes .2 seconds for you to generate a page. Let's say 
your website consists of 10 pages. So it will take 2 seconds of CPU 
time for a user to browse your entire website. So that's 1800 
user/website/hour. That's not 1800 simultaneous users though. If it 
takes a user 30 seconds to read a page then your app would look like 
this:

    generate page: .2 seconds
    Wait 30 seconds:
    generate page: .2 seconds
    Wait 30 seconds:

So the users could interleave... In fact, with .2 seconds "busy" out of 
every 30 seconds, that's 150-1 ratio. so 1800*150=270,000 simultaneous 
users over an hour.

And that's for a single app instance. In practice, requests can 
interleave a bit, because some of WO is pulling the data over the 
network and shoving it back out again. So multiple instances can be 
much faster, and multi-threaded WO Apps do even better.


>  What sort of user experience would they be getting?

   Again, depends on your application.

> Does anyone have any experience serving on similar "legacy" boxes?

   Yes.

  So that answered the question you asked, which is probably not the 
question
you should have asked.

  Here's my answer for "how much does WebObjects cost to deploy" from 
back in the
WO 4.5 days when a WO license was $50K.

http://www.twinforces.com/tf/docs/WOCosts1.html

  You should read this because you're missing a bunch of issues. For 
instance, if WO takes .2 seconds to generate a 100KB page, but you only 
have a 1 Mbs link, it will take you 1 second to send said page, so you 
can only send 3600 pages
per hour, so your app server will never rise above some small amount of 
CPU
being used, because it can generate 18000 pages/hour and its only being 
asked to do 3600.

That's an advantage of colocation. With your ADSL connection, you have 
a hard limit of 1Mb/s. With colocation you don't usually have a hard 
limit. They send the bits as fast as possible, and bill you for the 
amount sent on average instead. So that increases your maximum number 
of simultaneous users during peak times.

  In practice, you have some mixture of dialup, cable modem, DSL, etc. 
users, and all that affects how many users you can handle, because 
simultaneous users is not the same thing as simultaneous requests.

  What we run into at Marketocracy is something I think of as 
"collisions". We have about 24 application instances. The problem we 
have is that some users have accounts much larger then others. (100x 
larger).  While I've spent a lot of time architecting things so that 
login is fast, yet complete enough to do useful work, occasionally, 
those users touch one of those pages which require a long
database fetch. Meanwhile, all the other users who also are trying to do
a database fetch on that instance are locked out. I think of that as a 
collision
and the solution is more application instances since I can't use 
multiple database connections in 4.5, or what I'm working on now is 
sort of a wait
cursor so that users will always get _something_ after 30 seconds, 
instead of
just bouncing to another instance.

  Pierce