Optimizing RPC: directly-eval'able server responses
Rob Jellinghaus
>From the Gears/GWT thread, Scott said:
"BTW: The reason the server couldn't simply send the client a
directly-evalable string is that the server doesn't know the
obfuscated
symbol names of the various fields and constructors. If the server
DID know
those symbols, we could probably make deserialization an order of
magnitude
faster. But that's a separate discussion. :)"
This thread is that separate discussion!
Why can't the server know the obfuscated symbols on the client? Is it
to prevent the server from having to be aware of what client-side
compilation mode was used? Could there be some kind of dictionary
that the GWT generator builds, that could be put on the server's
classpath as a resource, and loaded (if present) to enable server-side
direct-eval response construction?
The key questions are:
1) is this breaking some important information hiding that you want to
maintain over the wire?
2) how large would the performance increase actually be?
3) is this moving in the direction of something like a generic JSON-
ish wire format that would let the server part of GWT RPC be used by
NON-GWT clients?????????
Cheers!
Rob
Rob Jellinghaus
Rob Jellinghaus wrote:
> The key questions are:
Oops, one other key question:
4) What's more important, server-side performance (of RPC response
construction), or client-side performance (of RPC response
deserialization)?
If you care more about user experience (e.g. not blocking the UI
thread), you probably care more about client-side performance. If you
care more about server scalability, you probably care more about
server-side performance....
Cheers!
Rob
Ian Petersen
> 1) is this breaking some important information hiding that you want to
> maintain over the wire?
I'm not sure what you're hinting at here, but I'd like to get in early
with "security by obscurity is not secure". If anyone is relying on
GWT's wire format being obfuscated for security reasons, they're
already hosed.
> 4) What's more important, server-side performance (of RPC response
> construction), or client-side performance (of RPC response
> deserialization)?
I have to vote for client-side performance being more important. If
my server is too slow I can buy a bigger one or another one. If my
client is too slow, I can do nothing more than beg my customer to buy
a newer machine.
Ian
--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com
Sandy McArthur
On 6/6/07, Rob Jellinghaus <rjelli...@gmail.com> wrote:
> Why can't the server know the obfuscated symbols on the client? Is it
> to prevent the server from having to be aware of what client-side
> compilation mode was used?
Compile -style mode, source/class versions, deferred bindings,
possibly the order of the parts of GWTCompiler's classpath/sourcepath
could all affect that naming of obfuscated methods.
To do this you would need to tie the server classes to the generated
JavaScript. One change in one would necessitate the recompile/deploy
of the other. This would seriously negatively affect refresh cycle of
people who use the no server mode.
--
Sandy McArthur
"He who dares not offend cannot be honest."
- Thomas Paine
Rob Jellinghaus
> Compile -style mode, source/class versions, deferred bindings,
> possibly the order of the parts of GWTCompiler's classpath/sourcepath
> could all affect that naming of obfuscated methods.
>
> To do this you would need to tie the server classes to the generated
> JavaScript. One change in one would necessitate the recompile/deploy
> of the other. This would seriously negatively affect refresh cycle of
> people who use the no server mode.
This is exactly what I was alluding to when I mentioned "information
hiding" between server and client.
Given that doing this does require a full server/client deploy cycle
(since the server needs state generated from the full client build),
and given that there are tradeoffs about whether you want to optimize
the client deserialization at the expense of the server's performance
(and at the expense of your build cycle), it feels like this would
definitely have to be an optional optimization. Basically it'd need
to be a final-deployment step once your main development is nearly
complete and build turnaround is less critical. Those who want the
server serialization to be fast could do without it altogether.
And again, exactly how much of a win it is (given the considerable
effort required!) is completely subject to discussion.
More?
Cheers,
Rob
The Class Connection
> 4) What's more important, server-side performance (of RPC response
> construction), or client-side performance (of RPC response
> deserialization)?
I have to vote for client-side performance being more important. If
my server is too slow I can buy a bigger one or another one. If my
client is too slow, I can do nothing more than beg my customer to buy
a newer machine.
I vote server-side performance being more important. I am less than happy with my explanation, but I have yet to think of a better way to say the following: As server-side work scales with the number of users, so does the savings given by any server-side optimization. The client side's optimization has a much smaller visible impact as each user sees a constant improvement, not a scaling improvement...
Also, my server is going to get run to its limits. My site is going to have more than a mebibyte of downloaded code before a user can use the interface. I expect my audiance to be primarily broadband users, people who, I expect, will have more than enough headroom to deal with the lack of client-side optimization...
Jason Essington
with the server returning an eval()-uable string, we could also move
in the direction of allowing cross site (JSON style <script>
injected) RPC for GWT mashups. There's still an issue with the amount
of info that can be sent via the <script>'s get, but I still think it
is a compelling idea.
-jason
Joel Webber
As Sandy points out, though, generating code on the server is a bit of an issue if you don't want to recompile your server all the time. Maybe there's a way to make this optional, but it is certainly a consideration.
One benefit to the client I want to mention is that, in addition to making the code much *faster*, it will also make it much *smaller*. The deserialization code can be quite significant, and I'm all for doing anything that eliminates client code.
joel.
John Tamplin
with the server returning an eval()-uable string, we could also move
in the direction of allowing cross site (JSON style <script>
injected) RPC for GWT mashups. There's still an issue with the amount
of info that can be sent via the <script>'s get, but I still think it
is a compelling idea.
Not saying there isn't value in cross-site RPC, but that doing it opens a lot of security issues.
--
John A. Tamplin
Software Engineer, Google
Toby Reyelts
It doesn't seem to me that the optimization under discussion would make a lot of difference either way on the server. In fact, if the server-side serialization code is generated, there's no reason it couldn't be pretty much optimal.
As Sandy points out, though, generating code on the server is a bit of an issue if you don't want to recompile your server all the time. Maybe there's a way to make this optional, but it is certainly a consideration.
One benefit to the client I want to mention is that, in addition to making the code much *faster*, it will also make it much *smaller*. The deserialization code can be quite significant, and I'm all for doing anything that eliminates client code.
Ooooh. That's a nice point. Ripping deserialization code out of the client would be great.
Scott Blum
Maybe a more promising approach would be that the client could somehow produce an eval enviroment? IE: expose well-known symbols into this environment that could be statically infered. It'd make the client-side code a little bigger, but might be speedier. We should perhaps mock something up and analyze what the potential performance boost would be.
Scott
Ian Petersen
> with my explanation, but I have yet to think of a better way to say the
> following: As server-side work scales with the number of users, so does the
> savings given by any server-side optimization. The client side's
> optimization has a much smaller visible impact as each user sees a constant
> improvement, not a scaling improvement...
You make a very good point about the scaling effects of server-side
optimization...
> Also, my server is going to get run to its limits. My site is going to have
> more than a mebibyte of downloaded code before a user can use the interface.
> I expect my audiance to be primarily broadband users, people who, I expect,
> will have more than enough headroom to deal with the lack of client-side
> optimization...
...but I'm less concerned about the size of an RPC payload than I am
about the time it takes the client to decode the payload once it has
arrived, and I don't think broadband-users are uniformly likely to
have fast machines at the end of their fast connections.
There are several things I'm worried about performance-wise:
- as a Linux user I hear horror stories of Windows users whose
machines are infested with spyware and everything slows to a crawl. I
don't know if this is a legitimate concern.
- Internet Explorer's JScript engine is, in my experience, dog slow
and lots of people are stuck with IE
- I assume that lots of people buy medium- to low-spec machines and
then plug them into cable internet. A cache-poor processor like the
Celeron, plus too little RAM can still browse Web 1.0 at high speed,
but it's not going to be any good at running a processor-intensive app
built with GWT.
Miguel Méndez
Miguel
Toby Reyelts
Scott Blum
Note that there are security considerations involved here -- if you make the return directly evalable (without stripping off // or something similar), you not only allow cross-site RPC but CSRF as well. To prevent that, you need to add some authentication token in the GET request and have the server not send sensitive data if it isn't present.
Not saying there isn't value in cross-site RPC, but that doing it opens a lot of security issues.
Scott Blum
Rob Jellinghaus
supposed to be just about Java 1.5! EVIL USER, SCOPE CREEP, BAD BAD
BAD!
On Jun 6, 1:49 pm, "Scott Blum" <sco...@google.com> wrote:
> Volunteers? :)
>
> On 6/6/07, Toby Reyelts <t...@google.com> wrote:
>
>
>
> > +1 - I'd love to just see the base line best performance improvement we
> > could get by attempting an evalable wire format. It doesn't seem difficult
> > to mock up.
>
Scott Blum
Oh God, why did I bring this topic up when the next GWT release is
supposed to be just about Java 1.5! EVIL USER, SCOPE CREEP, BAD BAD
BAD!
The Class Connection
John Tamplin
Fushion
This will enable developers to select their optimal RPC
implementation:
- the default (current?)
- client optimized
- server optimized
- other 3rd party implementations (based on JSON / 'real java
serialization'/ etc. )
The RPC implementation to be used could be set in the application.xml.
This will enable the compiler to eliminate non-used RPC implementation
code.
This will also speed up the development/test cycle of next releases,
as developers who don't care about RPC won't be bothered by unfinished
RPC implementations.
Just my 2 cts...
Greetz,
Menno van Gangelen.
On 6 jun, 23:14, "The Class Connection" <theclassconnect...@gmail.com>
wrote:
> Yeah, way to go man... If I get a tiny server-side slowdown AND no
> annotations/typesafe-collections/for-each, I'm going to literally cry.
>
> > > > > Miguel- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -
Miguel Méndez
Volunteers? :)On 6/6/07, Toby Reyelts <to...@google.com> wrote:+1 - I'd love to just see the base line best performance improvement we could get by attempting an evalable wire format. It doesn't seem difficult to mock up.
On 6/6/07, Miguel Méndez <mme...@google.com> wrote:SGTMOn 6/6/07, Scott Blum < sco...@google.com> wrote:The more I think about relying on knowing the compiler's generated symbols, the more it seems like a fool's game to me; they would be different on every permutation (so you'd have to know which perm the client was running), and it seems like it RPC and the compiler would have to be way too closely tied.
Maybe a more promising approach would be that the client could somehow produce an eval enviroment? IE: expose well-known symbols into this environment that could be statically infered. It'd make the client-side code a little bigger, but might be speedier. We should perhaps mock something up and analyze what the potential performance boost would be.
Scott
--
Miguel
Miguel
Scott Blum
I'd opt for a pluggable RPC framework.
This will enable developers to select their optimal RPC
implementation:
- the default (current?)
- client optimized
- server optimized
- other 3rd party implementations (based on JSON / 'real java
serialization'/ etc. )
For example, I think we could greatly improve server-side performance by generating server-side classes during the RPC compile rather than relying on runtime reflection.
Scott
Fushion
On 7 jun, 15:31, "Scott Blum" <sco...@google.com> wrote:
>
> I like this idea in principle. However, I don't think we're at the point
> where we can say "Our solution is as all-around optimal as it can be without
> making trade offs." I personally would like to see how far we can push the
> envelope with a single all-around great solution before we invest too much
> effort into making trade-offs on one front to optimize another.
>
> For example, I think we could greatly improve server-side performance by
> generating server-side classes during the RPC compile rather than relying on
> runtime reflection.
Agreed, but making RPC pluggable won't interfear with optimizing the
default RPC implementation... :-)
Scott Blum
Toby Reyelts
Scott Blum
Ahem, we are NOT working on any secret projects involving an infinite number of monkeys. Seriously.
The Class Connection
Rob Jellinghaus
On Jun 7, 11:52 am, "The Class Connection"
<theclassconnect...@gmail.com> wrote:
> Next, you'll tell me there is no cow level...
>
> On 6/7/07, Scott Blum <sco...@google.com> wrote:
>
>
>
> > Toby, please do not discuss Project Infinite Monkey publicly.
>
> > Ahem, we are NOT working on any secret projects involving an infinite
> > number of monkeys. Seriously.
>
> > On 6/7/07, Toby Reyelts <t...@google.com> wrote:
>
> > > Don't we have an infinite number of developers working on GWT?
> > > On 6/7/07, Scott Blum < sco...@google.com> wrote:
>
Kelly Norton
/kel
Reinier Zwitserloot
How about something like this: The GWT Compiler produces 1 class file
in addition to the slew of permutations dumped in /www. This class
file is then dynamically loaded, every time it is instantiated, using
a bridge class for instantiation (not new GwtCompiledSymbolStore(),
but GwtCompiledSymbolUtilities.getStore(), and then with (much) better
name). This takes care of one issue: You don't need to recompile or
even restart anything server side. All you need to do is make sure
that the server code re-gets a 'fresh' reference to the store for
every request. This seems trivial. This can work using a custom
ClassLoader, ample helpings of reflection, and a couple wrapper
methods/classes.
Hence there are 2 components to delivering symbol names to the server
app:
the single class file regenerated on every run of the GWT compiler,
and
an unchanging library of sorts that interfaces with that single class
file to allow the eval stuff to work.
Come to think of it, you don't actually need for that one file to be
a .class at all, it can be any sort of data file.
A parameter to the compiler can produce an actual .class file with
none of the dynamic reloading capabilities. This will be considerably
faster (no need to reread from disk every time, for one) and can be
used for deployment.
A wholly separate issue is for how to deal with this stuff in hosted
mode. I assume there's a simple solution to this - all the original
full symbol names are available to the hosted mode browser.
My apologies for being all talk and no write, as I have no time just
now to take this up, plus I have a big list of patches I want to
submit, some of which are more important to me than this idea.
Still, it's -very- cool.
--Reinier Zwitserloot
GeertB
> I'd opt for a pluggable RPC framework.
>
> This will enable developers to select their optimal RPC
> implementation:
> - the default (current?)
> - client optimized
> - server optimized
> - other 3rd party implementations (based on JSON / 'real java
> serialization'/ etc. )
+1
I'm thinking of small linux embedded devices that could use GWT with a
3rd party RPC implementaion that is served by their small web servers
typically written in C.