SiteLog 类别下的文章

升级了 Movable Type 到 3.34

虽然这个新版本发布好几天了,并且宣称 FastCGI 下提高了 N 倍的性能,可是似乎很少有人动手升级,可能是因为海地光缆导致的网络不顺畅,把人也变倦怠了吧。

今天把 MT 升级到了 3.34 版。升级异常顺利。已经 dreamhost 上已经是 fastcgi 模式了,只需如下几个简单步骤:

1) 备份当前的 MT 目录的内容,备份!
2) 解压缩下载到的文件包;
3) cp -R 复制文件过去;
4) 重新登陆。看见有提示就点击,否则就是已经升级完毕; 不放心的话也可以在 Web 上调用 mt-upgrade.cgi 看看;
5) 删除 mt-upgrade.cgi 或者修改一下权限

访问速度快了么? 我怎么觉得还是老样子, 希望速度能稳定些就成。

最近不少 Spam 留言漏网,升级后希望有所改善(应该不会被 Spam 拖得很慢了吧?)

--EOF--

Updated: 在 Dreamhost 上默认支持用 fastcgi, 如果要启用的话参考这个:

http://www.lifewiki.net/sixapart/HostingMTUnderFastCGI

这几天 Blog 的访问量

刚才看了一下后台 Awstats 的访问统计。26、27、28 号这几天天独立访问者平均居然也超过了 4000 ,虽然远远低于正常时的流量,但还是超出我的预期。访问者应该还是大部分来自国内的,看来新闻上所说流量恢复到灾难前的六成还是有些靠谱的。有些用网通的朋友据说访问速度已经不错了。

我在家里用的时杭州 ADSL ,还是不能直接访问国外。刚好这几天比较忙,调整一下节奏倒也不错。最近几个月的生活节奏非常不合理,身体也快吃不消了。

最近新搭建了一套 RHEL 4.3(Intel EM64T) + Oracle 10g Data Guard,安装过程遇到了不少小陷阱。很久没这么折腾了,倒是积攒了一点点经验,闲下来的时候总结一下。

在看一本比较有趣的书,《上学记》。

--EOF--

申请了 Google Apps 服务

看到 Dash 同学说"终于了了心愿,申请Google Apps for Your Domain成功,不由得想笑。原来也有和我一样一次一次反复申请未果的人。参考了这里介绍的方法,总算申请成功了。我之所以一次一次申请,主要还是想把 dbanotes.net 的邮件切换到 Gmail 上。Google Apps 提供的其他服务我倒不是很喜欢用。

到现在为止,用在 dbanotes.net 上的 Google 服务有:

  • Google 站内搜索(站内搜索页面)--似乎使用的人不多。
  • Google Adsense --用来赚钱小钱.聊胜于无,得到一个正反馈.
  • Google Analysis --偶尔使用. 大多数时间还是用 Awstats
  • Google Sitemap --用以提高 Google 收录质量

与之相比, 使用的 Yahoo! 服务有:

  • Flickr -- 偶尔使用
  • del.icio.us -- 不可替代的服务。本地做了一个镜像
  • MyBlogLog -- Yahoo! 最近收购的这个服务很有创新性,我越来越喜欢了。现在使用的频率已经比较高.查看本站的统计信息

有趣的是, Yahoo! 的这三个网络服务都非常容易 Mashup,也都是独立域名。而 Google 则把所有的服务都置于 Google 的子域名下。二者对于资源的整合策略差别非常明显。

--EOF--

CNOUG Planet 改版

距离上一次维护 CNOUG Planet 好久了。这段期间,Planet 经常罢工,虽然这个 RSS 聚合工具在开源软件站点比较流行,可是功能实在受太局限了。分析了最近涌现的其他类似工具,发现都还不如 Lilina 好呢。

AnySQL 楼大侠强烈推荐他 Hack 过的 Lilina 程序(Lilina 源程序 Bug 太多,性能也不太好),并且亲自操刀进行安装定制。效果真的很令人满意。此外,他还修复了关于 Dreamhost 不能显示 Favicon.ico 文件的问题。(我以前回复一个网友的时候还说,这个 favicon.ico 的问题是 Lilina 程序的Bug,不是 Dreamhost 问题,现在为我的愚蠢道歉。)

我和 AnySQL 开玩笑,说他现在是 CNOUG.net 的 CTO 啦,并承诺永久给他的 AUL 工具做广告。

