岗位职责：
1、按要求独立完成普通网站项目的开发和建设；
2、参与大型电子商务网站项目的整体开发和规划；
3、参与项目系统架构设计，负责系统模块分析和开发；
4、维护网站系统，解决各种相关问题。

任职要求：
1、学历不限，具有扎实的计算机实际操作能力；
2、具有1年以上网站应用程序设计、开发经验；
3、熟练掌握PHP语言，精通Smarty和ZendFramework框架开发技术，精通面向对象技术；
4、熟练掌握Mysql，精通SQL。
4、熟练掌握HTML， JAVASCRIPT、AJAX、XML、DIV+CSS等技术；
5、熟练掌握开发PHP的开发工具，具有优良的编程风格和注释习惯；
6、能独立进行系统二次开发；
7、有大型网站项目的设计和开发经验，具电子商务或ERP、CRM、SCM系统经验者更优；
8、善于与人沟通，具有良好的学习能力和团队合作意识；
9、能够承受较强的工作压力，有极强的工作责任心

工作地点：北京

有意向直接和我联系： dayuer#gmail.com

收录：24万。

一个月以后再看效果。

使用Apache2.2，并发到3000出头就不行了，TIME_WAIT状态5，6千左右；
直接结果就是网站反应减慢，内存消耗剧增，能将16G内存全部耗光直至宕机。

另搭建了一台Nginx，逐步将流量引过来，经过一周的测试运行，并发数量逼近1万，完全解决之前的TIME_WAIT堆积的问题；
网站反应速度没有变化，内存消耗量大约1.2G，load 在3-4左右，对于一台8G内存双4核的服务器来说，毛毛雨。

并发放大也暴露出很多后台程序问题，明显的数据库的压力增加，重压之下，一些隐藏很深的性能问题暴露无遗。

Nginx的确是搭建稳定高效的web server的首选。

没流量，担心
流量狂增，还是担心

没什么时候能省心。

其实刚开始跟毛笔没什么关系，其实我是在修机器，一台在库房里放了快3年的机器。

机器里有重要数据，必须得开起来，通电开机，自检很正常；

经过这么多年，CMOS的电池自然是没了，重设了时间，继续；

开机进入windows2000的启动界面了，好古老的Windows2000，怀旧一下～

在要进入登陆界面的最后一哆嗦，蓝屏，system halt，傻了。

开始怀疑是不是windows哪里出问题了，到处找安装盘，这么古老的安装盘，多难找啊～

终于找到了安装盘，启动，进入了修复界面，然后告诉我不能修复，必须要软盘的紧急安装盘，没招

一狠心一跺脚，把机箱整个拆开，到处都是灰尘，连沙子都有。

又怀疑是不是内存出问题了，然后拔掉了2条内存，再启动，故障依旧

看着手上的内存，发现真是脏透了，一层的土，于是找了只毛笔（毛笔登场了），把内存上的土刷掉

顺便把内存插槽也扫了一遍，抱着死马当活马医的态度，把清理好的内存条重新插回去，开机！

window2000启动了，滚动条到最后了，然后……进入登陆界面了！

我日，成功了……彻底变成了一没技术含量的机器清洁工。

一只毛笔就这么拯救了一台濒临报废的机器。

双四核8G内存的服务器，我习惯性的装了FreeBSD i386版本，用得还可以。

今天检查服务器的时候发现怎么内存只有3G？再仔细核对了配置单，服务器就是8G的啊，我靠。

半天没明白怎么回事。

google了有1小时，想到回去看看FreeBSD的手册，于是看到了AMD64版本，tmd，脑子真短路。

i386是32位架构，压根访问不到8G内存，真是……

服务器已经上架跑了，没法撤回来重装了，tmd，只能等下次再说了

目前遇到的一个网站改造项目，由于历史原因，全站的图片都在放在几个目录下存放，每个目录图片文件数量能达到数十万。

网站流量增加后，明显IO上造成了巨大瓶颈，唯一的办法就是将图片移走，换一个专用的图片域名，然后把图片按Hash值分目录存放，控制每个目录的图片数量在一个合理范围。

不过，这样改造的工程量浩大。

且不说要更改上传图片的程序，图片更换目录后，所有的图片链接地址变化了，意味着有大量的前端页面图片会出错。

这样的改造工期过长，涉及到的开发量过大。

好，现在squid就派上用上了。

