Peter, very very very very thanks. I needed a guide like these ...
Best Regards, ... and now to work! ;-) ----- Original Message ----- From: "Hunsberger, Peter" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 23, 2002 6:38 PM Subject: RE: web app design > > 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: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- 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: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
