WHY so SLOW?

102 views
Skip to first unread message

clem...@gmail.com

unread,
May 1, 2015, 12:04:05 PM5/1/15
to gwt-pl...@googlegroups.com
Hello.
I am new to GWTP.
I am just trying this framework and testing it a bit...
I created several action/result/handler to perform calls dispatch-RPC.

in my test I have 3 buttons on my client.

button one calls action1/result1/handler1
button two calls action2/result2/handler2
button three calls action3/result3/handler3

every handler is extremely simple:
it just performs an objectify get by key operation

the first time I push the button one it takes up to 5 seconds to get the answer
the first time I push the button two it takes up to 5 seconds to get the answer
the first time I push the button three it takes up to 5 seconds to get the answer

after that I can click any button and I will have the answer within 500 ms.

my question is why? (do not tell me that it depends on what I write on the handler because in the handler if I just write return null, it's the same)
is it because the first time I click on a button the server has to start a different servlet (one servlet per handler?) and that is long?

Another question:
why use GWTP dispatch-RPC action/result/handler , instead of the "usual GWT RPC"?  (what are the pros and cons both on the server side and on the client side?).
Thanks very much.

Christian Goudreau

unread,
May 1, 2015, 12:15:18 PM5/1/15
to gwt-pl...@googlegroups.com
What is your backend? Then, 5 seconds is really long, I've never experienced such latency unless it is the cold start of Google App Engine when I didn't had resident instances.

There's also two types of handles (badly documented) Lazy and Eager. The lazy ones (default) instantiate the handler as needed while the eager one instantiate all handlers at startup of the app.

So yes, it can be related to what you have to instantiate in all your handlers, then what is kept in memory.

Now, why Dispatch RPC? To introduce a command pattern that can let you easily add: Batch requests, sequencing and undo/redo. The idea behind is explained in that video: https://www.youtube.com/watch?v=PDuhR18-EdM

Personally, I prefer APIs and that is why we've built REST-Dispatch. It is much more lightweight and server side agnostic while keeping some of the goodies you get from the command pattern, without the boiler plate code that you have in RPC Dispatch.

Cheers,


Christian Goudreau | CEO - Président

--
You received this message because you are subscribed to the Google Groups "GWTP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gwt-platform...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

clem...@gmail.com

unread,
May 16, 2015, 12:43:25 PM5/16/15
to gwt-pl...@googlegroups.com
Thank you for your answer.
My backend is GAE...
Can you please show me some links about the 2 types of handles lazy and eager. is it specific to gwtp or is it a gae or gwt feature? 

clem...@gmail.com

unread,
May 16, 2015, 1:00:20 PM5/16/15
to gwt-pl...@googlegroups.com
And another question:

When I was using gwt and gae (without GWTP) I used to create a remote interface on which I could call a lot of methods:


@RemoteServiceRelativePath("greet")

public interface GreetingService extends RemoteService {

BarterConnectResult connect(BarterConnectRequest connectData);

SaveImagesResult saveBarterImage(SaveBarterImagesRequest saveImagesRequest);

SaveBarterItemResult saveBarterItem(SaveBarterItemRequest saveItemRequest);

SaveVotesResult saveVotes(SaveVotesRequest saveVotesRequest);

GetImagesResult getBarterImages(GetImagesRequest getImagesRequest);

........

}


Is it bad pratice to do like this? I do not really mind using the gwtp rest dispatch functionnality but the problem that I have is the performance:

the way I used to do things involve in fact the creation of one serverlet only called "greet" which means that after making one RPC call everything is initiliase and I will only have one RPC call that is long to return.

whereas when I use the RPC dispatch there is more than only one...



Reply all
Reply to author
Forward
0 new messages