Web 类别下的文章

闲谈 Web 图片服务器

现在很多中小网站(尤其是 Web 2.0 站点) 都允许用户上传图片,如果前期没有很好的规划,那么随着图片文件的增多,无论是管理还是性能上都带来很多问题。就自己的一点理解,抛砖引玉,以期能引出更具价值的信息。

事关图片的存储

把图片存储到什么介质上? 如果有足够的资金购买专用的图片服务器硬件或者 NAS 设备,那么简单的很;如果有能力自己开发单独存储图片的文件系统,那么也不用接着往下看了。

如果上述条件不具备,只想在普通的硬盘上存储,首先还是要考虑一下物理硬盘的实际处理能力。是 7200 转的还是 15000 转的,实际表现差别就很大。是选择 ReiserFS 还是 Ext3 ,怎么也要测试一下吧? 创建文件系统的时候 Inode 问题也要加以考虑,选择合适大小的 inode size ,在空间和速度上做取舍,同时防患于未然,注意单个文件系统下文件个数别达到极限。

独立,独立的服务器

无论从管理上,还是从性能上看,只要有可能,尽量部署独立的图片服务器。这几乎成为常识了(不过在我做过面向 Web 的项目之前就这个问题也被人笑话过)。具备独立的图片服务器或者服务器集群后,在 Web 服务器上就可以有针对性的进行配置优化。比如采用传说中更有效率的 Lighttpd

如果不想在几台机器间同步所有图片,只用 NFS 模式共享一下即可。注意软、硬连接可能带来的问题,以及 NFS 特定的传输速度。

独立,独立的域名

如果大部分 Web 页面必须要载入很多图片,那么需要注意 IE 浏览器的连接数问题(参见对该问题的测试)。

前几天有个朋友在线上问我,"一些大网站,图片服务器为什么都用另外一个域名? 比如yahoo.com 图片服务器用了 yimg.com 的域名?" ,粗糙一点的答案:除了管理方便,便于CDN 同步处理,上面说的 IE 连接数限制也是个考虑因素吧(其他原因我也不知,有请 Yahoo!的同学发言) 【还有一个我没考虑到的是 Cookie 的因素,参加楼下高春辉的留言】

雅虎 Web 优化 14 条

关于雅虎 YSlow 工具倡导的 优化 14 条规则,建议每个 Web 维护人员必须倒背如流,当然也应该辩证来看--介绍这 14 条规则的页面本身也只能得到 70 多分...其中的第九条和上面说的独立域名之间多少有些矛盾。实际情况要根据自己的 Benchmark 与具体需求而确定了。

有效利用客户端 Cache

很多网站的 UI 设计人员为了达到某些视觉效果,会在一些用户需要频繁访问的页面模块上应用大量的图片。这样的情况,研究表明,对于用户粘度比较高的站点, 在Web 服务器上对这一类对象设置 Expires Header 就是十分有必要的,大量带宽就这么节省下来,费用也节省了下来。顺便说一下,对于验证码这样的东西,要加个简单的规则过滤掉。

服务器端的 Cache

在国内,CDN 也是有钱才能玩得起。而类似 Amazon S3 这样的一揽子存储服务,国内还没有出现。所以,充分利用服务器端的 Cache 也是有必要的。Squid 作为反向代理服务器,缓冲图片效果应该说尚可,新浪技术团队贡献的 Ncache 据评测,效果更佳。

服务器端做Cache的好处是显而易见的,一个数据对象的请求时间会控制在 100ms 以内,否则的话,至少要几百个 ms 甚至更长。

高解析图片问题

如果网站存在大量高解析度的图片,那么有必要考虑部署 IIPImage 或者类似的软件。

运营问题

很多比较有规模的网站对于用户上传的图片不做任何处理,结果页面上还能看到很多 BMP 格式的图片(个人觉得任何网站出现 BMP 格式的图片都是可耻的)...这完全是运营上的策略之误了。找个程序员投入一点时间写个图片处理模块,对那些"截屏"得来的图片做个转换,投入成本可能远比存储上的开销小,而用户再访问该图片,质量未必能有什么损失,浏览速度无疑好多了。哪种处理方式更让人接受,不言而喻。

--EOF--

图片处理工具的选择

可能大多数网站都是选择 ImageMagick 做为基础库,不过这里也有一篇 GraphicsMagick 1.2 vs ImageMagick 6.3.6 Benchmark Report,如果图片处理量巨大,性能问题又怎能不考虑?

Lighttpd 的 ModCache 模块非常值得推荐。

Updated: 对于创业团队来说,推荐又拍云服务,用了都说好。

域名 Transfer 的经过

前天终于收到一封邮件:

Domain Registration Transfer COMPLETED for dbanotes.net

在经历过几个月断断续续的折腾之后,这个域名终于 Transfer 到国外。有好几次真忍不住想骂人。整个过程曲折复杂,如果你有耐心看流水帐,我就继续。

第一回合

大约去年 11 月份,域名要到期了,我突然有了要把国内注册的这个域名 Transfer 到国外的念头(原因)。如何 Transfer ,我自己不太清楚的,搜索了一下,大致知道需要先拿到域名的密码(Authcode),然后还需要当前的注册商解锁。

