28

I was hoping to be able to fire off multiple JavaScript Visualforce remoting calls in parallel and have the execute simultaneously, and for me to deal with the responses asynchronously.

Whilst in practice I can fire these off and get the reponses back (in a random order, as expected) I notice that the execution time of the responses increases for each request that is returned. So much so, in fact, that it is not much quicker to force sequential running of the individual calls.

This graphic shows 3 tests;

  1. Running 3 calls in parallel with the "buffer" param set to true (so VF remote calls are batched in one HTTP request)
  2. Running 3 calls in parallel with the "buffer" param set to false (so VF remote calls are sent in parallel as separate requests)
  3. Running 3 calls in sequence using JavaScript promises.

Vf remote tests

As you can see with (2) the second call that returns takes 2x as long as the 1st, and the 3rd call takes 3x as much... which leads me to think that although I'm firing the calls in at the same time they are actually being queued and run in sequence.

Does anyone know if this behaviour (in (2)) is to be expected or if there's a way to make the calls run more simultaneously?

  • So your buffer is true right ? Hoping you did not set it explicitly to false to slow it further – Mohith Shrivastava Mar 24 '16 at 23:56
  • I do ideally want to have it set to "false" as I want to achieve 2 things; 1. Have the result of each individual call as soon as I can (so perhaps to update the page with some info) 2. I was hoping that the calls would be dealt with in a more standalone simultaneous fashion, and hopefully quicker. – Todd Halfpenny Mar 24 '16 at 23:58
  • Promises seems Ideal and I guess the behaviour is expected to slow down with buffer false .Also I think if some logics which you do via three remoting calls can be moved to server side apex it would help reduce further time. – Mohith Shrivastava Mar 25 '16 at 0:01
  • 1
    Are you doing a call to the same apex controller/method? Probably there can be an bottleneck, But in general it looks like there is no parallel execution of remoting calls. Here is some more research about this behaviour jsforce.github.io/blog/posts/… – steals Mar 25 '16 at 15:37
  • That's an interesting post @steals, thanks for posting. It does seem to match my findings. And yes, in the example used in the OP I was calling the same controller/method for each. It does make me wonder whether this "queuing" is done on a per user basis or whether it's more global. – Todd Halfpenny Mar 25 '16 at 15:44
2

Actually, I had the same issue in one of my implementation and I found out it was sequential but asynchronous (crazy though). But managing the sequence can be handled by us setting some cookies which I did.

Creating a cookie on init and setting it back to some final value after callback helps us to poll and perform the action only when required.

On other side, I have seen during this polling resources do become available but we force the system not to make any call out by forcing it to be on wait mode till required value is set. The above is true for both buffer=false and buffer = true. If you watch the consolidated time for buffer= true its (26.xx s) and when buffer = false (total time for the third request is 24.xx s) which is including the Pending wait state.

0

This Blog post explains the various methods for asynchronous javascript, Promises being the most recent method which is widely supported. It is, in fact, asynchronous, and the issue is likely that processing multiple requests at once slows down how quickly your browser can process each request.

React process DOM updates as efficiently as possible. If you want to go down that route, here is some good learning material:

  • 1
    The post wasn't really about asynchronous JavaScript, more about the platform's handling of it's "JavaScript Remoting" calls, when they're sent in parallel. You should be able to see from the diagram that with the "buffer = false" test that the calls are run in parallel. – Todd Halfpenny Jul 20 '16 at 15:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.