do use HTTP compression. And I'm sure you mean for the webservice--
right? It certainly will be faster-- no doubt. Remoting is still a
serverside deserialization of said webservice to native ActionScript
whereas the webservices API is a clientside deserialization of the
compressed web service soap. The actionscript webservices api uses the
built in xml classes in the flash player to parse the soap whereas the
remoting gateway does this process for you. The http compression thing
is completely unrelated to the respective implementations-- in other
words it would benifit both but remoting would still ultimately be
faster because it is a binary protocol. Thats what I mean by common
sense.... I suppose its common sense only if you understand that BOTH a
remoting server and the clientside webservices api can consume web
services. You see I'm not contending that you should use webservices for
your service layer. In fact I encourage it. I'm suggesting you consume
those services with a remoting server if you want to enjoy a performance
boost.
As that a swf can only consume a service from the same domain it resides
on the developer has little choice about this anyhow-- unless you have
access to the server publishing the service / then you can edit the
crossdomain.xml to allow access. A luxuery that somewhat defeats the
purpose of a service oriented architecture imo.
-----Original Message-----
From: Brian LeRoux [mailto:[EMAIL PROTECTED]
Sent: January 31, 2004 10:36 PM
To: CF-Talk
Subject: RE: Web Services vs. Remoting - Performance Tests?
I'd love to see your tests matt. Especially the actionscript you used.
Lets see it.
-----Original Message-----
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: January 31, 2004 9:34 PM
To: CF-Talk
Subject: Re: Web Services vs. Remoting - Performance Tests?
> Remoting is binary / web services are verbose xml therefore remoting
> *is* faster-- http compression or not. Benchmark or not. Its simple
> common sense.
Actually, no it is not common sense. HTTP compression of XML can often
result in a payload that is smaller than the equivalent representation
in AMF. Why is that? Well, like any protocol, there are redundancies in
data, so even if AMF was the least verbose protocol known to man there
would still be opportunities for compression. If you are looking for
simply common sense, I'd stick with testing. It allows you to determine
the situation as it applied to your application as opposed to relying
on biased points of view.
> Although if you take the time to read the tests and if you
> can understand the code, I'm assuming you cannot, then you would also
> understand it is a fair test.
It isn't a fair test if they don't take into account HTTP compression
or for that matter, alternate data providers.
> The fact that they have a business case
> for the benchmark means nothing. They wouldn't publish if it wheren't
> in
> their favor afterall. Just as Sun hasn't published any j2ee/.net
> benchmarks for a very long time.
It means that you have to assume that their benchmark is biased and
look at how it was arranged to best enhance their business case. Again,
the lack of viable alternatives being shown proves yet again that
benchmarks only serves the people who run the tests.
> Besides all of this http compression is
> a web server concern not applicable to a benchmark of the remoting
> technology itself.
>
I don't see why not. Why would I want to use a product (Flash Remoting)
whose sole purpose to solve a problem I wouldn't have using HTTP
compression?
> As I said before: flash remoting is a serverside technology capably of
> consuming webserivces and communicating to the client via a binary
> format whereas the new actionscript webservices api uses clientside
xml
> deserialization process. It *is* slower no matter what.
>
Not true; my tests have shown that in some circumstances Flash Remoting
is slower. It all depends on your application. Further, I have found
that even when Flash Remoting is faster it is not significantly faster,
which leads one to question whether the negatives of Flash Remoting
make it worthwhile.
> >From my experience the performance difference is really only
noticable
> when dealing with datasets-- or as it's known in cf land "querys".
>
Both arrays and structs can be large payloads as well.
-Matt
_____
_____
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
