SiteLog 类别下的文章

请临时更新本站 RSS 地址

小提示: 部分朋友估计看到的还是旧的站点(或是RSS 没有更新). 本站已经从 Movable Type 平台 迁移到 WordPress 平台。

RSS 地址临时有变动:

http://dbanotes.net/feed

请通过这个地址订阅: http://feeds2.feedburner.com/webarch

如果上述地址无法访问,请使用这个地址(格式可能不那么好): http://dbanotes.net/feed

新启用 http://mt.dbanotes.net 作为旧平台的备份.

--EOF--

Linode VPS 迁移到日本 Tokyo IDC

Tokyo Hot!

今天看到 Linode 针对亚太地区用户的需求新开辟了日本东京机房。价格不变,速度会更快(地理优势),看了网友的反馈也是如此。所以第一时间迁移了过去。

迁移 VPS,需要在后台 Support 处开一个 Ticket ,客服人员会在分钟级别提供响应,提供一个简单的指导,要你关掉 VPS , 点击迁移 , 然后耐心等待。并且会告之你在东京机房的 IP 地址。

这里有一个小技巧:在客服通知你新的 IP 之后,先在后台 DNS Manager 中修改 DNS, 以便减少一些宕机时间,否则 迁移完了还要再等 DNS 生效(另:推荐使用 DNSPod 的服务,谁用谁知道)。因为是跨机房迁移,所以操作系统磁盘镜像文件传输速度并不是特别快,我观察到的速度是 2MB/s 左右。启用新的IP之后,如果你的服务器配置绑定了IP,记得修改一下。

如果 Startup 团队要选择 VPS ,面向国内用户的话,建议选择 Linode 东京的机房就可以,访问速度相当不错。值得一提的是,Linode 前不久推出的 NodeBalancer 也是个很有趣的服务。如果对可用性要求较高,或许可以尝试一下。

每当品评国内云计算公司,我喜欢拿 Linode 说事儿,或许有些人会觉得 Linode 做的是小生意,也有人私下里嘀咕:是不是你只知道 Linode?看看数据吧,事实是:Linode 去年(2010)收入1070万美元。而员工数?只有19人!位列 Inc. 500 名单。这家公司并不是一夜之间冒出来的,2003年就已经成立。如果前几年乱烧钱,早死在沙滩上了。

--EOF--

BTW, 我的 Linode referral code: 92405a6e282a712f7a1270e98d16eba13efb1b68
如果你也准备购买,不妨用一下我的 referral code :)

刚才在我的 Google+ 上发布了一条半开玩笑的信息:DBA Notes 也有 iPhone App 了 ?

DBA Notes 有了 App 了?

其实没那么神奇,借助于这款 iOS App : Bloapp .

安装完这个 App 之后,到其网站上"创建"你的 App,其实主要是一些视觉风格的定义,用它扫描生成的这个 QR Code :

DBANotes_QRCode.png

就可以像一个真的 iOS App 一样阅读我的个人站点的最新文章了。不是每个网站都需要一个 App ,大家需要的只是一个途径。

整个应用设计初看上去并不算复杂,用到的技术大约有 RSS 处理、QR Code 处理,嫁接得很巧妙,也是一个很有意义的应用场景。什么是创新,这就是创新。

--EOF--

使用 Linode 一年小记

去年 11 月中旬,在豆瓣的友情赞助下开始使用 Linode 的服务,到现在为止已经一年多了。有必要和大家分享一下我使用 Linode VPS 的一些感受。

首先说一下 Linode 提供的升级服务,Linode 360 免费升级到了 Linode 512,摩尔定律带来的益处让消费者也能受益,而不是一个定价一成不变(在这里我很鄙视国内的那些垄断企业,相关资费始终高居不下),尽管 Linode 的 VPS 差不多是一个供不应求的状况。另一个变化是 Linode 后台管理工具进行了升级,比以前更为直观清晰。Linode 甚至还有个 iPhone 应用,可以进行一些简单的管理工作。这些对用户来说,都是很受令人欣赏的努力。

