Are msw handlers and application competing for main thread?

[shwarcu]

MSW is fantastic library 🔥
We use it extensively in our testing setup - entire communication with API is mocked with MSW so that we can test our web app in isolation without any dependencies.

This works great when running tests on PCs (like MacBook with M1).

However when running our tests in containers in GitHub actions we noticed that our app slows down significantly and sometimes it takes ridiculous time to load.

Taking a look at network tab I can see that some requests take ridiculous amount of time (still, all requests are mocked with MSW) - like 3, 5 or more seconds.

The app is quite heavy and makes multiple requests on start. Our first though was that we incorrectly implemented msw handlers and they are executing too slowly.

So I run profiler with CPU throttling enabled and saw that handler for request (let's say) /user took few milliseconds but network reports that request was completed in 8 seconds.
That is also confirmed by timelines inside devtools profiler - in flamegraph, block for execution of MSW handler is tiny and block for network request handled by that handler is much more longer and ends later).

Flame chart in profiler is generally filled with our app code execution with smal 'breaks' of MSW handlers execution.

I'm trying to understand what does that mean. My first assumption is that, because main thread is throttled and both app and MSW handlers are executing on main thread, we have situation that they both compete for it.
So when application code is running we can't handle requests immediately because main thread is blocked.

Is this any close to how MSW is working? Or am I totally wrong?
Do you think it's possible to move execution of MSW handlers to web worker so that they are not affected by slow execution of application code?

I would really appreciate some hints how to tackle this problem as it drives me crazy 😅

[kettanaito]

Hi, @shwarcu.

I don't have much share in regard to performance implications caused by MSW internals. But I think what will be helpful is that MSW runs entirely client-side. We use the Service Worker as the interception and response mechanism and that's it. All the request handler declaration, processing, and client/worker communication are handled on the client. Respectively, if something blocks the main thread of your app that will also block the execution of MSW.

However, based on what you've described, that's not what's happening.

My first assumption is that, because main thread is throttled and both app and MSW handlers are executing on main thread, we have situation that they both compete for it.

Can you share some concrete examples of when this occurs? If I'm reading everything you wrote above, MSW doesn't affect the main thread at all (handlers execute quickly, etc).

Do you think it's possible to move execution of MSW handlers to web worker so that they are not affected by slow execution of application code?

I don't believe this would be possible. First, moving the logic to a web worker will imply another client/worker communication channel. That in itself introduces asynchronicity that may have a negative impact on performance aside from unblocking the main thread (things that can be synchronous would now have to be async due to the nature of messages between threads). Secondly, there is very little reason to do so. MSW in itself is not a resource-demanding library. All it does is:

1. Receives outgoing requests from the worker.
2. Runs them through the list of the request handlers you've defined.
3. Finds whichever first handler is producing a mocked response, and sends it back to the worker.

That being said, the lookup algorithm can be vastly improved so its performance is decoupled from the number of handlers you may have in your app.

I would love to hear more information about this issue from you. Maybe there is room for improvement but I need to scope it down first. Thanks.

[shwarcu]

Hi!
Since I wrote here we did more investigation on our testing setup and we concluded that our tests slowdown is not caused by MSW. At least for now, we don't see any drawbacks of using MSW itself, it's really fast. I saw you're interested in quality area so I will tell the rest of the story.

Inside our MSW handlers we used Dexie (indexedDB wrapper) to retrieve and update tests data (to simulate our API behaviour). Calls to indexedDB are asynchronous therefore handlers were asynchronous too.

In normal conditions such handler returns response really fast (milliseconds). That made us initially not consider indexedDB to be the problem.

However during application startup main thread is really busy and asynchronous call to indexedDB are significantly delayed, causing final response to take around 2 and more seconds for multiple requests. These requests were required for application to complete startup. So when our tests run, we have to wait a lot of time for app to be ready for testing.

I might not be 100% correct in explaining what's going on, I'm still learning how to analyse app performance with the profiler. But I think I'm more or less correct.

We're now testing solution based on synchronous in-memory DB and it seems to bring significant improvement, I don't see requests taking so long to be handled anymore. And tests are less flaky.

[kettanaito]

That's interesting. Is there an option to improve the IndexedDB calls themselves? I don't suppose it's normal that they take up to 2 seconds of runtime. Perhaps, some of it could be moved to the testing setup and performed once (no experience with IndexedDB here, so feel free to ignore).

[shwarcu]

I don't know to be honest. I think it's related to how asynchronous actions are handled by JavaScript (indexedDB calls in particular). I think that because in environment when main thread is not occupied I see no significant difference in performance between solution with MSW+IndexedDB (Dexie) and MSW+memoryDB (LokiJS).

Based on observations of network tab and performance profiling, my assumption for now is that when I have asynchronous MSW handlers (because of Dexie/IndexedDB) and I have heavy app running on main thread, then handler execution is spread across the timeline. This leads to request response being handled much later than if handler was synchronous (because synchronous handler would return value immediately, right?).

So at the end I think it's rather how async code works. I see no performance issues with MSW or IndexedDB themselves.

I will close the conversation because I think my case is solved (for now). However, I am always open and happy to talk in other discussions about MSW use cases and testing!