我这个域名,之前为了省钱,续费的时候是转到了代理商下面的。于是联系了代理商,代理商告诉我"寄资料给注册商索取转移密码",然后我联系注册商,注册商告诉我域名要到期了是不能 Transfer 走的,必须先续费,确保不欠费了才可以。

联系代理商,续费。接着打电话给注册商,他们告诉我到什么地方下载表格(传真件还不可以,必须是手写的原件),然后告诉我必须要代理商盖章才可以。再联系代理商,再次告诉我不需要盖代理的公章。我被打败,第一回合结束。

第二回合

我这个人有个毛病,越惹我恶心的事情,我越要搞定它。忙过了几天之后,又想起来这事情。再次联系代理商,一听我要转走,根本都不愿意理我。我说要不你把"域名转到非代理管理"的状态下吧,这样我就不需要你的公章了。过了一会儿,代理商告诉我,"解锁了,以后不要再来烦我了"(原来代理商下面还有一道锁的)。

打电话给注册商,告诉我现在"还在代理商管理"下,吐啊吐,我说那边都给我解锁了啊,"那你在我们的网站有账户么? 你需要用账户把这个域名管理起来,也就是'转进来'--要多交一年的注册费用..." 吐,多续费一年...100 多人民币又花出去了.

第三回合

几天后,我继续折腾。这次你总要让我转移了吧? 下载并填写好了相关表格,快递过去,接着打电话问注册商。告诉我"你是刚续费的,至少要等 45 天才可以转移的",我怒之,你大爷的,你这是 Catch 22 啊? 注册商客服象弹簧,你弱他就强,你强他自然就软了。告诉我"要写个免责声明, 这段时间如果转移出问题,责任自负"。我写...注册商大爷,你就给我密码吧!

第四回合

话说,终于拿到了域名密码。喜不自胜,心说这下子总算可以转移了,时光如水,岁月如梭啊,不知不觉就快到春节了。赶在春节前在 Dreamhost 上填好了 Transfer 申请,几天后终于收到了 Dreamhost 发来的邮件:

Domain registration transfer for dbanotes.net has been rejected by your current registrar!

这个气啊, 发邮件问注册商客服,到底咋回事? 那边信誓旦旦的说 "已经给你解锁了呀,重新试试看", 我重新试试看,眼看着雪灾日益严重,我终于把这个事情暂时忘了。年都过完了,又一次失败。如是者多次,我只能认为是我 RPWT 了。期间用我的洋汀浜英文与 Dreamhost 客服沟通了几次,不赘述。

第五回合

放假归来,再发邮件问,给我回复说,密码和域名状态都是对的。"那为什么总被拒绝呢? 这很明显就是你们不让我转出嘛!" ,你强它就弱,这真是真理。再次尝试,终于(不拒绝了),终于,终于,收到了转移成功的确认邮件。

--EOF--

不要在国内注册域名

最近一次域名转移的经历实在把我恶心透了。如果有可能,千万不要再在国内注册域名了。

1) 费用贵! 在国内注册一个域名起码要 100 多 RMB,国外很多注册商都不超过 10 美元,现在人民币升值,美元贬值呢,而且大多都有折扣代码,还要更便宜。国内如果通过代理走,有的时候是能便宜一点的。但是有后顾之忧--我在后面会写出来. 有得朋友因为没有信用卡而不能境外支付,那就办理一个好啦,现在信用卡发放就和卖白菜差不多。

2) 服务差 先是技术服务差,对比一下国外的域名服务,国内的限制非常多。管理面板里的功能少的可怜。其次是售后服务差,经常在规则里下拌儿。很多域名注册商都没有正规的呼叫中心,电话经常打不通,打通了等半天,好不容易和人接上话后,敷衍你几句了事。

3) 不安全 去年国内的几个域名注册商就出过好几次技术故障,还有些朋友时不时的域名被劫持一下。另外,国内的"非理性"因素太多,说不上什么时候你的域名可能被强制停掉也说不定。

虽然之前,我曾经推荐过几位朋友在国内注册算了,"省事",现在看起来,我错了。

--EOF--

BlogDay 2007

FeedBurner 已死,Feedsky 当立! 现在广大 Blogger 们除了呼吸稍有不畅之外,还能忍耐。

昨天 (8 月31) 日是 BlogDay,晚上匆忙扫了几眼 Google Reader ,很多朋友都响应了这个活动。06 年 Blog Day 我也参加过,今天马后炮一下补充一篇。

我推荐的几个 Blog:

Livid's Paranoid
url: http://www.livid.cn/
网络上对于 Livid 有很多并不过分的夸奖。他前一段时间关于 "个人数据中心" 的想法很具有战略性。Livid 与 Flypig 两个人是 "80 后靠谱" 的有力证明。

大徐
url: http://daxu.net/
大徐在雅虎工作。我非常喜欢他的 Blog 写作风格。大徐是个热爱生活的程序员

