cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: web app design
Date Mon, 23 Sep 2002 16:38:39 GMT
> This framework will be for small business or medium business and to
> construct and publish their corporative webs.

Just this constraint alone will get you a long way towards creating some
performance targets and usages numbers:  You can make an assumption about
the max. number of users in a company (possibly adding some users for
extranet type usage if applicable).  From there you can make some
assumptions about max. simultaneous users based on the application type.
Using the first number you can make some estimates on max data based on
application type times number of users.  Using the second number you can
make some assumptions about bandwidth requirements (max. users times data
sizes in play at any moment).  Now you've got some idea of your database
size, # of simultaneous users, amount of data being accessed and generated.
Next you need to make some assumptions about response time.  Again, you know
the application type (eg. generating credit card responses is way different
than generating seismic analysis result sets) and should be able to come up
with some reasonable numbers.  This will allow you to estimate transactions
per sec, page views per sec. etc. 

What you don't know is how Cocoon maps to any performance metrics; you can't
do that without some real load analysis software and hardware.  But at this
point, that isn't really the issue:  what you really want to estimate is
whether a processing heavy architecture can handle the transaction
requirements on some reasonable hardware (as defined what your company is
comfortable supporting).  If it starts to look like you've got a lot of
transactions per second or a lot of page views per second with a lot of data
per page view then maybe a pure Cocoon architecture isn't the best way to
go.  In my experience, apps targeted at small companies aren't generally an
issue.  App's targeted at 1000's of simultaneous users might start to get
questionable (although that's our ball park with a mostly pure Cocoon
architecture, albeit mixed with a good chunk of EJBs).  We're targeting a
single large database processor, a couple of EJB' servers and in the order
of 10 front end web/app servers as the largest possible hardware config we
will need (a couple of years out). However, our app splits nicely into small
user communities that can be easily mapped to individual app servers. (Note
that fail over hardware is a separate issue from the hardware needed for
performance reasons).

How to start?  Create a spread sheet and fill in some guesses for max users,
max. simultaneous users, largest data set sizes, required transaction
response times.  Validate the assumptions with as many people as you can.
Now figure out, disk space usage, bandwidth, transactions per sec. etc. If
these numbers are small, don't worry about the architecture much more.  If
they start to imply lot's of hardware invest some more time in validating
the numbers.  If you're still nervous after that you've got to start
benchmarking....


---------------------------------------------------------------------
Please check that your question  has not already been answered in the
FAQ before posting.     <http://xml.apache.org/cocoon/faq/index.html>

To unsubscribe, e-mail:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message