这一年来我这个网志站点的可用率终于比以前提升了许多。尽管有过几次较长时间的不可用,那是因为我个人没有及时维护造成的。对于这样规模( Alexa 数据大约 45000 左右)的个人站点来说,每个月 200GB 流量的限制从来没有用光过,磁盘存储空间更是绰绰有余。至于费用问题,初始缴费之后到现在甚至没有继续产生费用,反而赚了一点--引荐(referral)其它用户得到的收益,到现在为止我大致计算了一下,起码有 500 美元的虚拟收入在那里,第二年的费用应该也够了,所以,我又启用了 Linode 的备份服务。对于个人 VPS 消费者来说,通过 referal 的获益降低成本是个很好的模式。也期待如果有朋友看了我的文章觉得有用的话,恰好你又要购买 Linode 的 VPS,不妨使用我的 Refer 代码,于己无损,于人受益。

关于 referral,是一个值得重视的商业方法,能够有效的提升用户的忠诚度。作为创业公司,尤其应该借鉴一下。这或许也是使用相关服务得到的一点收获,不光是使用提供的产品,也稍微研究一下他们的商业手段,这也是一种收获。

Linode 是不是最好的 VPS ?不一定是,但可以肯定的是至少它是一个很不错的 VPS,这就够了。我看到有很多网友整天在各个 VPS 之前迁移来迁移去的,其实,人的时间也是很大的成本,也是要慎重考虑在内的。

尽管一年已经过去了,但是国内仍然没有很值得推荐的 VPS 提供商,或者有不错的,但是我不知道。而一些哭着喊着要做云计算的大公司,甚至连个像样的 VPS 也捣鼓不出来--也或许不屑于做这个?其实 VPS + App 自动部署的模式,潜在的市场应该不小,比如 VPS 上部署一个网店软件,起码会很受电子商务中小企业的欢迎,但很遗憾,目前还看不到这些。

广告:

  • Linode 的 Refer 代码:92405a6e282a712f7a1270e98d16eba13efb1b68 。用了这个代码注册,过几个月据说我可以得到一点好处,就当你做一回雷锋 :)
  • 如果要使用 Dreamhost ,我以前設置的优惠代码:FENNG 依然有效。对于很多在校的学生来说,如果一年只有20多美元的成本,有一个可以部署 Web 应用的环境,还是很不错的。

--EOF--

这是一则只写给国内几百个 Movable Type 用户看的信息。

Movable Type 5 的用户可能会遇到关于留言功能的一个小Bug,系统在用户留言的时候提示留言失败(实际上留言已经成功),"wide character in subroutine entry",搜索后可以参考这则 信息 以及 困扰已久的 MT5 的 bug 解决了,但对于没有使用的 Markdown 插件的用户,这两个地方提到的办法只是给了一个思路。更合适的解决办法是打开 MT 的 Debug 模式,然后提交留言,系统提示信息可以让你发现具体是哪一个脚本出错,这次遇到的是 EncWords.pm 176 行提示错误。

于是,修改该文件,在开头加入:

use Encode qw(encode_utf8);

将 176 行的代码:

encode_base64($str, '');

修改为:

encode_base64(encode_utf8($str), '');

重新提交留言测试。MT 5.01、5.02 与 5.03 测试通过。

说句题外话,Movable Type 日渐式微,国内用户也是越来越少了。如果不是用 Perl 开发,比如用 PHP ,可能现在也未必是 WordPress 的天下。基因决定命运,对某些创业企业来说是这样。

--EOF--

更新:后续的几个版本也有同样的问题,需要手工修改一下。Movable Type 越来越没落了。

Yes! Linode VPS

感谢豆瓣独家提供的两年托管赞助费用!这几天利用空闲时间把 Blog 站点迁移到了 Linode.com 提供的 VPS 上。或许,可以在一段时间内缓解重建页面的性能问题,用户留言的速度也会好很多。

原来站点放在 Dreamhost 上,但是年初的时候频繁遇到 HTTP 500 错误,那段时间,我发布一篇文章都要反复 Build 多次才能成功,很影响积极性。可气的是,Dreamhost 还不断给我发他们的 PS (Private Server) 的折扣信息,一不小心上了贼船,发现上去后反而下不来--不让且回到原来的共享模式下,结果几个月下来花了不少银子。性能,其实也没好到什么地方去。

