Thanks, Matt. Our .DEF is about 25 Mb, but the XML version is 123Mb.
I'd prefer a supported OOB solution to avoid requiring XML expertise for
our Remedy application support. (Hypocritical given that we "roll our own"
ARS applications, but that's another story - :)
(you do do some "whizzy stuff" - hat's off)
Mike White
Office: 813-978-2192
E-mail: [EMAIL PROTECTED]
"Carey Matthew
Black" To: [email protected]
<[EMAIL PROTECTED] cc:
COM> Subject: Re: ARS object
cross-reference
Sent by: "Action
Request System
discussion
list(ARSList)"
<[EMAIL PROTECTED]
ORG>
11/30/2006 12:24
Please respond to
arslist
The basic issue I found was that you needed roughly 5 times the ram vs
the XML data file your parsing. (Using Saxon as the XSL transformation
engine via JSP(tomcat).)
So if you have a 100MB XML file then you needed to give your web
server 500MB of RAM. (Which actually takes some special config of the
web server a head of time.)
The performance( time to process) was not to bad if you could limit
the XML file size by doing things like...
Produce a file for only one ARS object type if that is all your
interested in.
Use XSL select statements that were "top down" instead of
"Anywhere" searches.
Work through the XML to a list and then drill down to get more details.
etc...
One issue with the way I constructed my web application is that I was
not doing any caching of the parsed XML or the returned results. If I
could find a way to generically implement a good way to parse and
cache the parsed version of the XML/XSL templates (and even better the
results of a single transformation) then I am sure the time to process
would be very reasonable. However I wanted to keep everything in the
XSL universe and not add any "fancy/complicated" stuff that the end
user would need to know about too. So ... I have yet to find a good
technical solution that meets all of my project goals.
If I ever decided to do something more like ARSDocs ( where the
results are cached from the XML file) then I think the "one time
processing" would be the "heavy part" and display performance would
become very light. I am however trying to not do anything that takes a
programmer to change the produced artifacts. ( XSL is not what I would
call programming, but some might disagree.)
--
Carey Matthew Black
Remedy Skilled Professional (RSP)
ARS = Action Request System(Remedy)
Love, then teach
Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.
On 11/30/06, Eric Roys <[EMAIL PROTECTED]> wrote:
> Matt,
>
> Just curious what the performance was like for you using the XSL approach
> against an XML file ranging in the neighborhood of 100+ MB? I messed
with
> it a bit after delving into XSL for another project and the results were
> less than responsive. I had better luck parsing it with PERL (which
wasn't
> pretty), but it still took plenty of time. It's too bad you ran into a
road
> block with your web-based utility as it looked promising. Can you
elaborate
> on the scaling issue?
>
>
> Eric Roys
> Sr. Software Engineer
> Verizon Business
> Email: [EMAIL PROTECTED]
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
