bug: playing a video from assets is super slow #2074 #2087
Conversation
|
Im using it so it won't collide with the built in Promise, but as you wish 😀 |
|
Bluebird implements the standard Promise spec so it's completely fine. |
|
I'm using typescript 99% of the time and the type definitions are a bit different and can cause minor conflicts, that is why I'm used to do what I did. Will fix in 2 hours. |
regevbr
force-pushed
the
#2074
branch
2 times, most recently
from
6d65105
to
5e8eaa3
Compare
regevbr
changed the title
|
@NGPixel I rebased the branch so it won't mix commits. Githubs builtin merge with master behavior is not smooth in my opinion, so I do it manually using rebase and force push |
|
@NGPixel I see you already upgraded the |
fix: #2074
Backstory - I uploaded a large 100mb mp4 video as an asset (using postgres as the db) and added an html5 video element to play it in a page. As soon as the page was trying to load, my wiki server just stopped responding for a good few minutes. Cpu was spiking at 100%.
After a lot of investigation, I came to realize that the issue occurs due to a performance bug in the
node-postgresslibrary. I already fixed the bugand waiting for CR on it.and it was released and it is already being used in the master branch.This PR fixes a performance issue while handling videos:
When a request is aborted (due to change of playing position for example) the browser cancels the request, but the error handling in the code ignored it and tried to send the file again from DB which wastes time and causes more issue and the response is already closed.
In addition, I thought about an optimization - instead of fetching assets from db and caching them, the assets might already be cached on the local disk on one of the storage modules (git or disk), so why not use them?
The reason I came up with the optimization is that even after my fix to node-postgres it still takes 40 whole seconds to retrieve the 100mb video file from the DB and it is simply a bad user experience...