> 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]>
