Hi,
I noticed that when a story has too many levels (containers, related
stories, ..) and fields, it takes a lot of time generating the XML
document for a SOAP export request.
After watching some code and profiling reports, I found that the XML
is written by XML::Writer to a IO::Scalar object which concatenates a
scalar variable in memory each time $obj->print() is called.
On a story with too much fields, containers and related stories, the
$obj->print() method is called a lot of times (one per node),
concatenating the XML scalar variable in memory which turns it on a
very heavy process.
This is very annoying when we have stories taking almost 3 minutes to
export.
Then I changed the code to write the XML into a temporary file on
filesystem, instead of working data in memory. So when print() is
called, it just write()'s data into the file. After the serialization,
the file is closed and read into memory.
Example with one story having 406 subelements, each one with a related
story:
With original Bricolage code:
real 2m50.793s
user 0m0.264s
sys 0m0.060s
After code changes:
real 0m11.001s
user 0m0.276s
sys 0m0.084s
The code patch is attached.
--
David Oliveira
<d.oliveira@prozone.org>
I noticed that when a story has too many levels (containers, related
stories, ..) and fields, it takes a lot of time generating the XML
document for a SOAP export request.
After watching some code and profiling reports, I found that the XML
is written by XML::Writer to a IO::Scalar object which concatenates a
scalar variable in memory each time $obj->print() is called.
On a story with too much fields, containers and related stories, the
$obj->print() method is called a lot of times (one per node),
concatenating the XML scalar variable in memory which turns it on a
very heavy process.
This is very annoying when we have stories taking almost 3 minutes to
export.
Then I changed the code to write the XML into a temporary file on
filesystem, instead of working data in memory. So when print() is
called, it just write()'s data into the file. After the serialization,
the file is closed and read into memory.
Example with one story having 406 subelements, each one with a related
story:
With original Bricolage code:
real 2m50.793s
user 0m0.264s
sys 0m0.060s
After code changes:
real 0m11.001s
user 0m0.276s
sys 0m0.084s
The code patch is attached.
--
David Oliveira
<d.oliveira@prozone.org>