Howto: Optimising RPC

[George Georgovassilis]

Hello all,

I've been spending some time with reducing RPC payload size and
optimising the request pattern and thought I'd share my pain and
wisdom with you :-)

You can read the full story here [1], the main points I am discussing
are:

- rewriting RPC to use GET over POST for reduced network packet count
- type name elision (and pitfalls)
- packing variables (and when not to)
- using higher gzip compression ratios
- batching requests

Please feel to post any comments
G.

[1] http://georgovassilis.blogspot.com/2011/03/squeezing-last-bit-out-of-rpc-gwt.html

[Gal Dolber]

Nice post, thanks.

I am having a problem code-splitting my rpc classes and dependencies when using the command pattern. 

Even if I only load the login screen, if it uses any command rpc it forces my apps to load all of them. I am testing some solutions at the moment, any thoughts on that?

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Guit: Elegant, beautiful, modular and *production ready* gwt applications.

http://code.google.com/p/guit/

[George Georgovassilis]

Hello Gal,

Sorry, I've had so far no experience with code splitting, my applications are all monolithic beasts. I guess the real bloat is not the DTOs but the marshalling code generated for RPC, right?

I can think of a possible solution (haven't tested this) but it's ugly: assuming that my DTOs live in a defined hierarchy, lets take two as an example:

my.package.dto.a.*
my.package.dto.b.*

they can be reflected with a set of corresponding Commands:

my.package.commands.CommandA
my.package.commands.CommandB

where CommandA references only classes from my.package.dto.a and CommandB references only classes from my.package.dto.b. I realise that even this is a long shot because such a distinction might not always be feasible.

To make it worse, I'll probably need multiple service interfaces:

interface MyBatchServiceA{

ResultA process(List<CommandA> commands);

}

etc

If I can think of something better I'll post back

[Paul Stockley]

I had the same issue with the command pattern. The problem is that all commands/results implement a common interface. The first time the service is created, it needs all the Marshalling code for all commands/results. The only way to avoid this is to have different services that define unique interfaces for their commands/results i.e. ServiceACommand interface and ServiceAResult interface.

In the end I gave up on the command pattern and switched back to standard RPC with different services for each logical area.I added common error handling / version checking in a service facade.

[Gal Dolber]

Another two optimizations on the compiler (the first one affects gwt-rpc): 

-XdisableClassMetadata  EXPERIMENTAL: Disables some java.lang.Class methods (e.g. getName())

-XdisableCastChecking   EXPERIMENTAL: Disables run-time checking of cast operations

On Tue, Mar 29, 2011 at 12:53 PM, Paul Stockley <pstoc...@gmail.com> wrote:

I had the same issue with the command pattern. The problem is that all commands/results implement a common interface. The first time the service is created, it needs all the Marshalling code for all commands/results. The only way to avoid this is to have different services that define unique interfaces for their commands/results i.e. ServiceACommand interface and ServiceAResult interface.

In the end I gave up on the command pattern and switched back to standard RPC with different services for each logical area.I added common error handling / version checking in a service facade.

[George Georgovassilis]

Hi Gal,

That's a good point - I'm actually using them in production (since we are at it, I might throw in
    <set-property name="compiler.stackMode" value="strip"/>)

However I've found none of those to affect actual RPC payload size, though they most certainly reduce the compiled javascript size.