FeedSky,技术方面还需要努力

不是给 FeedSky 找别扭:)
我的 Feed 是交给 FeedSky 托管的,同时也是 FeedSky 话题广告(虽然我没有写过)和 Feed展示广告 的客户。通过这段时间内的服务使用,觉得 FeedSky 的服务还不错,但是技术方面和理念上还需要加强。


1。关于 ping 服务 和 cache 机制。

我用的 MT,在后台中设置了新Blog会给 http://www.feedsky.com/api/RPC2 自动发 ping 的,但是似乎有时总是看不见 Feed 的更新,常常需要我去 Feedsky 去手动通知下,才会更新,刚开始以为是 feedsky 的 cache 机制的缘故,但是测试的结果是如果你不手动去 feedsky 去ping 的话,24小时后也不会更新。
我不清楚Feedsky ping机制和 cache 机制,但是通过几次 Feedsky MySQL 服务器 down 掉返回的错误信息来看,Feedsky 使用的是 C写的CGI程序+MySQL来管理的。但是记得当时我的Blog已经 N 小时没有更新了,访问Feedsky 的错误居然还是“MySQL error“,难道对没有更新的Feed没有静态cache? 这个对服务器的压力太大了一点吧?
我想象中的Feed更新应该是 ping->更新MySQL数据库->生成(更新)静态cache,这样会比较好的减轻服务器负担,而且是否更新静态cache应该看feed数据是否更新和静态cache的生成周期(比如最后更新时间小于5min则不更新)等等,这样既可以保证即时性,也减轻了MySQL服务器的压力。
即时性是Feed的一个重要因素。如果保证不了这个,那么就比较另人头疼了:)
我相信像 FeedSky 这样的服务,没有 cache 机制是不可能的,只是显然他们现在运行这个cache机制似乎不太合理?
(猜测,仅仅是猜测。)

2。服务器的统计机制?
也许是数据太多了还是其他? 总觉得 Feedsky 的统计有问题,有时候是靠人力来弥补的:)
说的简单的例子,Feedsky 说给订阅数>20的用户都发了 Feed 展示广告邀请,但是从支持论坛来看,好多>20的依然没有收到email:) 虽然是个小问题,而且客服也很热情的帮忙,但是也应该从技术上抓一把,让这样的事情不发生或者少发生:)

3。Feed 规范方面
发现通过 FeedSky 托管的 Feed 虽然界面漂亮了,但是总是通不过 标准 的验证:
大家请看下面两个地址


第2个托管的Feed的源就是第一个原始Feed,但是我自己的通过了而托管的没有通过,虽然不影响阅读,但是作为一个专注于Feed服务的专业网站,通过验证应该还是必要的。
我自行分析了一下没有通过的原因,似乎仅仅是 Feedsky 少了 <![CDATA[ ... ]]> 而已?
也许是Feesky的疏忽吧?

4.飞递指数
飞递指数是FeedSky 对托管的Feed的一个评价,类似于 Google PR。
这个是个很好的创意,但是遗憾的是 FeedSky 显然没有把这个作用真正体现出来,我说的不是公布飞递指数的计算办法,这个是商业机密,就好象 Google不会告诉你 Google PR 的计算办法一样。我说的是用户看不到自己订阅的Feed的 飞递指数,窃以为飞递指数 可以给订阅者一个初步的信息来让订阅者在第一次看到这个Feed来判断一下这个Feed是否可读性高从而引导订阅者,这样,对Feed的发布者来说,也是一种激励。然而,现在的Feed依然看不到 飞递指数 ,也没有工具查看某个 Feed 的飞递指数,这个指数现在只是用来作为广告定价的凭据而已,似乎是浪费了这个创意。

5。话题广告和展示广告

这个,我都算是用户吧。申请话题广告的时候,我刚开始决定使用 FeedSky 的服务,订阅数是 0 ,当时申请是报着好奇的心态去申请的,倒是很快申请下来了,但是却一直没有写任何话题广告,原因很简单:当时比较忙,进Feedsky管理后台一看,只有一个”赶集网“可以接,其他的都是灰色的,而”赶集网“看了两眼实在没有兴趣,so就搁浅了。 展示广告倒是现在在用,效果不知道,总而言之,怎么评价呢,觉得展示广告还算Feed正行,而话题广告就有点偏题了,感觉优点不务正业的味道。。。。当然只是偶一家之言。 :)

罗嗦了一大堆,不是对 FeedSky 挑毛病,只是今天上班的时候偶有奇想,so乱笔记下而已,初衷只是希望 FeedSky 做的更好:)本人非专业人士,纯粹胡言乱语,有不和大众胃口的地方,还请洗耳不闻:)(写这段话的原因是因为这里:点击查看精彩