Skip to content
TORNLIFE More

Advanced Reduced Bandwidth Guide (technical)

Started by Mauk [1494436] on in Questions & Answers.

20 replies · 527 views · thread synced · 5 days ago · View on torn.com
About this thread

Posts archived: 21 / 21 posts (100%) · the total is Torn's reply count + the opening post at the last fetch

Counted by TornLife from the archived posts.

Archived posts
21
Discussion span
→
Authority score
60 / 100
Historical score
32 / 100
Story score
41 / 100
Engagement score
66 / 100

People posting, likes and official posts are not counted for this thread yet: on threads longer than one page they come from a periodic pass over the archive, which has not covered it.

Mentioned in this thread

XOR [743049] ×1 68k [846690] ×1 LouBaker [1162207] ×1 Mauk [1494436] ×1 cyberdude [1613175] ×1

Mauk [1494436]
Update (2014/08/20):

Oh, well.. They are once again caching for only 1 hour. It may have this way for a while, but I haven't noticed it as I haven't been using mobile.

Update (2014/07/19):

For most users, this is no longer needed! :)
Check out my replies below for more info.



Original post:

Hey!

As some of you may have already noticed, RESPO considerably increased bandwidth usage. That'll surely be fixed with time, but there's something we can do in the meantime: set up a forward proxy. Yes, this is meant for the very tech savvy players, unfortunately.

What we'll do is run a web server in our machines as a forward proxy. It'll then add http headers to certain requests - javascript and image files - that instruct the browser to cache the resources. Using this method the average page load will go down from 800kb-2mb to 25kb-60kb, and we can even log in from mobile devices as long as the computer is on! Plus, the smaller pages will mean faster load speeds.

You could use any server for this, but I chose nginx:

1. Download and install it (either from your preferred package manager or the website:http://nginx.org/en/download.html).
2. Find your nginx.conf configuration file: the default places are/usr/local/nginx/conf, /etc/nginx, /usr/local/etc/nginx or in the extracted folder in Windows's case.
3. Substitute it with this file. I also recommend you to read through it. It's a simple configuration to control requests to torn.com.
4. Run nginx. Simply running ./nginx or nginx.exe should do, in most cases. If you need more info, check outthis helpful tutorial.
5. Point your operating system's proxy to localhost:8080. In OS X this is inNetwork Preferences > Advanced > Proxies and in Windows you can find it inInternet Options > Connections > Use a proxy server for your lan.

That's it, from now on your browsers should cache resources and save you bandwidth. If you wish to use this via your mobile phone, configure its proxy server using your computers' external IP.

I should mention that while this saves a lot of bandwidth and gives you a performance boost, you'll still see the blank page for a second sometimes. That's because Torn's javascript files are all included in the page's head, blocking the rendering process. Until Torn's devs change this, I'm afraid we'll keep waiting for the blank page. -- Hey, devs, move them to the body footer! Much appreciated :P

If all of this went over your head, I'm sorry. I wouldn't recommend anyone to run random software from someone over the internet without understanding about the process, anyway.

If you have any problems though, I'm all ears. :)



Ps. If you make modifications to your nginx.conf file after starting nginx, you should runnginx -s reloadto update it.
Mauk [1494436]

Yeah, this is meant as a temporary solution, I even said so in the post.
I'm sure they are already working on that.

With that said, activating gzip and cache headers at least for the static libraries is a fiften-minute fix with research, if even that. And focusing on a responsive site while making over 100 requests per page and without minifying gigantic javascript files is simply non-sense. The fact that it launched like this doesn't get my hopes up-- it seems like a very low-priority aspect of the site for them. Meanwhile I used my monthly mobile data by just taking a look at the new site...
XOR [743049]

Torn does use gzip encoded data.
Torn also uses caching for relative data that may need it. (IE: Versions of JS,CSS).

See screenshot: http://i.imgur.com/LAxQgop.png

Setting up a proxy to repeat what is already being done... is... pointless...
Unless you're planning on using several devices on a network, and you intend of saving overall bandwidth?
Mauk [1494436]
XOR [743049]Torn does use gzip encoded data.
Torn also uses caching for relative data that may need it. (IE: Versions of JS,CSS).

See screenshot: http://i.imgur.com/LAxQgop.png

Setting up a proxy to repeat what is already being done... is... pointless...
Unless you're planning on using several devices on a network, and you intend of saving overall bandwidth?

...I'm not throwing those numbers around. I measured it.
Look carefully: 60 seconds is hardly caching. I really got an immense improvement.

Also, while gzip has nothing to do with saving bandwidth in this case (as you'll have to download them from Torn's servers anyway), they are NOT gzipped from Torn. Look carefully again. Only php files are: js and other text files aren't.

Mentions: XOR [743049]

bounty_hunt [18202]

I do hope the higher ups fix this soon. 1.6 MB per load is ridiculous and takes away a lot from people who have data limits hard set on their plans.
LouBaker [1162207]

heres another test from London just the login page has 12.309s load time, very interesting viewing

http://www.webpagetest.org/result/140628_CZ_F99/1/details/
Mauk [1494436]
LouBaker [1162207]heres another test from London just the login page has 12.309s load time, very interesting viewing

http://www.webpagetest.org/result/140628_CZ_F99/1/details/


That's an eternity.:P

Mentions: LouBaker [1162207]

68k [846690]

Im glad this has been noticed by others, and hope its reduced back to more like it used to be, my data usage is too much now, incurring me unexpected costs. Bummer.
Ohadik [424017] Wiki Contributor

Well I am glad someone else noticed how bad torn has been lagging lately.

For me the faction pages are by far the worst. Takes forever just to get from target to target when making chains because there is a 30-45 second white screen between each page load.
Mauk [1494436]
Tanix [846690]
The OPs work-around is working nicely for me. Thank you!!!


Good to know, Tanix! :)

As long as we're reviving the thread:


Mauk [1494436]The fact that it launched like this doesn't get my hopes up-- it seems like a very low-priority aspect of the site for them.


16 days ago. That's nearly 2gb of bandwidth if you visited Torn 3 times/day with 20 page views/visit. That's one of the bigger (monthly) data plans around here, going entirely to Torn in half a month... Seems like it'll take a while.

Mentions: 68k [846690] · Mauk [1494436]

Mauk [1494436]

I wouldn't call it addressed but it looks like they changed some things: a few files have bumped cache times (just a few though) and they started returning 304 Not Modified forsome requests. It's a bit faster even though I still get around 600kb-1.5mb per page view.


Actually, scratch that. It looks like they are going back-and-forth this as I type this. Perhaps they updated some servers only? Unsure.
Mauk [1494436]

Okay, I just checked it again and have good news, everybody!

They now cache javascript and image files for a week, and have activated gzip for javascript files.
This means the proxy isno longer needed.



More technical info:

While not a far-future caching strategy, one week is a great compromise while they solve minification/request issues. Once they start minifying and concatenating files, it should be easy to far-future cache files given their names would most likely have content-based hashes.

Also, with all js files cached for a week, the number of requests and bandwidth usage went drastically down already, making minification and concatenation less of an issue.. Therefore , they can focus on other things before worrying about optimizing this futher.