Ubuntu Tweak每天20,000+的使用量每天仍在继续，给我带来很大的压力…最大的压力在于，我没有预料到这个情况，以至于我的Linode的Server的400GB流量，这个月才过了一半，就已经吃掉70%了！
这意味着，未来几天我不采取什么措施的话，要么我关闭服务、要么我募集捐助……这个时候，lfeng把他的Server给了我用，我终于可以先采取比较简易的方式让镜像一下media部分，暂时先把流量导出去。方法很简单：
首先看Server端的流量消耗情况：上下图只差了两天…平均一天5%，也就是20G。
意识到流量将在5天后就被吃光的情况下，我是各种着急啊，幸好lfeng同学主动说要给我Server用，于是我用了Nginx的rewrite把流量导出去了，就这么一行：
rewrite ^/media/(.*)$ http://ubuntu-tweak.lfeng.me$request_uri? redirect;
只要是访问media目录的，我就给他一个302重定向，到架在lfeng的那边的media镜像上去。
可是media的内容是用户上传的，会不断变化，怎么弄简单的弄个同步呢。幸运的是这media还真不是变化特别频繁，所以我用rsync搞了同步，放进cron里去跑：
rsync -avz /path-to-source/media -e ssh user@dest.server:/path-to-dest/ubuntu-tweak/
这样就可以用rsync通过ssh定期把这个Server的内容同步到另一个Server上去了。
一切ready后，我在lfeng提供的Server上观察了十分钟，这时我开启了nginx的access文件记录：
可以看到，10分钟的时间，ubuntu-tweak.com.acccess.log 就有了10,000+条记录，也就是有了10,000个hit，平均每秒16个请求。
这样我原始的Server暂时没有了流量方面的压力，我可以松一口气了。
这个quick and dirty的减轻Server压力的方式显然不是长久之计，我需要对我这个基于Django（uwsgi+nginx）的WebApp做一下profile，然后好好进行优化。
如果大家有什么好的practice，还请指教！
感谢lfeng~
下一篇我会讲讲比较悲剧的客户端的优化经历。
UPDATE@Oct 19
ohsc告诉我302这招一般不是针对静态文件的，想想也是，于是我改了Django项目的settings.py，简单的设置了一下：MEDIA_URL，就不需要在本地的Nginx动手脚了。直接把流量导到了另一个服务器，省了一个302的过程。
转载请注明：爱开源 » 重压下的Ubuntu Tweak服务端的解压方案