CNOUG Planet 接下来需要进行的修改:

*) 添加"阅读历史"的简单功能 (已经解决);
*) 解决输出的 RSS 文件中的乱码 Bug (已经解决);
*) 添加更多的中文 DBA Blog 信息 (添加中);
*) 更精细的 UI 改进 (基本上差不多了);

力争把这个 CNOUG Planet 变成一个对 DBA/开源爱好者的可靠信息源。

BTW: GreatNews 今天发布了一个新的版本。

--EOF--

Dreamhost 虚拟主机服务最吸引我的卖点无疑是可以有一个登陆的 Shell。这几乎给了你很大的扩展能力。那种靠 FTP 上传文件的场景在现在的 Web 环境下太不适应了。我一般使用 wget 从远程抓文件,因为服务器在国外,从 Sourceforge 下载文件速度飞快。建议准备购买国外虚拟主机服务的朋友,如果不支持 Shell ,那就别考虑了。

关于 Dreamhost 的引荐费的机制可以参考 Oasis Feng 的大作 《详解DreamHost的营销模式》,这个引荐费聊胜于无,颇有些老鼠会的意思,要想通过这个东西来把第二年的费用赚出来也是可能的,不过这可能偏离了你建立这个 Blog 的本意

关于你所在主机的配置,可以通过本站首页的"系统信息"进去参观一下。这个页面用 PHPsysinfo 搭建的。我不确定是否有安全问题,如果有,请了解的朋友通知我一下。

前一段时间做试验,搭建了一个 Wiki(现在已经在后台停掉了),不过要有心理准备,TWiki 这玩意儿实在是不适合放在 Web 上--太消耗资源了,而且,颇受 Spam 的青睐。

有的网友十分关心"一年后怎么办?"之类的问题,拜托,莫尔定律也不过是说说 18 个月,在互联网中,12 个月谁知道会发生怎样的情况?

另:小道消息,CNOUG.net Planet 将在最近改版,希望能加入更多数据库大牛的最新消息。

--EOF--

入住 Dreamhost 一周年小记

一年前的 10 月 12 日,我开始把 Blog 逐步迁移到 Dreamhost 上。关于 Dreamhost 的一个简单介绍参见《站点迁移到了国外》

一年中关于 Blog 的一些数据变化

PV 现在是去年同期的 300%,每月超过 30 万 ;
FeedBurner 显示的订阅数量涨了大约 10 倍,现在是 1200 左右;
从 Dreamhost 得到的引荐费是 $53 (我创建的优惠代码是 FENNG ) ;
现在 dbanotes.net 粗略监控到的可用性大约在 99% ;
当时花费的成本是 $24, 一年后大约 + $80 ;
收益......暂时保密
(我还放置了其他几个域名,就忽略了)

Dreamhost 当时存在的几个问题与现状

1) CPU 使用限制。刚使用的时候 Dreamhost 还有 CPU 使用限制,超出 CPU 使用时间先是警告,然后可能收费。没过多久 Dreamhost 就解决了这个问题。不过所在的虚拟主机上其实还是存在软限制--某个进程占用额外资源会被系统自动 Kill 掉。对于这一点我倒是很理解。毕竟资源是共享的,如果有个别人占用大量资源,对其他人是不公平的。

2) 系统负载偏高。很多人共用主机,肯定会有人的资源占用偏高,即使是无意为之,可能是使用的插件效率不好,或者是遇到了图片盗链什么的。有几次 Awstats 后台的统计数据出不来,非常恼火。后台添加Blog、前台留言也会频繁遇到 HTTP 500 错误。也或许是 Dreamhost 发现了我的苦恼,所以前不久通知我说:

This message is just a quick note to inform you that your account has been moved from topanga to munchies. If you did not request this move, do not fret. It is just part of our efforts to spread load and make your hosting experience more pleasant.

这的确使我很 "pleasant",最近一段时间稳定多了。Dreamhost 做的这个努力使我乖乖的交第二年的钱 :)

关于 Dreamhost 的客户支持与改进
我所能提交的都是电子邮件请求,反馈相对比较及时。而且质量很好。基本上一封邮件就能解决掉问题。
Dreamhost 在虚拟主机的技术方面绝对是不错的,而且,始终能看出来他们的改进努力,对于个人用户来说,用到的软件基本上都可以通过"一键安装"实现(MT 除外)。 我没有用过国外其他的虚拟主机服务,或许别的更好也说不定.

