[Webtest] [webtest][JIRA] Created: (WT-87) Addressing the OutOfMemory issue in reporting

[Denis N. Antonioli]

Hi

well, my first benchmark will be the tests I have now at work - see  
if it brings
an improvement there. I agree that it would be good to be able to  
monitor
this behavior. Maybe it is possible to instrument webtest's selftest  
to get
meaningful numbers?

I didn't knew these XOM/NUX projects - and they do look interesting -  
but I
did already serialization by hand: it didn't look like such a big  
deal, less than
0.5 day for the serialization, including a DTD and a minimal amount  
of junit
tests. I'll get it running tomorrow on my productive test suite and  
see it it
really improves things.

Best
     dna

On 19 sept. 05, at 11:17, Paul King wrote:

>
> What you are suggesting sounds fine at first glance. I guess what I  
> would
> like to see is a benchmark test of some kind which we can use to  
> compare
> the before and after memory usage.
>
> The entity approach seems like a bit of a hack to me. It would be  
> hard to
> explain to newbies why it was done that way - thought they are  
> likely to
> never see it and you are right it would be a lot faster. You  
> [we :-)] might
> be able to do something smart with XOM/NUX with the in-place update  
> feature.
> This might not require the entity include.
>
> If you do go for the serialization approach, what were you planning to
> use for the serialization technology? XmlBeans? XStream? Hand-coded?
>
> Cheers, Paul.
>
> Denis N. Antonioli (JIRA) wrote:
>
>> Addressing the OutOfMemory issue in reporting
>> ---------------------------------------------
>>          Key: WT-87
>>          URL: http://webtest-community.canoo.com/jira/browse/WT-87
>>      Project: WebTest
>>         Type: Bug
>>     Reporter: Denis N. Antonioli
>>  Assigned to: Denis N. Antonioli      Fix For: 1.7
>>
>>> From previous discussions and analyses, it looks like the xml  
>>> reporting is one of the main culprit.
>>>
>> xml reporting works now as follows:
>> (1) reads the existing report file and build a DOM for it,
>> (2) convert the testResult (all the java Objects for the steps)  
>> into xml Element and inserts them at the end of the DOM,
>> (3) serializes the DOM back to the report file.
>> I see two issues with this procedures:
>> First, it repeatedly reads and converts the report file to DOM,  
>> which is a potentially expensive process, and it needs every time  
>> more memory since the report file itself is growing.
>> Then, it converts the testResult from hierarchy of webtest Objects  
>> to a DOM, which is also bound to consume memory.
>> I'm planning to addess the two issues separately.
>> First, I'd like to get rid of the reading/writing of the result  
>> file. I've already done a prototyp that works as follow:
>> the webtest report xml file is just a container:
>> In this example, the user set the name of the webtest report file  
>> to WebTestReport.xml in the test configuration.
>> The file WebTestReport.xml contains just:
>> <?xml version="1.0" encoding="ISO-8859-1"?>
>> <!DOCTYPE summary [
>> <!ENTITY testresult SYSTEM "WebTestReport_.xml" >
>> ]>
>> <summary>
>> &testresult;
>> </summary>
>> The file WebTestReport_.xml contains a concatenation of all the  
>> <testResult>.
>> By doing it this way, no changes are required from all the xml  
>> processors/xsl stylesheet used to format the reports works.
>> Then I will suppress the intermediate DOM and serialize the  
>> Webtest objects directly to the output file as xml tags.
>> What do you think?
>> Good idea? Bad idea? Other proposal? Any pitfall?
>> I'm hoping for comments ;-)
>>
>
> _______________________________________________
> WebTest mailing list
> WebTest@lists.canoo.com
> http://lists.canoo.com/mailman/listinfo/webtest
>

-- 
"... the whole documentation is not unreasonably transportable in a
  student's briefcase." - John Lions describing UNIX 6th Edition
"This has since been fixed in recent versions." - Kernighan & Pike