Speed bursts

[hjone72]

Hi,

Not really an issue but possibly something that could be solved with Nginx.

I've noticed that when using Chrome to stream Plex the speed jumps up and down. If I watch a 10Mbps transcoded movie occasionally I see spikes of bandwidth as high as 16Mbps. Because of these spikes I am forced to reduce my quality to much lower than 10.

Wondering if there might be a way to minimise this?

[toomuchio]

Currently nginx is forwarding everything as soon as it gets it, perhaps a proxy buffer may help....

The problem is the plex clients only request when they reach a certain point instead of something like YouTube which is constantly fetching ahead. Nginx can't really help with that the client needs to request extra data.

Make sure your openssl version is up to date otherwise http2 may not work correctly in Chrome, that could help as well.

openssl version OpenSSL 1.0.2g 1 Mar 2016

[hjone72]

Thanks for the tips. I've only been able to watch the issue on a PC but I suspect it happens on other devices too.

I agree though, it is definitely due to the way the clients request the data.

Do you think a proxy buffer would be beneficial at all?

On Mon., 20 Feb. 2017, 6:25 pm Too Much IO, notifications@github.com wrote:

Currently nginx is forwarding everything as soon as it gets it, perhaps a proxy buffer may help....

The problem is the plex clients only request when they reach a certain point instead of something like YouTube which is constantly fetching ahead. Nginx can't really help with that the client needs to request extra data.

Make sure your openssl version is up to date otherwise http2 may not work correctly in Chrome, that could help as well.

openssl version OpenSSL 1.0.2g 1 Mar 2016

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/toomuchio/plex-nginx-reverseproxy/issues/7#issuecomment-281015520, or mute the thread https://github.com/notifications/unsubscribe-auth/AEJEGyWgIbnB98QP6jdbvp239KZBJwc-ks5reU3kgaJpZM4MF39p .

[toomuchio]

Play around with it, could help but doubtful it really depends were the issue is stemming from.

These should already be set by default in your nginx.conf sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65;

But that can all really help as well, read more about it here > https://t37.net/nginx-optimization-understanding-sendfile-tcp_nodelay-and-tcp_nopush.html

I'll keep this issue open please keep me updated I'm having similar issues sometimes if I'm at a friends house, I'm trying some stuff as well to try and improve it. I host a speedtest on my server as well which helps me eliminate any bad routing/speed issues being the cause.

[toomuchio]

@hjone72 Give it a shot with the latest commits, I saw an improvement. I do have an in country reverse proxy to my reverse proxy to my plex server which is in another country though.

[hjone72]

I plan on testing the changes you suggested above too. Just need to find some time first.

I'm in a similar situation; Plex <- RevProxy <- RevProxy (my country) <- Me

[toomuchio]

I have 128 set on the keepalive in the upstream for my in country reverse proxy at the moment that seems to have helped as well. You also don't need any of the rewrite logic if it's just a reverse proxy to the reverse proxy. You can just have proxy_pass in the location block since the reverse proxy on your actual server will take care of all that.

[hjone72]

I have my keepalive set to 36000 after having an issue where some clients would disconnect while paused.

While I haven't been able to resolve the issue with Plex, I've found that Emby does not have this issue and performs MUCH better.

[toomuchio]

That's a bug with Chrome, Opera doesn't have it though.

[natoriousbigg]

I'm getting speed surge as well. It's not a big problem on most devices but it crashes by Plex client on the Amazon Fire TV. Maybe buffering will help? Anyone has any example of buffering settings?

[toomuchio]

Turning off http2 can help, buffering doesn't help. I haven't had any issues in months with the current config. With http2 off though, and I increased the keep alives.

[hjone72]

@toomuchio, in your production config do you have http2 off? You also mentioned increased keep alives?

[toomuchio]

Yes I turned off http2 and use 256 keep alives.

[hjone72]

Is there a reason you haven't added these changes to the repo? I'm only curious, the work you've done so far has been fantastic! 😄

[toomuchio]

It depends on circumstances as to if disabling http2 will have a negative or positive effect, most of my logic for disabling it in the first place was Netflix doesn't use http2. It's not exactly a solid foundation.

http2 should be faster, the only reason I can think of it being slower is because some ISPs may throttle a single connection which is what http2 does, were as http1.2 can have a number of connections to get page content.

It's not solid or proven conclusion and probably not the same for everybody if it's due to ISP throttling like I think it is, configuration should be seen as a base. You should tweak it for your circumstances.

Same deal with the keep alives, maybe your server can't handle more than the default, maybe you don't need more than 32 or what ever I have set as the default. It's something you need to tweak based on your uplink and server hardware.

If I set it too high people will complain, better to set it to a base level, that should work for everything and let users scale up at their discretion.

[hjone72]

Thanks for the fantastic explanation!

[hjone72]

