Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 93309 invoked from network); 15 Feb 2000 14:23:44 -0000 Received: from london-bridge.east.veritas.com (HELO lmoxch11.nsmg.veritas.com) (207.30.27.2) by locus.apache.org with SMTP; 15 Feb 2000 14:23:44 -0000 Received: by lmoxch11.nsmg.veritas.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Feb 2000 09:24:19 -0500 Message-ID: From: Andy Lewis To: "'cocoon-dev@xml.apache.org'" Subject: RE: Variations on a theme by Cocoon Date: Tue, 15 Feb 2000 09:24:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" I have Cocoon 1.5 running on an internal server - NT 4, Netscape 3.63, JRun 2.3.3, Sun JDK 1.2.2, COMPAQ Proliant 1600 Dual Pentium II 300, 512M RAM, and about 37G of RAID 5 disk on a caching SMART Array controller. The web site is about 2000 pages. With only a dozen people browsing it regularly, we get out of memory errors, and dismal performance. We also have a somewhat complex XSLT transformation going on - about 500 lines of templates totaling about 30k with lots of conditionals.... That's as close to a large production site as I get with it. We actually produce static HTML files to dump onto the production web servers. I have another smaller site on a Celeron 333 running Linux, IBM JDK 1.1.8, with a Sybase backend however. It is a much smaller site, with a much simpler stylesheet, but far more dynamic, and it runs great. Andy Lewis VERITAS Software, Heathrow, Florida Voice: 407-531-7584 - Fax: 407-531-7686 - Cell: 407-718-4718 Pager: 4077184718@mobile.att.net - EMail: andy.lewis@veritas.com " Some days, it is best to keep reality at arms length..." -----Original Message----- From: Mike Engelhart [mailto:mengelhart@earthtrip.com] Sent: Tuesday, February 15, 2000 9:15 AM To: cocoon-dev@xml.apache.org Subject: Re: Variations on a theme by Cocoon 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 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.