usebruno
WSL Performance Issues
I have checked the following:
- [X] I use the newest version of bruno.
- [X] I've searched existing issues and found nothing related to my issue.
Describe the bug
Using Bruno (installed on Windows) with collections stored in WSL leads to constant hang-ups, and many issues such as not being able to rename files #2269 #2342 , or not being able to send requests altogether since. Other programs work just fine, so it's definitely something with Bruno.
It used to work flawslessly, especially prior to the Gold Edition release. I even paid for it because of how well it ran and how much I liked the idea. I'm starting to regret it.
.bru file to reproduce the bug
No response
Screenshots/Live demo link
An example of the program not allowing me to cancel a request (which had been sent 5 minutes earlier, and took a couple minutes to even be sent in the first place)
https://github.com/usebruno/bruno/assets/46006784/2af33784-2850-4bc2-a0f7-657bee581286
The program not responding:
Since you're mentioning golden edition. Did you try disabling the git Integration Feature? I've observed some performance issues with it being active and having a couple of collections in place. If this improves things this may be a good indicator of the underlying issue.
Since you're mentioning golden edition. Did you try disabling the git Integration Feature? I've observed some performance issues with it being active and having a couple of collections in place. If this improves things this may be a good indicator of the underlying issue.
@krummbar That seems to work. I've also disabled API Spec since I didn't use it, but I'll give this a try. If I don't report back, assume the issues are gone and Git integration is the culprit
It's just a blind guess though. Reporting back would be beneficial in any case. Imho if the Problem is related to git, Performance should bei improved. Specially since it is a payed feature
I suspect that read/write operations on WSL are sometimes kinda slow. This should normally not freeze the UI, but Bruno mostly uses synchronous operations (fs.writeSync) instead of asynchronous (Everything from fs/promises).
I add this to my to-do list and test this the next few days.
I investigated this a bit. I moved a collection with around 30 requests into a WSL folder but didn't notice any freezes. To be sure, I also moved a collection with approximately 2,000 requests into WSL. I only experienced the usual ~5 second lag when interacting with the large collection, but this didn't cause any "window not responding" issues.
Could you share more information about your system?
Also, if you're confident with debugging Electron, you can attach a debugger as described here: Electron Debugging Guide and do a performance recording.
@Its-treason Hi, sure I can. Do you need hardware specs, OS version...? And I could try to debug Electron, although I just came back from holidays and this is for my work machine, so it may take a while before I can take a dig at it 👍🏼
@Its-treason Still a problem in 1.25.0. I even deactivated my Gold license to see if that was part of the issue but to no avail. I'll try a performance recording to see if that helps. I've never worked with Electron but I assume it's just cloning the repo and running it, correct?
Edit: I've a few performance recordings in which the program hung for a few seconds, even getting the (Not responding) message in the title bar. Let me know how to send them to you privately 👍🏼
Hey @BoscoDomingo, thank you for taking the time and doing some performance recordings. You can either message me on Discord: https://discord.com/users/139058134596583424 Or email me [email protected]. I don't have much time today, so will be looking at the recording tomorrow.
Hey @BoscoDomingo, thank you for the recording! I've had a look into your recordings, and it's quite interesting, because it has nothing to do with IO but, it's just the .bru file parser that is really slow.
This was already noted here: https://github.com/usebruno/bruno/issues/2416 and it just seems that parsing files with 1–2 MB in size takes an about ~10 seconds of parsing. Because parsing is done in sync inside the main thread, this also blocks the render thread, resulting in a window not responding message.
What interests me now: How big are your .bru files? There was one outlier in the CPU Profile that took 2 seconds for parsing, so that file should have been around 200 KB - 400 KB in size. If all your files are small (under 10 KB) there is something other that causes the parser to perform even worse. Parsing around 50 files should not take 13 seconds.
@Its-treason Interesting find for sure. I've checked and the largest .bru files in my system are 12KB, so there's definitely something up with the parser:
@Its-treason Any updates on this front?
Not really, it's most likely some weird issue with the parser, I couldn't really figure it out. Anoop announced, that Bruno will move to YAML, which may fix your Problem.
@Its-treason Any updates on this front?
Not really, it's most likely some weird issue with the parser, I couldn't really figure it out. Anoop announced, that Bruno will move to YAML, which may fix your Problem.
Oh nice! Any ideas when that might happen?
@Its-treason Any updates on this front?
Not really, it's most likely some weird issue with the parser, I couldn't really figure it out. Anoop announced, that Bruno will move to YAML, which may fix your Problem.
Oh nice! Any ideas when that might happen?
Anoop said something about this quarter, in the last community call. I hope pretty soon.
We recognized that the performance problem increases with the count of imported collections. It makes WSL almost unsuable having Bruno UI open. On my system the critical mass is at 5 to 8 collections. All of those collections have there bru files located in WSL. So it looks like it is related to WSL filesystem access, as WSL CPU usage also increases. Consumption distribution of the additional CPU usage is about 40% for Bruno UI and 60% for WSL. But I wonder why the CPU usage stays high nevertheless there are no changes in bru files detected.
Recently (version 1.35 IIRC) the problems mentioned in this issue seem to have gone away. I'm pretty sure it may have something to do with #3482 but I'm not certain. Out of precaution I haven't updated since, and it's all worked as expected
Edit: I've updated to 1.38.1 and it's all good still. Also, the latest Chocolatey version is 1.36.1 (even when using --version=1.38.1). Might want to check that
I'm experiencing the same issue. High CPU usage for both Bruno and vmmemWSL on Windows 11 with a collection of 700 requests.
When I move the folder to Desktop from a folder inside my WSL environment Bruno goes down to 0-0.1% and vmmemWSL goes down to 1-2%.
I'm running Bruno 2.1.0.
Exactly the same behavior with version 2.10.0. I'm using a laptop with Windows 11 and WSL 2.5.9 (Ubuntu 24.04).
I open Bruno on Windows and the files are stored in the WSL (\wsl.localhost\Ubuntu\home\user...). I open a collection of ~100 requests. When the collection is opened, Bruno and vmmemWSL use 90% CPU constantly (with the fans waking up...). When I close it, vmmemWSL goes back to ~2% CPU.
Now, I moved my working folder out of the WSL, and I have no more performance issues. 🥇
Any updates on this yet, this is really annoying if you want to change any env vars, bruno becomes unusable tbh
@bramvdh Thanks for reporting this! Could you please test our nightly version at https://github.com/usebruno/bruno-nightly-builds and check if you’re still experiencing the same problem?
@bramvdh Thanks for reporting this! Could you please test our nightly version at https://github.com/usebruno/bruno-nightly-builds and check if you’re still experiencing the same problem?
will give that a try
Hello,
I have the same issue here, when Bruno UI is opened, it burns a lot of CPU related to the init process.
it makes hard to use Bruno in our context and it is not very eco-friendly...
the issue is still present with the lastest nightly build mentioned above
@asanglard Could you please share a video of this? It would be easier to identify the process causing the issue from a video, and the terminal logs could be very helpful as well. The performance fix for the environments modal should be working now.