FeedSky,技术方面还需要努力

| 6 Comments | 0 TrackBacks | WebBlog Articles

不是给 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 做的更好:)本人非专业人士,纯粹胡言乱语,有不和大众胃口的地方,还请洗耳不闻:)(写这段话的原因是因为这里:点击查看精彩

引用通告|TrackBacks (0)

本日志的TrackBack URL: http://easun.org/cgi-bin/mtos/tb_mt_41.pl/130.

本文相关评论|Comments (6)

feedsky抓取太慢了,feedburner也没有要求我们主动去ping他们的服务器,但几乎每次都在更新后几分钟内就完成抓取,几乎和源feed同步。

feedsky抓取太慢了,feedburner也没有要求我们主动去ping他们的服务器,但几乎每次都在更新后几分钟内就完成抓取,几乎和源feed同步。
我觉得倒不是抓取的事,而是cache不合理:) Feedsky 比起 feedburner还是技术上有差距。

如果是一些有rpc功能的blog 程序的话,ping的时候能够自动通知各大搜索引擎,当然也会包括feedburner.
pingomatic应该就是典型代表

feedsky好像远没有进入这个圈子一样.或许国内也需要一个类似的服务的copy?

如果是一些有rpc功能的blog 程序的话,ping的时候能够自动通知各大搜索引擎,当然也会包括feedburner. pingomatic应该就是典型代表

feedsky好像远没有进入这个圈子一样.或许国内也需要一个类似的服务的copy?


这个圈子其实我的觉得不必要刻意去进什么的:)技术做上去了,用户多了,影响力上去了。自然。。就进了 :P

用户数不可谓不多.
用户质量有极大的问题是真的.
如果一算平均订阅数的话,就知道feedsky做了多少无用功了.

这是个没办法的事情.

feedburner(2007.7.20)
Currently feeding 471,686 publishers who've burned 808,707 feeds

feedsky(2007.5,from sina)
主持人:你们现在的用户数大概是多少?

吕欣欣:我们托管Feed数是三百多万,这个月应该会突破四百万,其中有一部分是注册用户,大概在七万到八万之间,还有一部分大概有十万左右是通过别的渠道过来的。

恩。的确,用户群和Feed数够庞大的了。用户质量不咋的,技术方面需要加强啊 :D

发表该文评论|Leave a comment

最近发表|Recent Entries

[八卦]话说修路这件事

建国路貌似又在修。根本没有办法步行。这个让我想起来一个笑话:话说某A国人来北京,在东城区丢了一枚戒指,于是乎找警察,警察告诉他尽可能的帮他找。过了几天,此人发现整个东城的马路都挖开了,于是感叹曰:北京的警察真好。看来这个笑话的地点可以换在朝阳了?是不是某人的戒指又丢了?PS: 城市规划城市规划,年年挖年年修。。。生命不休,挖路不止…

[SiteLog]Blog升级到了 Movable Type Pro 4.25

Thisi is a SiteLog of Easun's WebBlog.今天终于升级到了 Movable Type Pro 4.25 ,貌似一切顺利,也没有发现什么特别大的改动?只是 Community Pack 变成了 1.62, Professional Pack 升级成了1.3 。其他的一切顺利,模版也没有修改,我甚至连重建前台HTML的事情都没有做。。。就这样吧,继续用这个风格,等有时间了再慢慢研究吧。如果非要说有什么修改的话,就是评论的登陆方式又丰富了很多,包括…

IE脚本错误,可以尝试以下办法

IE 脚本错误是个很麻烦的问题,一般定位都是 JS 引擎 和 VB 引擎出错。但是有时间反复注册 jscript.dll 和 vbscript.dll 也不能解决问题。具体表现 部分 js 解析正常,而部分就不行,尤其是基于 Web2.0的网站。不说别的,就连 ie7/ie8 本身第一次运行向导的"保存设置"也出错。其实研究下,貌似都出现在 XML 解释上? 重新注册…