暂时想起来这么多,朋友们想了解些什么我明天继续说.

--EOF--

感受到了一把什么是 15 Minutes of Fame

早些时候,我曾经利用 FeedSky 提供的服务烧录了一个 Feed, 然后把这个地址加到了特色 Blogger 评选中,测试了几天后,发现会存在重复显示 Blog 的问题,就放弃了。

今天收到一封 FeedSky 公司人员的来信:

我们注意到,您似乎选择了使用抓虾的 "合并 Feed"功能,就是如果订阅用户在抓虾里提交了您的参赛 (Feed评选活动 )Feed: http://feed.feedsky.com/fenng ,点击 "订阅 " 后,会自动转换成另一个Feed :http://feeds.feedburner.com/dbanotes ,这样一来,我们就无法正确统计您的参赛 Feed的被订阅数字了(抓虾会将您选择合并到的 Feed地址的订阅数发送给我们,造成统计的混乱),严重的影响了排名的正确性。

看到来信,我跑到评选页面看了一下,晕,居然排到了第八,见下图:


FeedSky 特色 Blogger 评选数据

而实际上,通过 FeedSky 烧录的 Feed 地址订阅的用户应该不超过 15 个。看 FeedSky 的来信,可别被人当作我作弊,如果作弊的话,我直接把重定向到 FeedBurner 的 URL 指向 FeedSky 就可以了,还会取得更好的排名。与 FeedSky 的 Herock 沟通了一下,搞清楚了到底是怎么回事(效率不错)。

抓虾合并了我指向 FeedBurner 的RSS订阅数量与FeedSky的订阅数量(也指向了FeedBurner),返回给 FeedSky 的订阅值就大大的增加--那些没有通过 FeedSky 订阅的用户也统计在内了。这么说起来还是有点绕。

我的案例:
Local RSS --> FeedBurner --> FeedSky --> 抓虾(订阅数)
+
Local RSS --> FeedBurner --> 抓虾(订阅数)
=
FeedSky 得到的订阅总数量(错的数量)

FeedSky 烧录 FeedBurner 的地址的用法虽然有点怪,但我也期望能够正常的看到内容的输出。作为用户,采取这样的用法,应该是无可厚非的。

抓虾的"频道合并"是一个很好的服务,我不知道这个返回的订阅数量是否算抓虾的一个小Bug,还是 FeedSky 程序过滤取值出现了错误。

为了不造成继续的困惑,我已经给抓虾去信请求把 FeedSky 烧录的地址从合并的频道中去掉。

可是,这是谁的错呢?

--EOF--

Updated: 写完这篇 Blog ,看到
1) Herock 在 Gtalk 上的留言,重复显示的问题已经解决了。
2) 收到了抓虾的反馈邮件,统计信息没有问题,但需要把 FeedSky 的地址从中剥离.
3) 对参赛者的一个好消息: FeedSky 决定将这次活动的获奖 blogger 增加到10个。更多的朋友可以来杭州了。

MT Tag Cache 与 Blogroll 的调整

AnySQL 最近在改进 Movable Type 的性能。又有新成果:写了一个 NewSearch.pm 来代替 Search.pm , 并有说明《通过Cache提升MT基于Tag搜索的速度》 , 极力向我推荐,我做小白鼠,测试后发现对于 MT Tag的查看速度的确有很大提升,而且使用简单,无毒无公害. 在此向他的辛勤编码工作表示敬意!

对右边栏的"友情链接"作了一些调整,如果链接 Blog半个月才更新一次,将会放到"更多链接"页。从现在起,尽量做到不做无意义的交换链接(昨天有个朋友联系我,交换链接,点开一看居然是"超女"内容,这和我的 Blog 内容根本不相关). 通过一段时间的观察,发现还是 Blogger 间的引用最有效果。

对于主动链接到我的,通过 egoSurf 脚本, 会自动发现的。 对于关心 PageRank 的 Blogger ,这样也公平一些.

本来的链接途径发现是:Here-->BlogSearch-->BloggersLink2Me
通过这个脚本简化一步:Here-->BloggersLink2Me

Blog 改进,其乐无穷.

--EOF--

1 2 3 4 5 6 7 8 9

关于归档

本页包含 SiteLog 类别下的所有文章.

上一类别为 Security.

Startup 为下一类别.

回到 首页 查看最近发表的文章或者查看所有 归档文章.