I might have to consider doing the _file version of my method xslt
method. I suppose I could even set a threshold based on the length of
the variable, right? and have the witango code decide which version of
the bean method to call.
/John
Robert Garcia wrote:
its not just the debugging. In my notes on doing the beans, with the
xml stuff I did, and with jmagick, the bean chokes on input of large
data. Any bean method, if you pass more than a few K to it, you will
lose all of the efficiency that you got from doing the bean in the
first place.
So, what I do, is I always have to methods for the same thing, like
String doMyXMLthing(inxml String) and String doMyXMLthing_file(inxml
String)
The second one, you send in a file reference to the bean, and let the
bean read from disk, it is a pain in the ass, I know, it should all
work in memory, but you will find, there is a size of the inputed
string, that will be much faster if you write to a file in witango,
and pass just the path to the bean. I don't remember how big, but I
think somewhere between 100k to a meg.
As far as I know, there is no workaround for this, I spent hours
trying to find if there was any way around it, but it seems there is
an issue with the bean handler, and witango never responded to me
regarding it.
My goal was to have methods for xml and images, that only required
memory, but this issue makes it impossible.
And yes, big debug xml will choke witango, but I haven't found that to
be an issue, cuz when you turn debug off, it goes away, but when debug
shows you the results of a huge var, it can take a long time.
--
Robert Garcia
President - BigHead Technology
VP Application Development - eventpix.com
13653 West Park Dr
Magalia, Ca 95954
ph: 530.645.4040 x222 fax: 530.645.4040
[EMAIL PROTECTED] - [EMAIL PROTECTED]
http://bighead.net/ - http://eventpix.com/
On Jun 14, 2006, at 9:04 AM, John McGowan wrote:
I've always thought that debugging didn't have much of an effect on
the performance of a TAF. I always knew that lots of debugging
information caused a lot of extra traffic to be sent back in the http
response, and I understood that pages may take longer to load when
you have the addition of many many kilobytes of text added to the
resulting webpage, but i ran into something here today that showed me
there is more to it.
I wrote a java bean to essentially mirror the functionality of the
@XSLT tag but using the newest version of Xalan-J instead of the
Xalan-C included with Witango. I'm doing this to benefit form
features that re in Xalan-J that are not part of Xalan-C.
I have a page that sends a very large XML document to that bean to be
processed by a stylesheet. The page was taking a long time to load
and the last timestamp in the debugging output was always over
10000. Each time the XSL processing bean was called, the input and
ouput xml was being included in the debugging information, and it was
looking to me like the xsl processing was taking up all the time.
However when i turned off debugging, i noticed the page loaded much
quicker and the time it took to execute on the server was on the
order of 1-2 seconds instead of 10-20.
Witango was really chewing up CPU simply writing those very large XML
results to the debugging output.
Anybody else ever run into the same thing?
--
John McGowan
[EMAIL PROTECTED]
P 847.608.6900 x 110
F 847.608.9501
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
--
John McGowan
[EMAIL PROTECTED]
P 847.608.6900 x 110
F 847.608.9501
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
