Well, for me, it is all about code portability, and code maintenance,
balanced with performance.
In the evolution of my stuff, I have used various methods to shore up
witango weaknesses, or add features that witango doesn't have.
For instance, before 5.5, all of my webservices, except for VERY
simple ones, were written in realbasic, and compiled and installed as
windows services. Witango would com via <@url, which is VERY fast.
But it was always my goal, to get this as much as possible, all into
witango code, for portability. Once 5.5 came out, I was able to get
around all of the text encoding issues (with much effort) and moved
99% of my services to be completely done in witango.
However, there were still issues with webservices that required lots
of looping, or special xml processing, or whatever. With these, I
would do external actions, command line apps using RB, but the bean
is much more efficient. But much more of a pain in the butt, cuz of
ZERO documentation, and VERY buggy. But I have mapped most of the
mine field.
This is my opinion, but when managing a team of devs, and working on
large sites, keeping the code as much as possible in one place, is
extremely helpful, and I would say necessary. I use VERY few stored
procedures for instance, because of this. with <@URL, you have
services installed in different locations, and you have to maintain
that on a bank of servers, and it gets cumbersome. By moving all code
into witango, or php, or whatever, then it is MUCH easier to
maintain, and debug.
So I will always try to do completely in witango first, then opt for
a bean second. If done right, the bean is as fast or faster than
<@url like, FASTCGI type communication.
You are well aware of the level we use webservices, and you can see
how cumbersome it would be, if this code was spread out, and not all
in witango.
So I guess, the answer is, I will do <@URL only as a last resort,
when a bean is not possible, or a script is not efficient enough. The
external script, has the limitations of the environment var
interface, and a 30ms or so overhead to launch the external service.
So if the process you are doing, is a ~100ms process, external script
is too ineffecient, must use a bean. But if the process is 1000ms, or
even longer, external action is fine, cuz the 30ms, is not going to
be noticed.
Hope that all makes sense.
--
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:47 AM, William M Conlon wrote:
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
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