目标其实很简单：squid的cache目录管理是hash目录存储的，只要想一个办法把现在的图片文件嫁接到squid的cache里就搞定了。

第一步：建立一个图片专用虚拟主机，映射网站的图片目录。

这台机器的IP假设为 133.33.33.31

比如网站的域名是 www.dayuer.com，用同样的目录新建一个 image.dayuer.com；

注意，在dns里不要把image.dayuer.com指到这台主机，这个主机仅仅是squid访问的而已。

这样，访问 www.dayuer.com/images/xxx.jpg等同于 image.dayuer.com/images/xxx.jpg

第二步：在另外一台服务器装squid，配置成透明反向代理

这台机器的IP假设为 122.22.22.221

具体的步骤google多的是。这台squid是用来代理image.dayuer.com的；

squid的hosts里解析 image.dayuer.com

在dayuer.com的dns服务器里设子域名 image.dayuer.com = 122.22.22.221

如果配置成功，现在访问 image.dayuer.com/images/xxx.jpg就能看到图片了

第三步：前面的工作做好以后，就要把对www.dayuer.com的图片访问转移到image.dayuer.com的访问

OK，现在是关键：

www.dayuer.com的主机配置文件里，增加一个rewrite规则：

Redirect /images http://image.dayuer.com/images

这样，访问www.dayuer.com/images/xxx.jpg的时候，apache会发出一个302转向，去请求 image.dayuer.com/images/xxx.jpg，这个过程在浏览器里看不出来，用户完全不会有感觉。

好了，到现在为止，图片目录就被顺利的嫁接到squid的cache里了。

看起来好像没什么变化

分析一下访问一个图片的请求情况

访问http://www.dayuer.com/images/xxx.jpg

请求到达apache后，根据rewrite规则，会被转到

http://image.dayuer.com/images/xxx.jpg

这时，请求到达squid了，squid检查cache，发现没有缓存，那么去请求原始文件

squid根据hosts的设置，知道image.dayuer.com的真实ip是133.33.33.31,然后把请求发过去

这时，image的虚拟主机接受到请求，返回图片给squid，squid再把图片返回给浏览器

然后浏览器里就出现图片了。

说到这，估计有人不明白，干嘛这么绕一圈，累死人了。

的确是绕了一圈，不过这么一来，原来的程序不用修改了，页面也不用改了，文件目录也不用挪走了，以前的一切该怎样还怎样。

但是，用户访问image的流量，确确实实被转移到了squid，不会再读取本地的图片目录，IO瓶颈没了。

大量的文件按Hash目录结构存放到了squid的cache目录里

一个快被流量压垮的网站，就这么分解了流量，重新又活了，这一切，一句代码都没有改过。

CCTV的大火刚灭，今早上班路上又目睹一场火灾。

现场有N多人围观，大多数人都拿着手机在不停的拍照，录像，我也不例外；

录了没多长，因为那大火烧得浓烟滚滚，一阵阵的黑灰不停的往下掉，所以赶紧走了。

录像位置离大楼就是一墙之隔。

新浪的播客上也有一则，不过是火灭了以后才录的；

草泥马们节节败退

在昨日的最后通牒之下，无数的小站访问不到了～

河蟹总部网站之一的MII的PR已经升到10，无疑是Google的失败，因为这是一个最没有价值的网站

草泥马只能离开草泥马戈壁，迁到遥远的美利坚，生根发芽。

也许过不了多久，海底光缆就会再次意外中断，再也无法恢复，那些远离的草泥马即使翻墙也看不到了

谁才是这个戈壁的主人，草泥马Or河蟹？

成王败寇，历史总是如此

能让你偏安一隅的活着，就是最大的自由了

卧槽草泥马，悲从心起。

这到底是一个什么样的时代～

莫名其妙的问题，在某机房的一台Server，PHP写的ftp代码不能登录其FTP，不管windows还是BSD；

错误信息都一样

PUT > SYST
systype: Read failed (Connection reset by peer)
GET <
Can’t detect remote OS

不能登录。

但是，用FTP软件却可以顺利的登录；

奇怪的事情就是，同样的代码，去登录别的FTP却一点问题都没有

据说此机房装了防火墙，难道有这原因？没道理软件能登录，PHP的代码都不能登录。

折腾得没法，最后改成用Snoopy，把文件Post上去，在Server放一个php来接收，总算可以把文件自动传上去了

第一次遇到此奇怪问题，不得其解。