"Steve Brackenbury" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> At 05:27 PM 6/9/2003 +0100, you wrote:
> >Hi,
> >
> >On Sunday 9th June, we put live Phase One of our migration of Standard
Life
> >Investment's sites...
>
> The site looks great and the response appeared to be snappy.
>
> >The box is an IBM RS6000 running AIX, and the software stack is
> >Apache/Tomcat/Cocoon 2.0.4.
> ...
>
> >Phase Two, which is scheduled to start almost immediately, involves
moving
> >more apps across to the server, and load-balancing another box in the
setup,
> >in addition to bringing back within scope, some items which were dropped
to
> >meet Phase One's go-live date.
>
> I'd be interested in learning more about your impressions of Cocoon's
> performance with apps involving dynamic content.
> Most of your site examples appear to be static content, so you can take
> advantage of Cocoon's caching mechanisms to boost performance.
None of the site is "static" content :) It just looks that way, due to the
magic of Cocoon ;)
<map:resource name="display-page">
<map:aggregate element="aggregated-page">
<map:part src="{path}/{file}.xml"/>
<map:part src="{section}/section-config.xml"/>
<map:part src="site-config.xml"/>
</map:aggregate>
<map:transform
src="file:///usr/local/apache/jakarta-tomcat-4.1.18/webapps/content/content/
ireland.standardlifeinvestments.com/xsl/chunkfile2xinclude.xsl">
<map:parameter name="vpath"
value="/usr/local/apache/jakarta-tomcat-4.1.18/webapps/content/content/irela
nd.standardlifeinvestments.com/"/>
</map:transform>
<map:transform type="cinclude"/>
<map:transform src="{xslt}">
<map:parameter name="vpath" value="{path}/{file}.xml"/>
<map:parameter name="page-id" value="{file}"/>
<map:parameter name="section-id" value="{section}"/>
<map:parameter name="vpath" value="{path}/{file}.xml"/>
<map:parameter name="ln" value="en"/>
<map:parameter name="use-request-parameters" value="true"/>
</map:transform>
<map:serialize type="html"/>
</map:resource>
> Have you migrated/tested apps that involve retrieving data from databases
> and rendering dynamic pages? Things like user portfolios/account details
> etc? I'm curious to see how Cocoon performs when serving up large volumes
> of dynamic content and how well it scales as request volume grows? Can
you
> (or anyone else) share your experience with this?
The above resource is used for most matches.
But, we also pull in dynamically generated content from a servlet
<map:part
src="http://uk.standardlifeinvestments.com/FundAccessor/FundAccessor?series=
{file}"/>
We've tested the load up to 200 concurrency on the Fund prices pages alone,
these are the slowest pages (due to the Servlet request)
Significantly, the FundAccessor servlet does return "LastModified" properly
(as per the Servlet spec), although I'm not entirely sure how much this is
helping.
> I'd like to consider Cocoon for the presentation tier of a large business
> application powered by J2EE on the back end. Almost all of the pages
> served would include some dynamic content, so I'm not sure how much if any
> of Cocoon's caching I could use to boost performance.
You might want to consider ESI (Edge Side Includes) and see if they fit
within your design.
> I'm wondering if Cocoon is appropriate for such applications or whether a
> more traditional JSP based web app would perform and scale better.
Perhaps
> Cocoon shines best when serving static content and is not appropriate for
> high volume dynamic content?
Cocoon doesn't shine when serving static content, thus the quite clear URI
distinction on the SLI sites between /content/* and everything else :)
Apache serves everything that's not dynamically generated, which for some
pages means that Cocoon is only serving 1 in 20 requests.
> What options are available for optimizing Cocoon performance when serving
> up dynamic content? What are the Cocoon "best practices" when dealing
with
> dynamic content.
Good question...our XSLT transformations are not terribly complex (I don't
imagine), enough to publish pages at least :)
The Site and Section configurations add complexity tho', as there is
multi-layering of Legal disclaimers etc. The Fund prices pages are pretty
complex, this was our first XML/XSLT solution, so a lot of the XSLT could
probably be improved for performance, the beauty of the solution is that we
only need to deploy new XSLTs and the entire site benefits.
> Please share your views and experience on this. I'd really like to get a
> sense of the Cocoon community's thoughts on this. I posted a similar
> question a couple of days ago and so far I haven't received any feedback
on
> this topic. Is no one using Cocoon with J2EE?
We are about to migrate applications to J2EE, but we have a quite clear
architecture in mind for this, there is already quite a lot of material on
getting the best out of J2EE, specifically the Facade pattern, and
client-side caching. We will almost certainly re-use the
Servlet/Aggregation pattern again, allowing the Servlet to cache values
where appropriate.
I appreciate that for heavily dynamic pages this isn't always going to help
much, but, then I'm not sure how much you're losing by using Cocoon anyway.
> Thanks in advance for your time. I'd be happy to take this off-line if
> this is not the appropriate forum for such discussions.
Maybe it's not appropriate, if not, can someone let me know :)
Thanks
Kevin
---
Kevin McDermott Senior Technologist
0131 476 6000 Cert. TeamSite Consult
www.realise.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
