cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: Variations on a theme by Cocoon
Date Tue, 15 Feb 2000 17:47:41 GMT
On Tue, 15 Feb 2000, Mike Engelhart wrote:

> Donald Ball wrote:
> 
> > +1. Personally, I think cocoon should focus more on functionality and code
> > maintainability than performance. More often than not, the primary cost
> > contraint for a project is personnel cost - programming and administration
> > - not hardware. This isn't always the case, but I tend to think it is for
> > the sorts of sites for which XML and XSLT are a good match.
>
> I'm not 100% sure that your cost analysis is true (but i'm not an analyst
> either ;-)).  First of all, in reality, *all* sites (other than simple home
> pages) are a good match for XML/XSLT.  Second, if you need to have 25
> machines to do the work that one or two SMP machines *could* do if their web
> software was tuned correctly then your theory fails.  I have no idea what

Not necessarily. Assuming we're talking $2000 machines (low-end intel
servers) then the cost difference is $50000. If programmer time is billed
at $200 an hour, then if the optimization takes more than 250 programmer
hours to accomplish, it's probably not worth it. Of course, this ignores
machine maintenance and setup costs, so taking those into account we'd
probably scoot the cutoff point to 500 programmer hours. Your example is
pretty extreme, though - that's more than an order of magnitude worth of
difference in efficiency in the code. That's probably worth putting effort
into implementing.

> Cocoon's performance is (and it's pretty clear that nobody else does either
> because no one has come out and said they have implemented Cocoon on a large
> production site) so it's hard to say.  As a side note, it really would be
> nice to have more than just a JMeter hit on a Cocoon application to
> determine it's performance level and whether tuning this is an urgent need
> or not.  JMeter pretty much sucks for determining anything when you're
> dealing with complex dynamic sites.

ab (apache bench) works pretty well. comes with apache and has very little
overhead. it would be nice to combine it with a simple webcrawler or
logcrawler to fake real user traffic patterns.

- donald


Mime
View raw message