[deluge-web] Cache static ressources

Suggestions and discussion of future versions
Post Reply
lildadou
New User
New User
Posts: 5
Joined: Sun Jan 22, 2012 11:49 am

[deluge-web] Cache static ressources

Post by lildadou »

Hello,
I find that the web page of deluge-web is very long to load.
The main reason is that the JavaScript files are downloaded each page opening. As I use nginx in front, I added a rule that queries on static files (ico, css, js, gif, jpg, png) was treated with an additional header who caching response on the client side (Cache-Control).
  • Context : min/max (size)
  • With forced cache rule : 1,97s/2,11s (3,89KB transferred)
  • Without forced cache rule : 13,69s/13,72s (850,99KB transferred)
  • First load (no client-side caching) : 14,72s/15,20s (859,72KB transferred)
My version is 1.3.4-dev (from git repo). Does the cache is used in the final versions?
negge
Member
Member
Posts: 32
Joined: Tue Jul 29, 2008 5:35 am

Re: [deluge-web] Cache static ressources

Post by negge »

Awesome idea. How difficuly is it to set up nginx as a front-end? I've only touched it a few times.
lildadou
New User
New User
Posts: 5
Joined: Sun Jan 22, 2012 11:49 am

Re: [deluge-web] Cache static ressources

Post by lildadou »

Here is a configuration file ready to use:

Code: Select all

server {
	### server port and name ###
	listen				0.0.0.0:80;
	listen				[::]:80;
	server_name			your.domain.net;
	if ($host !~* ^(your.domain.net)$ ) { return 444; } #URL non matché par le domaine
	
	access_log			/var/log/nginx/transmission-proxy.access.log;
	error_log			/var/log/nginx/transmission-proxy.error.log;

	### Compression ###
	gzip				on;
	gzip_static			on;
	gzip_buffers			32 8k;
	gzip_comp_level			3;
	gzip_http_version		1.1;
	gzip_types			text/css text/xml application/x-javascript application/atom+xml text/mathml text/plain t
ext/vnd.sun.j2me.app-descriptor text/vnd.wap.wml text/x-component image/x-ms-bmp image/svg+xml application/msword application/rt
f application/xml application/xhtml+xml application/xml+rss text/javascript application/javascript application/json;
	gzip_vary			on;

	location / {
		proxy_pass		http://localhost:8112/;
		proxy_next_upstream	error timeout invalid_header http_500 http_502 http_503;

		### Set headers ####
		proxy_set_header	Host			$host;
		proxy_set_header	X-Real-IP		$remote_addr;
		proxy_set_header	X-Forwarded-For		$proxy_add_x_forwarded_for;

		### By default we don't want to redirect it ####
		proxy_redirect		off;
	}

	location ~*^.+(ico|css|js|gif|jpe?g|png)$ {
                proxy_pass              http://localhost:8112;
		expires			max;

                proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503;

                ### Set headers ####
                proxy_set_header        Host                    $host;
                proxy_set_header        X-Real-IP               $remote_addr;
                proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;

                ### By default we don't want to redirect it ####
                proxy_redirect          off;
	}
}
negge
Member
Member
Posts: 32
Joined: Tue Jul 29, 2008 5:35 am

Re: [deluge-web] Cache static ressources

Post by negge »

Thanks for the configuration, I'll try taking a look at it. I suppose the proxy could be used by programs like Transdroid as well who just access the JSON-RPC.

Another good optimization would be to smack together all the small icons into a single stripe. It's become pretty common on the web lately, and it does save quite a few requests in this case. I don't really know how to use them together with ExtJS, but surely it is possible.
Cas
Top Bloke
Top Bloke
Posts: 3679
Joined: Mon Dec 07, 2009 6:04 am
Location: Scotland

Re: [deluge-web] Cache static ressources

Post by Cas »

lildadou
New User
New User
Posts: 5
Joined: Sun Jan 22, 2012 11:49 am

Re: [deluge-web] Cache static ressources

Post by lildadou »

negge wrote:Another good optimization would be to smack together all the small icons into a single stripe. It's become pretty common on the web lately, and it does save quite a few requests in this case.
HTTP pipelining may be sufficient?
Post Reply