12

This question is the extension of How to turn boxcarring OFF for LWC imperative apex method calls?.

While taking into consideration for LWC implementations, that we do not have equivalent of action.setBackground, I discovered that either imperative or wired apex calls are all invoked parallel and separately - this means there is absolutely no boxcarring. I was testing this in dev org which is still in winter 20 release.

Does this mean that salesforce has released an update which removes boxcarring from LWC? I did not find any documentation which says so.


Added the feedback from salesforce core team in answer

11

Feedback from Salesforce core engineering team

Added by @salesforce-sas and updated by @PhilW:

There were major design changes rolled out in Winter '20 affecting the way server calls are made. Everything in LWC are separate parallel calls to the server at the Lightning Data Service (LDS) layer. However, the boxcarring effect kicks in at the Aura Data Service (ADS) layer (currently the intermediary between LDS and the server) when all available parallel XMLHttpRequests (XHRs) from the browser to the server are busy.

Currently all browsers support 6 parallel XHRs as standard. When ADS has started 5 concurrent XHRs, the 6th (last one) boxcars and sends all the remaining server calls queued by the LDS. This is the reason that, although we see only 6 XHRs in browser network tab, we will see individual apex logs per request in the Salesforce Developer Console.

This is not documented because the Salesforce dev team is continuously trying to improve server calls (LDS) and this design/implementation is not the final one. It is doubtful that these design changes will ever be documented.


We haven't seen any changes to boxcarring, at least in the last 6-7 months from when we started looking at this. There are specific details on how LEX and LWC are working that haven't been explained anywhere that I've found which may be affecting what you're seeing.

If you load a page with a large number of components in it that do a lot of different wire or imperative calls you will see that the way the LEX/LWC infrastructure works is:

  1. Up to 5** wire or imperative calls invoked "at the same time" are processed in parallel (@salesforce-sas reports he has seen 6 or more though this isn't something I have seen for "at the same time" calls. He also states that this specific aspect has changed since his testing in July '19. I can't comment as that is around when we started looking into this behaviour)
  2. Further calls starting "at or around the same time" get boxcarred

Here's an example. We have a grid (component). The grid is populated with visual representations of SObjects (component). Each cell (component) in the grid performs its own (here imperative) call to the server to fetch its data then uses that to create the SObject representations. Once completely rendered it looks like this:

final rendering

However, when the grid is first being rendered in the LEX Object Record Page, we see:

how it first looks

You can see that only 5 cells have executed their calls and been rendered; all the other cells are still waiting. Once the waiting has finished, the next thing the user sees is basically the completed picture (first figure, above).

If you look at the network traffic you see the following:

enter image description here

You can see that the first 5 wire/imperative calls are allowed to run in parallel. Once one of these has finished (so there is an available "thread" from the LEX perspective) you then see that almost all the other requests get collected together and run as a single invocation to the server - this is the boxcarring in action.

** It is worth noting that the various browser implementations actually limit the number of "parallel" AJAX calls to the same host. For Chrome it is 6. This may mean you see different behaviour on different browsers. Take a look here for some further details.

To conclude - boxcarring is still there, but if you keep your number of "start at or around the same time" calls to 5 or less no boxcarring will happen. We use this to good effect in some of our other components where we specifically orchestrate our (imperative) calls to the server to do 5 or less at any one time. Other requests get postponed and are started when an existing request completes.

PS: One thing that did change recently - boxcarred requests now correctly each get their own limits. This wasn't the case previously due to a bug in the platform.

8
  • Thanks for your answer. If you are saying that initial calls are not boxcarred, then its definitely a change which is not documented. I have written my detailed testing here. However, I will test by having 10 apex calls and check as you suggested (as I tested with only 2 calls which were sent separately) Jan 31 '20 at 8:29
  • LEX has been allowing up to 5 separate "call threads" for at least 7 months (since we started investigating this) and I believe actually since the beginning. LWC wire/imperative calls have always been using these "call threads" so if nothing else is currently using any "call threads" boxcarring doesn't happen for up to 5 calls. This didn't change with the latest release, nor the one before. Remember - boxcarring only impacts requests that get made at (approximately) the same time. If you separate requests by enough time, boxcarring doesn't happen.
    – Phil W
    Jan 31 '20 at 8:35
  • I tested it now and found what you said is correct except: 1. Not just upto 5 but sometimes 6 or 7 or even 8 transactions are separate and further calls are boxcarred. 2. It has changed from the last time I tested it. I was getting only single network call and single apex log. But it appears this is NOT documented anywhere. Can you please include these points so that I can accept the answer. Thanks! Jan 31 '20 at 8:54
  • @salesforce-sas, I added mention of your points here.
    – Phil W
    Jan 31 '20 at 9:12
  • I also added a link to detail about how different browsers support different numbers of parallel AJAX calls to a given host.
    – Phil W
    Jan 31 '20 at 9:30
3

According to Winter 20(Current release ) notes:

Hitting Apex Limits in Server-Side Actions Is More Predictable

Previously, the Apex limits applied across all the actions batched together (boxcar’ed) in a request (XHR).Apex limits in Lightning components are now applied per action.

it implies that boxcar requests don't share same limits as a single request, it doesn't say that its being removed. No mention of same in Spring 20, so to say, its as-is for some time at least.

https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_lc_predictable_apex_limits.htm?edition=&impact=

1
  • 1
    Thanks for the link - this is what I was talking about in my "PS" at the end of my answer.
    – Phil W
    Jan 31 '20 at 13:06

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.