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

downloads slow and not caching at all #31

Closed
dark-swordsman opened this issue May 12, 2019 · 4 comments
Closed

downloads slow and not caching at all #31

dark-swordsman opened this issue May 12, 2019 · 4 comments
Labels
inactive Issue appears to be inactive

Comments

@dark-swordsman
Copy link

dark-swordsman commented May 12, 2019

Describe the issue you are having

I set the DNS on the gaming PC to our test server 10.1.0.135. Downloading CS:GO, I see the network traffic go through the lancache. Initally, it was hitting 15-20 MB/s, but now after fiddling with a few things, it's down to 4-6 MB/s.

Even though it's downloading through the lancache, the disk usage doesn't increase at all. Even after downloading the game completey and deleting from the gaming PC, it seems to re-download through the cache, but again, not actually cache.

How are you running the container(s)?

This is the bash script that I made and run as sudo:

#!/bin/bash

echo stopping old container: steamcache-dns
docker stop steamcache-dns
echo stopping old container: lancache
docker stop lancache
echo stopping old container: sniproxy
docker stop sniproxy
echo deleting old container: steamcache-dns
docker rm steamcache-dns
echo deleting old container: lancache
docker rm lancache
echo deleting old container: sniproxy
docker rm sniproxy

HOST_IP=`hostname -I | cut -d' ' -f1`
echo set HOST_IP to: $HOST_IP

MEM_SIZE=4000m
DISK_SIZE=180g

echo starting: steamcache-dns
docker run --restart unless-stopped --name steamcache-dns --detach -p 53:53/udp -e USE_GENERIC_CACHE=true -e LA$
echo starting: lancache
echo LANCACHE MEMORY SIZE: $MEM_SIZE
echo LANCACHE DISK SIZE: $DISK_SIZE
docker run --restart unless-stopped --name lancache --detach -e CACHE_MEM_SIZE=$MEM_SIZE -e CACHE_DISK_SIZE=$DI$
echo starting: sniproxy
docker run --restart unless-stopped --name sniproxy --detach -p 443:443 steamcache/sniproxy:latest

echo Please configure your dhcp server to serve dns as $HOST_IP

DNS Configuration

In the script above, this is how it's executed.

docker run --restart unless-stopped --name steamcache-dns --detach -p 53:53/udp -e USE_GENERIC_CACHE=true -e LA$

Output of container(s)

Output of the script I execute.

monolithic@monlithic:~$ sudo ./mono.sh
stopping old container: steamcache-dns
steamcache-dns
stopping old container: lancache
lancache
stopping old container: sniproxy
sniproxy
deleting old container: steamcache-dns
steamcache-dns
deleting old container: lancache
lancache
deleting old container: sniproxy
sniproxy
set HOST_IP to: 10.1.0.135
starting: steamcache-dns
268ba04fd222826ae12f8613e492b66b66042a6fdafb20bf17347eda52f5b74b
starting: lancache
LANCACHE MEMORY SIZE: 4000m
LANCACHE DISK SIZE: 180g
9ca10605d5b7fa2aba7b904eff444f03463f71b765eccb26d6b0b80a0837a960
starting: sniproxy
aedc8b894ec5ee648d04d122ff3069c9f8c34963b21bf5e96fd927635b78a9d8
Please configure your dhcp server to serve dns as 10.1.0.135

Also, I am curious. Would deleting the old containers get rid of the data on the lancache?

I was doing that because even though the commands to start the servers are docker restart, it yells at me that the containers already exist.

@dark-swordsman
Copy link
Author

Update: I was able to peek into the lancache container and found this in the access logs. Nothing in error logs though:

