Bandwidth issues + nginx monitoring
I'm a newcomer to Linode (still on my first month) recently transplanted from Dreamhost. I used to run 4 forum sites off a 300 MB RAM VPS there but was getting fed up with the random outages and run-around customer service.
The only nice thing I had there was the "unlimited" bandwidth, which I'm aware is more or less just a marketing gimmick, but at least I never had to worry about it until they thought it was getting out of hand. A couple of my sites have some image galleries but other than that, nothing big like video/audio streaming.
I'm on a Linode 768 package and I'm over 80% of my monthly bandwidth use less than halfway through the month. I noticed that from the graphs (Linode's CP is awesome by the way) early in the month that I was using between 4-6% of my 300 GB a day. I tried to install Munin to better track where this was all going but I was having a lot of trouble getting it to work with nginx. I put my sites on Cloudflare, set cache expires to their max age for most file types, and moved as much of my static files to a friend's server as I possibly could, but my bandwidth usage still seems excessive for the size of my sites.
So in regards to all that, I have a few questions for other members here and would appreciate any input you might have:
-Would you consider Linode's transfer limits on the lower end in comparison to the amount of RAM and disk space you get? I got the 768 package thinking I'd have some room to grow into it, but at this rate I'll probably be about 150GB over my limit for this month and even more as my sites continue to grow.
-Is there a drop in solution for monitoring bandwidth usage on nginx with virtual hosts? The graphs in Linode's CP have spiked up to 10Mbps a few times this month but other than that it usually just hovers between 0.5-2.5Mbps.
-Are there some common pitfalls in regards to excessive bandwidth usage that you think I might have missed?
Thanks for reading and hope to hear from you.
8 Replies
@llamaosama:
I put my sites on Cloudflare, set cache expires to their max age for most file types, and moved as much of my static files to a friend's server as I possibly could, but my bandwidth usage still seems excessive for the size of my sites.
gzipped HTML/CSS/JS output too? (gzip on; in nginx)
I'd assume text heavy forum threads would compress nicely.
jpegoptim and optipng can save you a lot on images files by recompressing them.
If you have say user avatars make sure it's not using a 2mb file then letting the browser resize it down to 80x80px that would be huge waste of bandwidth.
It might seem like a silly thing to limit, but I see people with multi-megabyte animated avatars, and you have a thread with ten 2MB avatars, then 1GB of traffic only gets you 51 pageviews…
I have gzip enabled on nginx, Zlib in PHP off, and gzip disabled on the individual forum scripts. I've read that having compression enabled at multiple points gets you no extra compression, but if you know differently please let me know. Here are my gzip settings in my nginx config:
gzip on;
gzip_http_version 1.1;
gzip_buffers 16 8k;
gzip_comp_level 9;
gzip_min_length 1024;
gzip_proxied any;
gzip_types text/plain text/css application/json application/javascript application/x-javascript text/xml application/xml application/xml+rss text/javascript;
gzip_vary on;
I know most people say level 9 is a waste of CPU but my server typically runs 0.5 - 1.0 load so I don't mind a little extra work on the CPU for just a little bit more saving on bandwidth.
Cloudflare's minifying features are enabled as well. I've compressed nearly all of my static images with smush.it as well as imgopt (which uses various lossless image compressors) Avatars are fairly small on my sites and most users don't have them. There definitely aren't any even close to 2 MB or anything like that.
I'll give awstats a try obs, thanks for the suggestion. Hopefully it's a bit easier than getting munin to work with nginx.
Analog
@llamaosama:
gzip disabled on the individual forum scripts.
But why? That's the bulk of your content since you can't quite cache that, but can set nice client-side cache times for images, js and css.