建议如果 Dreamhost 共享服务器够用,就别升级,也别切换了。毕竟,Dreamhost 的共享主机性价比还是不错的,迁移起来,其实也颇为费事。

我买的是 Linode 360 这个服务整年购买还能优惠 10%,也有优惠代码,不过现在都过期了。购买之后第一个决定是要选择 IDC ,都说旧金山的 Fremont 速度较快,相信大家的,没错。主机用了 Ubuntu ,然后登录进去用 APT (Advanced Packaging Tool) 安装软件或者更新系统,速度那叫一个快啊。早知道这样,再贵一点可能也要买 Linode。在 Dreamhost 上折腾来折腾去的浪费多少精力... 在 Linode 上,如果后续需要更大的内存,随时可以扩容,操作极其方便。 对于CPU 能力、硬盘空间和带宽开销,似乎也很难用到那么多,如果喜欢调试服务器,倒是可以看看怎样能更有效利用内存。对于技术爱好者来说,Linode 是个很好的操作系统玩具。

大家都喊着"云计算",但是面向个人用户这一块的市场需求似乎没有人关注。随着硬件价格的下降,VPS 服务越来越值得个人用户使用,或许,明后年,个人用户也能用上 Amazon 的 AWS 服务了。技术的乐趣在于折腾。

接下来,可以静下心来好好写一阵东西了。

广告:

  • Linode 的 Refer 代码:92405a6e282a712f7a1270e98d16eba13efb1b68 。用了这个代码注册,过几个月据说我可以得到一点好处,就当你做一回雷锋 :)
  • 如果要使用 Dreamhost ,我以前設置的优惠代码:FENNG 依然有效。
  • 另请参见 BlogKid 对 Linode 的介绍

--EOF--

延伸阅读:选择美国主机的机房地理位置与网络分析 http://oncn.net/641228

Updated: Linode 从 2011.09.20 开始提供东京的 IDC,我已经将 VPS 迁移到 Tokyo 了。速度相当不错。

DBA notes 五年

到今天,DBA notes 五年了! 从当年记录的日志看,2003 年 12 月17 日,这个站点"对外正式提供访问"。

前几天浏览 Flickr 上的历史照片,过去的很多场景似乎一下子又跑了出来,今天翻看站点的历史信息,也有这种感觉,那些记忆并没完全消失在时间里,它们还在...

看看还存在旧首页,还有从最开始的那些尽量"符合 Web 标准"的 HTML 页面,站点成立之初完全是用刀耕火种似的手工方式进行更新,直到后来换到了 Movable Type 内容平台。这个过程也是摸索、学习、实践互联网相关技术与文化的过程。从今年开始,Twitter(有 1000 多个 Follower 了) 似乎成了发布微格式内容的一个更直接渠道,不过只需通过简单的集成即可把消息显示在 DBA notes 首页,独立站点仍然是主体,将来可能也不会变化。

一直觉得自己是个不善于坚持的人,从没想过会持续 5 年的时间做一件事情,并且还在不断尝试做一些改进。5 年,1800 多天,在这个站点上发布了 1200 多篇所谓的文章,从开始的 Oracle 数据库的一些小品文,到一些鸡毛蒜皮的个人事情,再到网络评论以及网站架构介绍.....有的时候自己会考虑迎合一下读者的口味,有的时候则完全由着性子写。自己其实不太清楚为什么会一路坚持写下去,可能仅仅像吃饭喝水那样,没有更深层的原因。

上次在广州参加网志年会的时候,居然遇到了一位 4 年前就是我的读者的朋友,多少有点惊讶。5 年,通过在站点上表达的这些东西,认识了很多新朋友,也收到过很多来自他们的反馈以及建议与意见 ... 5 年,已经无法计算究竟为此花费了多少业余时间,不过有一点:我相信付出的那些时间都是有价值的。我付出,也得到了应有的回报。分享知识的过程是最让人快乐的,即使分享的那些东西或许微不足道

