Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Event Loop blocks while Sending Large Attachments #1321

Open
gamer0mega opened this issue Jan 7, 2022 · 6 comments
Open

Event Loop blocks while Sending Large Attachments #1321

gamer0mega opened this issue Jan 7, 2022 · 6 comments

Comments

@gamer0mega
Copy link

I am having issues with sending large attachments, they simply block the entire event loop until the attachment is sent.
I couldn't find the cause inside the RequestHandler, sending a 4MB video file is enough to block the loop for a few seconds.
Once I returned client in a function and used it in a eval, I had to restart the process just because the output file was never sent and the loop was completely blocked.
I am running eris@0.16.2-dev (git+ssh://git@github.com/abalabahaha/eris.git#1a6e043331aea04de307a71d2e50e9680d1a5ae3)

@DonovanDMC

This comment has been minimized.

@gamer0mega
Copy link
Author

This is bound to happen when you don't have a good network connection, as nodejs is single threaded

But magically, on the exact same VPS, the exact same file doesnt block the event loop while sending out on my upcoming lib

@abalabahaha
Copy link
Owner

This is bound to happen when you don't have a good network connection, as nodejs is single threaded

Irrelevant, threaded I/O is a major selling point of Node.

@gamer0mega can you provide a (somewhat minimal) repro script? Eris shouldn't be using sync APIs for network I/O, so something is being overlooked here.

@gamer0mega
Copy link
Author

gamer0mega commented Jan 9, 2022

This is bound to happen when you don't have a good network connection, as nodejs is single threaded

Irrelevant, threaded I/O is a major selling point of Node.

@gamer0mega can you provide a (somewhat minimal) repro script? Eris shouldn't be using sync APIs for network I/O, so something is being overlooked here.

fs.readFile("video.mp4", ((err, buf) => msg.channel.createMessage("", {file: buf, name: "vid.mp4"})));

You can get the video at https://media.discordapp.net/attachments/795468742670417971/929560222249410642/vid.mp4

Here is a demo: https://media.discordapp.net/attachments/795468742670417971/929560623145173002/Screen_Recording_20220109-052052_Discord-Canary.mp4

@abalabahaha
Copy link
Owner

It seems your issue is that the ping message is delayed until after the file message? That is the ratelimiter system working as designed: requests in one route are sent sequentially, but without blocking the event loop or other routes. Try sending the two messages in different channels (different ratelimit routes), and they shouldn't be blocking each other if there aren't any other bottlenecks.

@gamer0mega
Copy link
Author

It seems your issue is that the ping message is delayed until after the file message? That is the ratelimiter system working as designed: requests in one route are sent sequentially, but without blocking the event loop or other routes. Try sending the two messages in different channels (different ratelimit routes), and they shouldn't be blocking each other if there aren't any other bottlenecks.

There you go, The file is too big so i can show you from other channels. On my main bot i use a fork from DonovanDMC(0.16.0-dev) which i didnt update yet, and sending the exact same spongebob video is almost 3 times slower, I am unsure if thats an issue with the event count or the eris version.
Video: https://media.discordapp.net/attachments/831113546846306324/930093239959191582/Screen_Recording_20220110-163828_Discord-Canary.mp4
Length: https://media.discordapp.net/attachments/795468742670417971/930093753652371496/Screenshot_20220110-164103_Discord-Canary.png

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants