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
