Current Downtime/issues

There's a current issue with content not being served correctly. It stemmed from a ZFS related panic on one of the backend servers (note to self - update to the very latest FreeBSD-7-stable code; these are all fixed!) which then came up with lighttpd but no ZFS mounts. Lighttpd then started returning 404's.

I'm now watching the backend(s) throw random connection failures and the Lusca caches then cache an error rather than the object.

I've fixed the backend giving trouble so it won't start up in that failed mode again and I've set the negative caching in the Lusca cache nodes to 30 seconds instead of the default 5 minutes. Hopefully the traffic levels now pick up to where its supposed to be.

EDIT: The problem is again related to the Firefox range requests and Squid/Lusca's inability to cache range request fragments.

The backend failure(s) removed the objects from the cache. The problem now is that the objects aren't re-entering the cache because they are all range requests.

I'm going to wind down the Firefox content serving for now until I get some time to hack up Lusca "enough" to cache the range request objects. I may just do something dodgy with the URL rewriter to force a full object request to occur in the background. Hm, actually..

New mirror node - italy

I've just turned on a new mirror node in Italy thanks to New Media Labs. They've provided some transit services and (I believe) 100mbit access to the local internet exchange.

Thanks guys!

Lusca in Production, #2

Here's some 24 hour statistics from a Lusca-HEAD forward proxy install:

Request rate:

File descriptor count (so clients, servers and disk FDs) :

Byte and Request hit ratio:

Traffic to clients (blue) and from the internet (red):

CPU Utilisation (1.0 is "100% of one core):

Lusca-head pushing >100mbit in production..

Here's the Lusca HEAD install under FreeBSD-7.2 + TPROXY patch. This is a basic configuration with minimal customisation. There's ~ 600gig of data in the cache and there's around 5TB of total disk storage.


You can see when I turned on half of the users, then all of the users. I think there's now around 10,000 active users sitting behind this single Lusca server.

Lusca-head in production with tproxy!

I've deployed Lusca head (the very latest head revision) in production for a client who is using a patched FreeBSD-7.2-STABLE to implement full transparency.

I'm using the patches and ipfw config available at http://tproxy.no-ip.org/ .

The latest Lusca fixes some of the method_t related crashes due to some work done last year in Squid-2.HEAD. It seems quite stable now. The bugs only get tickled with invalid requests - so they show up in production but not with local testing. Hm, I need to "extend" my local testing to include generating a wide variety of errors.

Getting back on track, I've also helped another Lusca user deploy full transparency using the TPROXY4 support in the latest Linux kernel (I believe under Debian-unstable?) He helped me iron out some of the bugs which I've just not seen in my local testing. The important ones (method_t in particular) have been fixed; he's been filing Lusca issues in the google code tracker so I don't forget them. Ah, if all users were as helpful. :)

Anyway. Its nice to see Lusca in production. My customer should be turning it on for their entire satellite link (somewhere between 50 and 100mbit I think) in the next couple of days. I believe the other user has enabled it for 5000 odd users. I'll be asking them both for some statistics to publish once the cache has filled and has been tuned.

Stay tuned for example configurations and tutorials covering how this all works. :)

And the GeoIP summary..

And the geoip summary:

From Sun Jun 7 00:00:00 2009 to Sun Jun 14 00:00:00 2009

Server	Country	MBytes	Requests
	us	5163783.09	6533162
	de	1514664.22	2307222
	ca	1152095.00	917777
	fr	948433.27	1451105
	uk	945640.71	1136455
	it	818161.03	770164
	br	542497.79	1426306
	se	482932.15	229559
	es	445444.34	647321
	pl	397755.30	1021083
	nl	373185.13	306023
	ru	368124.64	749924
	tr	293627.27	484965
	mx	276775.12	463252
	be	249088.62	213460
	ch	201782.33	209530
	ro	190059.45	274216
	fi	172399.75	204630
	ar	170421.77	374071
	no	169351.46	155258

A quick snapshot of Cacheboy destinations..

The following is a snapshot of the per destination AS traffic information I'm keeping.

If you're peering with any of these ASes and are willing to sponsor a cacheboy node or two then please let me know. How well I can scale things at this point is rapidly becoming limited to where I can push traffic from, rather than anything intrinsic to the software.

From Sun Jun 7 00:00:00 2009 to Sun Jun 14 00:00:00 2009

Time	Site	ASN	MBytes	Requests	% of overall
		AS3320	602465.01	1021975	3.26	DTAG Deutsche Telekom AG
		AS7132	583164.05	778259	3.16	SBIS-AS - AT&T Internet Services
		AS19262	459322.30	603127	2.49	VZGNI-TRANSIT - Verizon Internet Services Inc.
		AS3215	330962.95	553299	1.79	AS3215 France Telecom - Orange
		AS3269	317534.06	333114	1.72	ASN-IBSNAZ TELECOM ITALIA
		AS9121	259768.32	434932	1.41	TTNET TTnet Autonomous System
		AS22773	244573.65	283427	1.32	ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc.
		AS12322	224708.25	343686	1.22	PROXAD AS for Proxad/Free ISP
		AS3352	206093.84	305183	1.12	TELEFONICADATA-ESPANA Internet Access Network of TDE
		AS812	204120.74	166633	1.10	ROGERS-CABLE - Rogers Cable Communications Inc.
		AS8151	198918.22	328632	1.08	Uninet S.A. de C.V.
		AS6327	197906.53	152861	1.07	SHAW - Shaw Communications Inc.
		AS3209	191429.18	303787	1.04	ARCOR-AS Arcor IP-Network
		AS20115	182407.09	225151	0.99	CHARTER-NET-HKY-NC - Charter Communications
		AS2119	181719.20	117656	0.98	TELENOR-NEXTEL T.net
		AS577	181167.02	152383	0.98	BACOM - Bell Canada
		AS12874	172973.42	108429	0.94	FASTWEB Fastweb Autonomous System
		AS6389	165445.73	236133	0.90	BELLSOUTH-NET-BLK - BellSouth.net Inc.
		AS6128	165183.07	210300	0.89	CABLE-NET-1 - Cablevision Systems Corp.
		AS2856	164332.96	219267	0.89	BT-UK-AS BTnet UK Regional network

Query content served: 5234195.61 mbytes; 6878234 requests (ie, what was displayed in the table.)

Total content served: 18473721.25 mbytes; 26272660 requests (ie, the total amount of content served over the time period.)