Do you have a discord or gitter chat to discuss some of these options further? I just don't want to flood your issues page.

For example:

Sendfile The operating system’s sendfile() system call copies data from one file descriptor to another, often achieving zero-copy, which can speed up TCP data transfers. To enable NGINX to use it, include the sendfile directive in the http context or a server or location context. NGINX can then write cached or on-disk content down a socket without any context switching to user space, making the write extremely fast and consuming fewer CPU cycles. Note, however, that because data copied with sendfile() bypasses user space, it is not subject to the regular NGINX processing chain and filters that change content, such as gzip. When a configuration context includes both the sendfile directive and directives that activate a content-changing filter, NGINX automatically disables sendfile for that context.

This suggests to me that enabling gzip for this location context will disable sendfile, is that correct by your reading?

[toomuchio]

I don't at the moment, issue spamming is fine :)

Yes that's correct, it will disable sendfile but only for pages which we gzip which is basically just the Plex app js files and such, our streams are not effected by gzip so sendfile should work fine.

Most people probably use the app via http://app.plex.tv anyway or the respective iOS/Android ect.. app so I doubt the gzip adds much anyway.

[gdob]

I have my keepalive set to 36000 after having an issue where some clients would disconnect while paused.

@hjone72 Did it help? I’m having issues with Chromecast and Roku if I pause the video for longer than 3-4 minutes but only if the video is transcoded or direct streamed, direct play works fine.

[hjone72]

Yeah it did. I'm not sure that I ever had the issue on Roku though. The main place I saw the issue was the chrome browser.

[toomuchio]

@gdob Which keepalive did you change the one in the upstream or the nginx master keep alive?

[gdob]

@toomuchio I tried keepalive_timeout 65; and also tried removing that line completely, but it still drops connections and reconnects.

This is from the Plex Web app (from Safari console warning log):

[object Object]connections is not in PersistentWebStorage
[object Object]skipSignIn is not in PersistentWebStorage
[object Object][Connections] Aborting connection test for test-server at http://plex.test-server.com/ due to mixed content prevention
[object Object][Connections] test-server is unavailable at https://144-xx-xx-xxx.cxxxxxxxxxxxxxxxxxxx8.plex.direct:32400/ (Status 0)
[object Object][Connections] Prevented fallback to insecure connection for test-server
[object Object][MediaServerEventManager] Unexpectedly closed server event connection to test-server
[object Object][Connections] Possible connection error for test-server, retrying connection tests

In Plex Web app > Status > Alerts it shows the following:

1:25 PM Opened connection to test-server, listening for events.
1:25 PM Connection to test-server closed.
1:24 PM Opened connection to test-server, listening for events.
1:23 PM Connection to test-server closed.
1:22 PM Opened connection to test-server, listening for events.
1:22 PM Connection to test-server closed.
1:21 PM Opened connection to test-server, listening for events.
1:21 PM Connection to test-server closed.
1:20 PM Opened connection to test-server, listening for events.
1:20 PM Connection to test-server closed.
1:19 PM Opened connection to test-server, listening for events.

Every minute or so this happens, even if I disable CloudFlare. I suspect this has something to do with Chromecast and Roku being unable to resume after a longer pause…?

[toomuchio]

As far as I'm aware it's a known bug with the Chrome engine. Firefox and Opera (Which is based on Chrome but has fixes) do not have this issue. If setting the keep alive higher fixes it though. I'd do that.

[gdob]

That’s weird because when I try reverting back changes and use port 32400 Chromecast has no problems continuing playback. I mean, it’s not a big problem, but wanted to see if I could find a solution, so far I’m out of luck.

EDIT: keepalive_timeout doesn’t fix the problem unfortunately.

[savahu]

@toomuchio Do you have any links about this issue in the Chrome engine? I fear it's an issue that only exists with our configuration of Plex.

[toomuchio]

Search around you'll find it, it is possible that this configuration is causing the issue but as many times as I've tried to look into it I can't see a cause. Doesn't happen in the browsers I use either.

[savahu]

Perhaps you mean this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=622313

Its' status is 'fixed' unfortunately..

I have increased my upstream keepalive timeout to 36000 to test if that resolves it. Otherwise I'll post logs on the Plex forum and here.

This issue by the way only affects me when using a Chromecast. But maybe I never pause when using Chrome / Plex Web.

[toomuchio]

Perhaps we need to forward https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges header as well.. But it should be set if set via the upstream...

[toomuchio]

Try set proxy_set_header Connection keep-alive; somewhere as well and let me know, I was able to recreate it, but I can't see what could cause it since no other player has the same issue.

[savahu]

Thanks for reproducing the issue, I will add the header and let you know!

[toomuchio]

I've tried a few things kicked up the keep-alive, set a few headers. Nothing works just keep getting NET::ERR_INCOMPLETE_CHUNKED_ENCODING... I'll open a separate issue for this.