回想当初申请域名时,最头疼的就是关于域名购买的网上支付问题,这也使我在考虑加入支付宝的时候无形中投了一票。从北京到杭州,如今也已经将近 4 年,互联网的支付问题已不再是问题,这其中有自己的一份力。或许,人在做某些决定的时候也只是其他某个地方的蝴蝶扇动了一下翅膀。阿里巴巴五年以上的老员工叫做 "5 年陈",会有一枚戒指作为纪念。Blog 五年有什么纪念?

感谢互联网,没有这个神奇的事物可能我不会学到如此多的知识,更不会成为一个技术人! 感谢车东,我在看他的网站的过程中萌生了自己建个站点的想法;感谢 SixApart 提供的 MT ! 当然也要感谢 Larry Wall,因为 MT 是用 Perl 实现的;感谢 Dreamhost 提供的物美价廉的空间! 感谢 鲜果,让我今年 Blog 订阅量暴增。 感谢通过 DBA notes 我所认识的朋友们!

我会继续的...

--EOF--

尤其要感谢从前我的女友--当然,现在已经是我的老婆--感谢她容忍我不陪她逛街或是摄影。

Movable Type 的性能问题

我算得上是 Movable Type 的忠实用户。这两年来,WordPress 快成为 独立 Blog 的标准配置了,MT 可以说每况愈下。自从升级到 MT4 之后,明显感觉 Blog 性能糟糕了很多,每一次发文章都要与 HTTP 500 错误战斗半天才能成功,读者留言也非常费劲,有段时间非常灰心丧气,都不想继续写下去了。如果说 MT 3 之前是与 SPAM 战斗,到了 MT 4 就完全是折腾性能问题了。虽然 MT 4 之后的每次小版本发布都宣称性能上有很大改进,实际表现总是欠佳。

一些常规的 MT 优化技巧 其实作用都不大,我还把 MT 用的数据库索引分析了一遍,删掉了好几个价值不大的索引,虽然不是无用功,但也解决不了问题,因为瓶颈根本不在 DB 这里。大多数 Movable Type 用户的应用场景是在 Dreamhost 上,在这个环境里要想找到应用的瓶颈还真的是个技术活。缺乏 Profiling 工具不说,如果调用某个命令消耗了资源稍微过份一点,立刻被系统 Kill 掉。

其实 MT 的设计思想还是很不错的,大部分页面都 Build 成静态页面,减少对数据库的压力。一般来说,这比 WordPress 频繁调用数据库的方式(当然 WP 是可以起用 Cache 的),应该在性能上有更好的表现才是。问题是 Dreamhost 对每个用户提供的硬件资源其实是很差的,尤其是磁盘 I/O 。我的所有页面加起来也不过几千个,如果只是访问静态页面或是数据库其实问题都不大的,麻烦出现在构建页面或者是遇到留言行为的时候,MT 会调用若干个磁盘上的模版文件,加上 Perl 本身的系统开销,消耗的资源就到了 Dreamhost 的极限,然后进程就被无情的 Kill 掉了。估计是用户群抱怨太多,从 MTOS 4.1.1 版本开始总算有了一个性能框架 专门用以分析性能问题(并且号召用户提供性能数据以便协助解决性能问题)。启用了一段时间后,收集到的 Log 响应时间典型是这样的:

MT::Template::build[Comment Response]=0.60070
MT::App::Comments::run=28.24320
Total=28.85665

或许在 I/O 不错的系统上,表现会好吧。Dreamhost 上文件都是放置在 NFS 上的,而且众多用户共用一个系统,只能将就一下。

今天看到 4.15 的改进中,已经可以 Cache Template Module 了。甘愿作小白鼠,升级。盼望这次能有效解决特定应用场景的性能问题。不过开启了性能 Log 看了半天,效果并非很显著,

后记:

经验证的有效办法之一

通过Cache提升MT基于Tag搜索的速度,只在第一次构建需要的 Tag 时候会占用平时一样的系统资源。再次搜索时,开销大大降低。"抱怨的同时要有解决办法"。

--EOF--

<< 1 2 3 4 5 6 7 8 9

关于归档

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

上一类别为 Security.

Startup 为下一类别.

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