从头再来
继续书写windows服务器上的痛苦，最近在尝试部署rails程序到服务器，网上有一篇robbin推荐过的多种rails程序部署方式的评测，但对于windows平台，只有apache+mongrel一个推荐。 然后按照上面的方法写好配置文件，无非是用了个proxy，但启动apache总是失败。到事件查看器里发现错误的提示是“Apache2.2 服务因 1 (0×1) 服务性错误而停止”，和没说一样，啥都看不出来。昨天搞到很晚都没弄明白，今晚继续搞。 突然灵光一闪，意识到日志指向的目录不存在，跑回去新建了目录，一切就好了。网上很难找到有用的信息，写篇blog记下来。
纯粹是闷骚。昨天想把服务器上的apache废掉，全部换上lighttpd，并使用lighttpd+fastcgi来跑php——也可以为以后部署rails扫清障碍。 想得美，昨天晚上熬了一会儿夜，看起来配好了，还像模像样写了一笔。 没想到中午一看，根本打不开。急匆匆地到服务器上看，发现后面的php-cgi进程有一个退出了，所以没法跑。经过我多次试验，换了好几种配置，服务器的php-cgi进程都会在运行一段时间后退出，而且不会重新启动。 竭尽所能去找答案，最后发现在windows上跑lighttpd本来就是不太合适的，好些功能没法用。跑PHP的fastcgi也有着奇怪的毛病。只好灰溜溜地换到apache+fastcgi（原来是apache+mod_php）。系统马上稳定了，开了5个php-cgi进程，最多时用到了3个，响应速度那叫一个快。也证明了之前不是php的问题而是lighttpd的问题。既然用lighttpd+fastcgi失败了，将来部署rails的程序，看来得用apache+mongrel了。 看起来好东西都得用linux或是unix来跑，既然选择了windows ，就挑稳定的来用吧。
以前在Dreamhost的apache日志都是按天保存的，可是我自己在服务器上安装apache之后，发现只能指定固定的日志路径。去网上搜了一下才知道，linux下是用cronolog实现的，正觉得无望时，发现cronolog也有windows版本。 在cronolog.org上可以下载到cronolog的windows版本cronlog.exe，之后随便放到个目录，记下路径。我放到了D盘，路径就是 d:/cronolog.exe 之后打开apache的配置文件，把指定日志路径的那两行改为： ErrorLog “|d:/cronolog.exe d:/logs/error-%Y%m%d.log” CustomLog “|d:/cronolog.exe d:/logs/access-%Y%m%d.log” common 重启apache，这样就可以将日志按天截断。这里%Y指四位数的年份，%m指月份，%d就是日了（这话觉得好别扭）。 这样内存里会长期跑着两个cronolog.exe进程，每个只占了1M多内存。
I kept an eye on apache via the task manager, only to find a apache child process had used 120M RAM. I searched and finally got a solution. Apache in windows often runs 2 procsses , and I just call them parent and child. The parent recieve the requests and dispatch them to the child, [...]
以前都是在Dreamhost放着网站们，不自己维护还真不知道艰难。这次买来服务器，想装Apache+MySQL+PHP就折腾了好半天，愣是没弄好。最后只好下载了Appserv一次把这3个都给装好了，说出来实在挺丢人。 不过后来看很多人说lighttpd响应静态文件很快，虽然在双核的独立服务器上应该还用不着，但我也想尝试一下。现在已经成功了，写一下具体的步骤。 首先来安装和配置lighttpd。通过搜索可以找到windows版本的lighttpd，安装之后，可以在桌面上找到启动lighttpd的快捷方式。建议把它设为启动项或者安装为服务，这样可以每次开机自动运行。 配置方面，既然前端请求用Apache处理，就需要占用80端口。给lighttpd分配别的端口（如8080）就好。 在配置文件里： server.port = 8080 把根目录也设为apache的根目录（可以不这样做，但这样被证明更方便）。 之后就是apache的配置。Apache常规的配置不必说了，绑定在80端口。之后在httpd.conf中启用proxy_module和proxy_http_module （去掉对应行前面的#号）。 然后在文件中这样写： Proxy /css/ http://localhost:8080/css/ ProxyReverse /css/ http://localhost:8080/css/ 其中/css/就表示存放/css/的文件夹下的所有文件，将会被转到http://localhost:8080/css/，由lighttpd处理。同样，可以根据自己的具体情况写成存放图片、js文件的文件夹。这两行是从月光的文章里看来的。 其实也可以使用Rewrite方式来实现，不过通过Rewrite的话实际上是个302转向，并不好。还是通过Proxy 的方式更自然。 还有一种更牛的搭配（当然，现在更用不着），是lighttpd+squid+apache，lighttpd放在最前端负责静态文件，squid作为缓存，如果能在缓存中找到就不需要开动apache。最后再用apache处理那些动态的、不在缓存中的文件。由于niupu将用rails重写，估计将来得用lighttpd+fastcgi了，还得学啊。
从前听说有个叫awstats的东西可以做流量统计，一直以为是一个类似于51啦的独立软件，没想到居然是直接分析apache日志的。这才是王道啊！ 前几天51啦的服务器可能出了些问题，统计的数据不对，于是我换到ITSUN，却发现比51啦还差。后来想想可以试试awstats，于是费了九牛二虎之力装上了。分析日志得到的结果果然详细，连每个搜索引擎用掉的流量都清清楚楚。牛扑现在每天搜索引擎会用掉几百M的流量，而通过浏览器的流量低了一个数量级。牛扑的统计数据在这里，有兴趣的朋友可以看一下。 而在DH后台看到泡吧论坛的流量最近特别大，已经有接近80G，以为都是爬虫惹的祸呢，等popo装好了awstats才发现真正用掉流量的是上面的mp3，统计的那一天用掉了2.3G。在限制流量的服务器上放mp3和电影这种东西是一定要小心的，以前有个朋友超流量超了4T（OMG），就是因为他放了一集越狱在上面。假如放mp3的话，一方面会有人在线听歌或是下载，另一方面会有搜索引擎的爬虫来爬，如果不能带来什么利益的话，还是不要放了。对于论坛，把附件上传限制在200K，再开一个防止盗链效果会很好。 还有一个细节是，不管是通过51啦还是通过ITSUN所做的流量统计，得到的流量都比awstats统计的小了不少，很有可能是有很大部分的浏览器不开js支持，从这就体现出日志分析的好处了。 如果你也有一个有shell权限的主机，不妨试一下awstats。
本来想直接从Google申请删除掉V2Read.cn的收录，但不小心在Google的帮助信息中看到这么一段话： 由于 Google 漫游器依网址来辨别网页，所以您不能自己更改目录里的网址。Google 下次漫游时都会自动更新这些网址。漫游器的行程是自动设定的，我们也没有办法让它提前到达您的网站。 如果您在 Google 漫游后更改了网址，您可以填写网页登录申请表，并按照下列说明删除旧网址。但还是要提醒您，登录的新网址不会马上生效，所以在 Google 下次漫游前的那段时间里，可能无法通过 Google 访问您的网站。 我们建议您要求各网站更新当前指向您的旧网站的链接，使其指向您的新网站，而不要申请更改网址。另外，请不要忘记更改您在 Yahoo! 目录和其它网页目录中的记录。最后，如果您的旧网址使用 HTTP 301（永久）重定向指向您的新网站，Google 漫游时会自动获知新网址，并在六到八周内自动进行更新。 这里说301对定向进行更新在Google需要6到8周，也就是最多要两个月，最少也要一个半月。现在的牛扑在Google收录还是0，看来心急吃不了热豆腐，还得等。要是到时候还不成该怎么办呢？ 同时，关于301定向的实现，有这样的资料可供参考： IIS实现： 打开internet信息服务管理器，在欲重定向的网页或目录上按右键 选择“重定向到URL” 在“重定向到”输入框中输入要跳转到的目标网页的URL地址 选中“资源的永久重定向”（切记） 最后点击“应用” Apache实现： 创建一个.htaccess文件，并将下面提供的代码写入文件内，它可以确保旧域名所有的目录或者网页正确的跳转到新域名内。记住.htaccess文件一定要放在旧网站的根目录下，并且新网站要和旧网站保持相同的目录结构及网页文件 Options +FollowSymLinks RewriteEngine on RewriteRule (.*) http://www.domain.com/$1 [R=301,L] 当然，用PHP/ASP这些也是可以实现的，原理其实简单，只要输出一个301代码的HTTP头就可以。V2Read到牛扑使用的是Apache的重定向，可以把原来的地址“无损”地定向过去。比如http://www.v2read.cn/subject/123/到http://www.niupu.com/subject/123/。但是IIS是做不到的，要实现只能在程序里做，还不一定做得彻底。 还有，blogkid.cn的Alexa排名最近狂飙，昨天到今天涨了3万多名，最近三个月涨了70多万名，现在的Rank在608250。想想再写两年的话，那可能也是一头大牛呢。
我一直用的Ubuntu6.10因为当年分区大小分配的不合理，现在有一个挂载点已经满了。可能由于这个问题，让apt-get也工作不了，看着Alone和popo都装上了7.04，我咬咬牙，把Project ZLLP备份了一下，也开始安装7.04了。 失败了两次，后来总结教训是因为在第5步选择了导入WindowsXP的用户数据。第三次终于好了，然后就是漫长的配置。配置Ubuntu不是一件很爽的事情，而且更大的问题在于每次安装都得重新配置一次。我也尝试果把不同的挂载点挂在不同的分区上，但重装的时候我又很乐意把他们全部干掉。 不管怎样，系统装好了，可以体验一下崭新的Ubuntu7.04。我又顺便装了Apache和php，惊讶地发现都是最新的版本（apache2.23&&php5.2.1）。 现在我可以很快在新的系统上开始工作了，不过折腾到现在也真不容易。 没发现什么bug，感觉字体做得比以前好点了。 PS: 今天V2Read有了第一笔小小的收入。
提示：近期Dreamhost已经更改了他们的主机配置，最新的介绍请看这里。 最近不少朋友们对我们买的服务器感兴趣，所以写篇blog简单说一下。我是3月中旬和Alone，popo，鲶鱼一起在Dreamhost购买的服务器。 我们买的是两年期的L1 Plan，服务器的配置是200G空间（每周增加1G）用于文件和数据库——估计超过了我们所能使用的极限了。还有2T流量（每周增加16G），也支持多种Web程序: PHP（这就不用说了吧），Ruby，JSP，Python等等。提供Shell，可以自己在服务器上做很多事情（实际上，我每天都会登录到服务器上开着shell）。支持CronJob，可以自己在服务器上定时运行程序。 一个服务器可以最多支持75个用户帐号，开通3000个Email帐号（估计这个不大用得到）。会自动进行文件和数据库的备份（可以省不少心）。服务器速度还可以，不过某些地方的朋友们可能会访问起来比较慢。Dreamhost的服务器是放在主干网上的，连接速度的瓶颈应该不在服务器端。我用wget在服务器上下载文件时，最快曾经达到每秒10M。 在服务器上可以不限数量地绑定域名和子域名，也可以开通泛域名的支持，服务器同时支持流媒体技术。更多更详细内容可以看一下这里(英文)。 使用一个多月来，没出过什么问题，速度一直不错。前些日子V2Read上线以后，数据库因为我的不恰当操作慢下来了，那边的技术人员反应很快，帮我更换了数据库服务器。每次发邮件过去基本上能在24小时内得到回复，解决得也相当满意。 更重要的是，这样一台服务器，你只需要20多美金就可以用上一年，没开玩笑。我注册以后顺便建立了一个折扣最大的折扣码”BLOGKID”，可以使所以原本要120$的Plan打折到20多美刀。只需要在注册的时候在”Promo Code or email of who referred you: “填入”BLOGKID“就可以了。我用招商银行的学生卡就可以付款。 如果想一次购买两年，也比较优惠。我们寝室就是这样的。“BLOGKID”优惠码可以省下97$。所以我们4个人一共只花了190.8-97=93.8$。也就是分担到每个人头上只用了180多元就得到了这台服务器两年的使用权。 不过话又说回来，如果网站已经做得比较大，DH的Shared Server毕竟是和别的用户共享着APACHE进程，就不一定适合继续放下去了。
晓光说，V2Read又上不去了。都怪我一时激动，昨天速度恢复时，马上取消了对IP的限制。结果很快就又不行了。头大。 今天有朋友让我用他的服务器放V2Read的程序，可是服务器的Web服务是IIS的，想把V2Read跑在上面还需要费些周折——主要是Rewrite功能没有。而且数据抓取这一块跑在服务器上确实很耗费资源，不知道该怎么解决。 今天开会到很晚，一回来就跑到MT上看了一下Livid租的服务器。档次居中的那一款每年需要$1000，不是一笔小钱。在DH的Shared Server上慢下来的不是Apache，而是Mysql。 SIFE的Project已经要开始启动了 。我还是再给DH发一封信说明下情况吧。ProjectZLLP离完善还有距离，但是这是一个永远都不会完成的Project。 明天的沙龙，不知道效果如何。今天我希望Alone能就数据抓取这一块为主题做一个沙龙，他不愿意做。其实技术这种东西，参与交流的人少一点，大家都能钻得很深入。
You are currently browsing the 张磊的blog weblog archives for 'apache' tag.
Longer entries are truncated. Click the headline of an entry to read it in its entirety.
