Robert,
From a philosophical/design perspective, where would you replace a
bean/external script with a web service? Would <@URL> which I presume
is threaded, offer some advantages over writing a file and then
spawning a process.
One could also then run the bean outside of the witango user space,
in case memory is an issue.
On Jun 14, 2006, at 10:21 AM, Robert Garcia wrote:
yes, you will have to experiment what the threshold is, as I don't
remember, I ended up just doing the file method on the thumbs, and
blob on the xml, cuz I rarely send in big xml, but the images were
always to big.
The issue doesn't seem to effect info coming from the bean to
witango, so I have always kept that in memory.
--
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 10:16 AM, John McGowan wrote:
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
______________________________________________________________________
__
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
Bill
William M. Conlon, P.E., Ph.D.
To the Point
345 California Avenue Suite 2
Palo Alto, CA 94306
vox: 650.327.2175 (direct)
fax: 650.329.8335
mobile: 650.906.9929
e-mail: mailto:[EMAIL PROTECTED]
web: http://www.tothept.com
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
