asynchronous requests a lot faster then synchronous requests!

[smies]

I just finished with my adapted version of the ZmCsfeAsynchCommand and after running a couple of tests I came to the conclussion that asynch communication is a lot faster then the synch communication.

Here are the test results.

synch roundtrip: 1400 - 1600 ms
asynch roundtrip: 203 - 1000 ms

So asynch can be about 7 times faster then synch. It fluxtuates for some reason.

My tests aren't designed for benchmarking, but besides that, it looks a lot faster. In near future I will do some serious benchmarking because I find this really important to now before I create a real application with ajax and zimbraTK.

Here you see the debug messages returned from the roundtrip. I used the same soap command and the same data with both versions.

 REQUEST

 ------------------------------------------------------------------------

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<FindPersonById xmlns:n1="urn:ActionWebService">
<id>
1
</id>
</FindPersonById>
</soap:Body>
</soap:Envelope>

------------------------------------------------------------------------

 REQ. HEADER: Content-Type - text/xml; charset=UTF-8

 REQ. HEADER: SOAPReturnFormat - JSON

 REQ. HEADER: SOAPAction - /client/api/FindPersonById

 ROUND TRIP TIME: 1437



 RESPONSE

------------------------------------------------------------------------

 Body: {
  birthdate: "1982-04-22",
  email: "info@smies.com",
  firstname: "Maurice",
  group_id: 5,
  id: 1,
  lastname: "Zeijen"
 }

------------------------------------------------------------------------

 ASYNCHRONOUS REQUEST

------------------------------------------------------------------------

 <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soap:Body>
<FindPersonById xmlns:n1="urn:ActionWebService">
<id>
1
</id>
</FindPersonById>
</soap:Body>
</soap:Envelope>

------------------------------------------------------------------------

 Found free Rpc Context in cache

 Have callback

 REQ. HEADER: Content-Type - text/xml; charset=UTF-8

 REQ. HEADER: SOAPReturnFormat - JSON

 REQ. HEADER: SOAPAction - /client/api/FindPersonById

 ReadyState changed

 ready state = 1

 ReadyState changed

 ready state = 2

 ReadyState changed

 ready state = 3

 ReadyState changed

 ready state = 4

 status = 200


 ASYNCHRONOUS REQUEST RETURNED

 ASYNCHRONOUS ROUND TRIP TIME: 203

 RESPONSE

------------------------------------------------------------------------

 Body: {
  birthdate: "1982-04-22",
  email: "info@smies.com",
  firstname: "Maurice",
  group_id: 5,
  id: 1,
  lastname: "Zeijen"
 }

------------------------------------------------------------------------

[KevinH]

Yes we've discovered this too. In fact you'll see more use of async in the next release. We've converted most of our code to use async calls to the server.

[pshah]

Just curious, are these results based on FF or IE?

[rdargahi]

Great post smies We have actually deprecated ZmCsfeAsynchCommand and modified the ZmCsfeCommand.prototype.invoke method to also support asynchronous calls (basically there is a callback parameter that if populated will result in the call being asynchronous). Among other things, we have also added the ability to cancel outstanding requests so that it is possible to allow the user to cancel operations if so desired.

As Kevin mentioned, we have made a first pass at moving all of our network calls to using the asynchronous model (there are a few we have not gotten to, and couple we cannot convert because of some interesting interactions with the browser). We have just about completed the work and will probably do another pass at flattening the codes callback structure in the near future.

We first used the synchronous model, because a couple of years ago when we were new to AJAX and trying to code the client, we first discovered the synchronous model and it was most expedient to just use it (since we were dealing with lots of other variables at the time). We have been badly wanting to convert for the longest time, but because of product requirements and release schedules, we have just not been able to get to it (and it is one of those things that the longer you wait the more painful it becomes to convert! )

My advice to you is to use the asynchronous model unless it makes no sense for your particular application. However, be aware that it can make your code more complex. You will by nature have to deal with callbacks which can be quite inconvenient and disruptive to the call flow since you basically lose the call stack and may have to cart state around - again this can be minimized if you start out with the async model in mind. For example, consider using a notification mechanism (such as the one provided in the AjaxTk) to indicate when operations are completed. For example, if you are using MVC, then a model would notify all interested listeners, such as controllers, that a modification has occurred to its state.

If you are careful, it should be possible to keep your callback depth to a couple levels in most cases. Also remember that if your app permits, it is possible to have multiple outstanding requests which may complete out of order, so your code should be robust enough to handle such a scenario. Also, you need to be aware of when to block the UI to prevent user interaction and when to allow the user to continue using the UI despite the fact that multiple operations may be executing in the background.

I am sure there are other issues, they just don't come to mind right now But good luck with your application!

[smies]

Thanks for all the tips, but they strange to me. I was already planning to use asynch as often as possible. The main reason is that sync communication can let the browser stall when there is something wrong on the server or a request/response just takes very long. Now I have some more reasons to use async communication .

I am also happy to hear that Zimbra is being converted to async communication. It's just better in a lot of cases.

[czaveri]

Would it not be possible to use asynchronous requests while sending email? Some users on my server were asking me about this. They were comparing Zimbra with Outlook wherein they can still do other things while the email is being sent.

[Ericx]

Can some one explain how to best use callbacks. I'm trying to do something I think is very simple. I have a zimlet, when I drag and drop an email an object is created. I can extract values like to, from, email id. But the body is in plain text. I want the fromat to be in html.

I'm trying to think in classes, but the concept of callbacks is preventing me from loading the objects in a manner that I'm accustomed to. I feel like everything is stored in parameters that I can't see or find. And callbacks are calling callback handlers all over the place. The argument types required by the functions are also very difficult to hunt down. I've started to make some headway by breaking apart the ZM_mail_all.js (not sure if that's the exact name but close), but that is not easy to follow either. I just feel like I'm missing some piece of information that will tie it all together, or there is some IDE or plugin that I could be using that will expose my options?