[steam] 10.1.10.95 / - - - [12/May/2019:19:47:18 +0000] "GET /appinfo/386180/sha/b6955b222073aebf540f2c6f06e7bfc52bc2c4fd.txt.gz HTTP/1.1" 200 1395 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:19:50:07 +0000] "GET /appinfo/774941/sha/7067136a414b61ff0e2eaf1b5ad5b83a2bcd226d.txt.gz HTTP/1.1" 200 1498 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:19:50:07 +0000] "GET /client/steam_client_win32 HTTP/1.1" 302 0 "-" "Valve/Steam HTTP Client 1.0 (client;windows;16;1556574584)" "MISS" "client-download.steampowered.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:16:50 +0000] "GET /appinfo/236430/sha/8d5e752c835a1eb755a9532a2fed7ea362fa728c.txt.gz HTTP/1.1" 200 4073 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:20:07 +0000] "GET /appinfo/700580/sha/f6cbce3521f0b5797144789321f149c56369aefd.txt.gz HTTP/1.1" 200 1592 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:20:07 +0000] "GET /appinfo/629760/sha/777f6ba0ed046ef1709bf9a18323b69e2fbca732.txt.gz HTTP/1.1" 200 1472 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:20:07 +0000] "GET /appinfo/349700/sha/f295164c5aeefe165f8398a7c8037402e638c46c.txt.gz HTTP/1.1" 200 1062 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:20:07 +0000] "GET /appinfo/105600/sha/f74fca57aa94e07b5abc155b1b62da0d81effc80.txt.gz HTTP/1.1" 200 2819 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:20:07 +0000] "GET /appinfo/620980/sha/e71a988b064f08f5a22d7ace5c181b2bdf176f42.txt.gz HTTP/1.1" 200 1577 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:20:35:07 +0000] "GET /appinfo/774941/sha/6d02f5ad7fdeb9565389f6faa7325879e9037681.txt.gz HTTP/1.1" 200 1498 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"
[steam] 10.1.10.95 / - - - [12/May/2019:21:05:14 +0000] "GET /appinfo/431240/sha/99ac9a7fbc4788f752d3d141cdf13afb9858a2b3.txt.gz HTTP/1.1" 200 2498 "-" "Valve/Steam HTTP Client 1.0" "MISS" "clientconfig.akamai.steamstatic.com" "-"

@dark-swordsman
Copy link
Author

Update:
I used top to watch processes on the server. Downloading CS:GO, sniproxy hits about 6-8% cpu usage. Just tried with Black Ops on Blizzard and nginx was hitting 25-30% CPU across two processes.

Deleted the 2 GB of black ops from my system, reinstalled, nginx ramped up again, and the server was downloading 80 Mbps, but uploading 150-200 Mbps.

Also, the file usage on root went from 2.6G to 4.4G. This tells me that it was pulling from the cache and that it may be another steam HTTPS issue, like the one you guys had a little while ago.

Any tips to check or prod steam to try to use HTTP?

@dark-swordsman
Copy link
Author

dark-swordsman commented May 13, 2019

Update:
I was able to employ the fix found here: lancachenet/lancache-dns#47 (comment)

I edited /etc/sniproxy.conf by peeking into the docker container and was able to start caching steam games. There is still a bit of an issue though:

When it initially starts, the sniproxy process hits 100% CPU usage for a solid 15-20 seconds without downloading anything. After that, it passes it off to nginx and starts downloading, but at a measly 3-4 MB/s.

I also found that BLOPS 4 (Blizzard) only downloads at about 10-12 MB/s when it's caching it, which is okay, but on the bntjah/lancache I was able to consistently achieve 50-70 MB/s while caching (when it worked). It does appear to be a lancache thing as I'm able to stay at 10 MB/s with BLOPS 4 while CS:GO starts and hits 3-4 MB/s.

Either way, while I'll keep this issue open to hopefully improve this sni issue and performance overall, it caches all data and pulls from the cache at 40-60 MB/s at the very least, which is a huge step up from before.

Oh, also. I noticed that I wasn't able to start steamcache-dns because Ubuntu's systemd-resolved.service was using port 53. I was able to disable that and the dns works fine, however, I was unable to, by all my power, get a restart/start script to run at boot, and I'm wondering if it has to do with referencing the docker command and the #! reference in the file. It seems to be a broadly answered topic across the internet with no clear solution.

I was recommended to make this Ubuntu 18.04 instance a docker image itself, but I am worried about using the dns on the docker image and redirecting the traffic to the image, as well as the fact that we would still need to setup the netplan yml to a static IP and what not.

Edit: To clarify, I believe it actually was hitting 100% CPU on one thread. That explains why other processes were still at 5-15% while that was happening. VMWare reported only 25% usage:

image

@unspec unspec added the inactive Issue appears to be inactive label Feb 22, 2020
@VibroAxe
Copy link
Member

This is an issue with comcast mandating SSL, the new lancache.steamcontent.com domain should resolve this, see #85

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

No branches or pull requests

3 participants