cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From craig <cr...@sapphireone.com>
Subject Re: is cocoon the right tool?
Date Thu, 24 Apr 2003 05:18:50 GMT
You are right, but I believe the best solution is to reduce the 
doc.size by splitting it up.
On Thursday, Apr 24, 2003, at 11:30 Australia/Sydney, Charles Yates 
wrote:

>    Are you using XSLT to transform these large documents?   XSLT is 
> generally not a good choice for very large documents.  Although Cocoon 
> does use an event model, the XSLT transformations currently require 
> the entire document be in memory  Using XSLTC seems to speed things 
> up.  XSLT preformance can be affected by stylesheet design, so if a 
> transformation is slow it might well be a stylesheet issue rather than 
> the environment it is being used in.  Also in Cocoon, you can plug in 
> a custom Transformer where you deal with the SAX events directly, 
> probably a good idea for large documents.
>
> Charles
>
> craig wrote:
>
>> I tend to agree with Alex - my 152K DocBook xml file, (admittedly 
>> with 200+ images) takes over 2 min. to
>> convert to HTML - I'm running OS X on a PowerBook G4 (512M ram, 667 
>> Ghz) - but then I've got a high tolerance for pain
>>
>> Craig Nock
>>
>>
>> On Thursday, Apr 24, 2003, at 12:59 Australia/Sydney, Alex Romayev 
>> wrote:
>>
>>> It would be interesting to see if anyone has
>>> performace tested or actually done an implementation
>>> which pushes Cocoon's performance.  I've actually had
>>> issues reading a 200K XML file on my laptop with 196M
>>> of memory (not exactly a production level hardware,
>>> but still).
>>>
>>> -Alex
>>>
>>> --- Ryan Hoegg <rhoegg@isisnetworks.net> wrote:
>>>
>>>> Theoretically, Cocoon is built for this type of
>>>> scenario.  It is built
>>>> on SAX, which processes XML serially using an event
>>>> model, so that the
>>>> entire document need not reside in memory all at
>>>> once.  We also have the
>>>> Paginator, which seems to be a perfect fit here.
>>>> Finally, if your
>>>> application will have concurrency requirements or
>>>> even have the same
>>>> dataset accessed more than once, Cocoon's caching
>>>> will also come into play.
>>>>
>>>> Having said all that, I have not yet seen an
>>>> application that puts my
>>>> comments to the test.  If you take the time to build
>>>> your application
>>>> using Cocoon, we would love to hear back about your
>>>> success and/or
>>>> failure.  If you discover a performance problem,
>>>> post details to the
>>>> cocoon-dev list.
>>>>
>>>> -- 
>>>> Ryan Hoegg
>>>> ISIS Networks
>>>> http://www.isisnetworks.net
>>>>
>>>> Adam Shelley wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I've been looking around the net for something that
>>>>
>>>> will help me solve the
>>>>
>>>>> problem of displaying xml datasets (varying in
>>>>
>>>> size: the larger it can
>>>>
>>>>> handle the better. Is upto 5-10MB reasonable?) on a
>>>>
>>>> custom web page.
>>>>
>>>>>
>>>>> I must be able to page through these documents via
>>>>
>>>> html and also output them
>>>>
>>>>> to PDF.  The problem is the size.  I could easily
>>>>
>>>> do this with xml/xslt
>>>>
>>>>> using dom but there is probably going to be some
>>>>
>>>> memory/speed problems.  Can
>>>>
>>>>> cocoon serve large documents reasonably?
>>>>>
>>>>> The XML data is generated via a users request
>>>>
>>>> through a web page to a text
>>>>
>>>>> based system.  The data returned will be a 1-XXXX
>>>>
>>>> with aprox: 40-50 lines
>>>>
>>>>> per page report where it might look like this:
>>>>>
>>>>> page1.txt
>>>>>
>>>>> meh
>>>>> meh
>>>>>
>>>>>
>>>>> page2.txt
>>>>>
>>>>> bloo
>>>>> bloo
>>>>>
>>>>> Once i have transormed it to XML it will look
>>>>
>>>> something like this:  (could
>>>>
>>>>> also have identifiers for line number / page
>>>>
>>>> numbers etc.)
>>>>
>>>>>
>>>>> <page>
>>>>>     <line>meh1</line>
>>>>>     <line>meh2</line>
>>>>> </page>
>>>>>
>>>>> <page>
>>>>>     <line>bleh1</line>
>>>>>     <line>bleh2</line>
>>>>> </page>
>>>>>
>>>>> These files will be stored on the webserver's file
>>>>
>>>> system under
>>>>
>>>>> userid_reportX (they've authenticated) where x is a
>>>>
>>>> report number.  I will
>>>>
>>>>> allow them N amount of reports to be kept on the
>>>>
>>>> file system before they are
>>>>
>>>>> forced to delete them.  Or this is the initial
>>>>
>>>> plan.  Haven't implemented
>>>>
>>>>> anything yet.
>>>>>
>>>>> Any input regarding this particular problem would
>>>>
>>>> be appreciated.
>>>>
>>>>>
>>>>> -Adam
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>>
>>>> To unsubscribe, e-mail:
>>>> cocoon-users-unsubscribe@xml.apache.org
>>>> For additional commands, e-mail:
>>>> cocoon-users-help@xml.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
>>> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
>> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
Craig Nock

-- 
Sapphire One Support Unit

Sapphire One Pty Ltd
A.C.N 003419930
A.B.N 84003419930
Locked Bag 1, Bondi Beach, 2011
Australia
Ph +61 2 8362 4500 Fx +61 2 8362 4599
support@sapphireone.com
http://www.sapphireone.com

PRIVACY AND CONFIDENTIALITY NOTICE: The information contained
in this e-mail is intended for the named recipients only. It may 
contain privileged and confidential information and if you are not an 
intended recipient, you must not copy, distribute or take any action in 
reliance on it. If you have received please notify us by replying to 
the original sender.

Mime
View raw message