DBA story
url: http://www.ixdba.com/
DBA 为题材的 Blog 有好几个了,Piner 这个虽然出现的比较晚,但也相对有更多的技术信息,不像我的 Blog 兑了那么多水。 最近他开始走怀旧路线和亲情路线了,也耐看,我只是担心他的写作热情是否会持续下去。所以在这里推荐一下.

插一腿的薄壳
url: http://www.bullog.cn/blogs/cyt/
插一腿是个半职业赌士。从这里我了解了关于赌徒的很多有趣生活。他的那部小说妙趣横生。

Taobao UED
url: http://ued.taobao.com/blog/
淘宝用户界面设计团队的 Blog。我喜欢看其中的 UI / UE 内容,其他文章也没有写成散文诗,所以是值得看看的,也是传达淘宝文化的一个窗口。

Tag BlogDay 一下。另外就不一一留言通知了,如果这些 Blogger 能看到,他们就能看到。不能看到,我留言作用也不大。

Blogger 来,Blogger 走,而 Blog 永存。

FeedBurner 已死,FeedBurner 万岁!

--EOF--

偶然间发现鲜果http 301 重定向 的识别也不够好,我本地的 RSS 文件是存在的,同时把 Feed 地址持久重定向(HTTP 301)到 FeedBurner 烧录的 Feed 地址。如果在线 RSS 阅读工具不能有效识别 HTTP 301 ,就会给我以及有类似情况的 Blogger带来的一个问题:订阅数不能汇总到一起。在鲜果的频道列表里看到我自己的 Blog 频道占了好几个,每个订阅数量都是不一样的。当然,最多的还是 FeedBurner 的这个。我给鲜果去邮件询问,他们很快回复告诉我可以"合并FEED地址",这可能是手工来做。

这一点,抓虾已经领先一步做到了。我记得抓虾最早对这个问题也不够重视,对于有疑问的用户当初的解决办法似乎也是用手工的方式汇总统计订阅数字。Google Reader 应该是没有问题的。至于其他的站点 FastLadder 目前似乎对该问题还没有重视。而 Bloglines 虽然最近推出了新的测试版,可总闹水管子工,没怎么细看,印象中倒是不支持的。

在这篇关于 RSS Feed 状态的文章中阅读器端对 只是建议支持。我倒是建议所有 RSS 工具的网站必须提供对 HTTP 301 的有效识别。Blogger 也可以把这一条用来评测 RSS 阅读工具。

支持 301 的另外一个好处是能够有效统计唯一订阅用户数。而订阅用户数对于 Blogger 来说,是比较重要的一个 Blogger 指标。提供准确、漂亮的订阅统计,虽说只是提高 Blogger 用户体验的一个小功能,但是很关键。

--EOF--

AWStats 6.7 正式版发布

邮件列表里看到的消息。AWStats 6.7 正式版发布了。新特性/改进列表:

- Full support for -day option. To build different report for each day
- Added virtualenamequot tag
- Added option NotPageList
- Addes .jobs and .mobi domains

对于第一条,按日构建报告其实从 6.5 版本以后就提供了相关功能。6.7 版本说是 "Full Support",没看明白怎么个 "Full"。更多内容可以参考车东的AWStats的千万级日志解决方案

--EOF--

MT 4 Beta 版经验

今天将 dbanotes.net 所用的 Movable Type 从 Beta 2 升级到了 Beta 5 测试了一下,遇到了大小毛病都有,不得不退回来。有些怀疑这个 MT 4 将会是一个比较失败的版本。

插件目录的变化

Beta 5 要求插件必须在 Plugins 目录下的子目录下,不允许脚本直接裸奔在插件目录下了。Beta 3 和 4 我没有还用过。不知道是从哪一个版本发生的变化。当然,这个变化不是问题,问题是即使这样设置了,很多插件仍然识别不到。包括 relatedkeyword.pl 插件。这个插件虽然简单,但却是我原来 Blog 不可或缺的。

更新导致的数据库错误

如果重复运行了升级操作,似乎就有这个问题:

lib/MT/Author.pm line 337

可以参考论坛上提供的修改数据库的解决办法

Media Manager 插件不兼容

因为 Media Manager 不兼容会带来如下错误信息:

Unknown action mm_entry_edit

这个插件作用不大,直接删掉。

Updated: 测试了一下 最新的 Beta 6 ,又回滚了

Beta 6 还是有新问题。MTinclude 后面的模块名字中间不能有空格。

--EOF--

中国雅虎站长工具又将新增一个产品:统计系统

上手比较简单,只需要添加站点的相关述即可获取一段 JavaScript 脚本,把这段脚本粘贴到自己 Blog/页面模版中。稍后片刻即可看到数据了,数据更新还是比较及时的。数据展现的纬度也比较多,有些数据也是直接针对中文用户而展现的(比如 PV 与 IP 单独的统计与对比),从这一点来说,倒是比 Google Analysis 更为贴近用户。

统计数据可以选择是否公开,如果公开的话,还可以接受留言,这是个很讨好用户的功能,促进个人站长之间的互动。

刚开始使用,参见 Blog 右下角的小图标 不少功能还没有完全体验到。回头再和大家交流一下经验。

--EOF--

关于归档

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

上一类别为 Tech.Memo.

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