作者文章: Fenng

Blogger 准备要赚钱之 Review Me

注:这是一篇付费评论文章(The following is a paid review).
不久前,我写过一篇《Blogger 们准备要赚钱?!》,当时我的基本观点是国内的 Blog 环境 “赚钱可以,但现在还不是时候,可以提前进场热热身”。最近在 Blog 圈子内对 Review Me 的模式反响很大,Blogger 如何赚钱这个话题,又给我们带来了一个可能性。
我比较感兴趣的是每个 Blog 价值的确定方法。我的 Blog 价值经过评估是 $250 (从目前来看,这似乎是中文 Blog 的最高价格?) 。Review Me官方给出的说法是这个价值是综合 Alexa 排名、Technorati 的连接数、RSS 订阅数量后综合得出的。对于 “RSS 订阅数量” 这个指标具体是采用哪里的数据没有给出,我猜可能是 Review Me 抓取 FeedBurner 的数据得出的。这样这篇 Review 据说可以得到 $125 的收入,如果用 Google 的评估体系来算,是有些偏高的。如果 Blog 投放 Google Adsense 广告,Blogger 在这个 Blog 的年收入差不多是 “每日独立访问者*1RMB”,也就是说,如果 Blog
一年下来,平均每天有 5000 个独立访问者,那么大约是 5000 RMB 的收入,前提是中文Blog(英文 Blog 价值要高许多)。
这个新的价值体系是从 Review Me 的角度建立的,如果有广告投放商准备买服务,那么也自然要认可遵从 Review Me 的价格标准,这个认可过程绝对是最大的问题。现在这个价格令很多 Blogger 欣喜,颇有些商鞅变法 “立木以信” 的味道。Review Me 建立了一套新的游戏规则,其目标是成为广大 Blogger 的代理人。
我比较好奇的是 Keso 的Blog 是怎样一个价格,搜索到的结果只有 $40,难道是 BSP 下的 Blogger 价值不高的缘故么? 还是Review Me 的评估体系对于中文 Blogger 不那么有参考性?
毫无疑问,Review Me 给付费评论点燃了一把火,这把火能否燃烧起来,就不得而知了。
EOF

本周言论 之 大硬盘存色情片

醒醒吧,硬盘是不能改变这个世界的。它能做的就是帮助人们存储更多的垃圾文件和色情片
–希捷 CEO Bill Watkins
追赶者必须在技术上超越对手才能够改变用户行为。如果搜狗做的水平接近百度,用户还是不会过来,2.5 版的技术和百度相当,现在 3.0 版已经超越了百度
–张朝阳
圣诞一到,有狂喜着磨刀的,还有梦呓着磨牙的。
王冉
我们所担心的是,如果我们再这样不加节制地推出新产品,你会发现在能够使用它们之前,你将不得不先去搜索我们的产品。
–塞吉.布林(Google创始人之一)
如果哪天有消息称 Google 要做比萨饼,那么比萨饼可能就要免费了.
比尔.盖茨
哪个地方拆迁不死几个人啊?
–山东菏泽市某拆迁指挥部领导
感谢 Keith Zhou, Jick Nan, Joy Yong 几位提供本期部分内容。

继续阅读

我们对未来知之甚少

偶然看到去年岁末《财富》杂志的 《2006 年的 IT 发展 8 大预测》,时间会证明一切,看看哪些预测是准确的。

1.Google 锋芒被雅虎抢走

现实:预测失败. Yahoo! 持续低迷,到了年末《花生酱宣言》之后出现了大振荡。Google 依然风光无限。

2.亚马逊在 Web 市场重新崛起

现实:预测失败. 没看到 Amazon 在 Web 市场的什么大动作。这一年多来只能说是波澜不惊。

3.电信公司的 ISP 地位无人可撼

现实:正确. 的确是这样。至少在中国是这样。因为电信公司没有竞争对手。

4.苹果将进军手机市场

现实: 不算正确。没有任何迹象表明苹果不会进入手机市场,但是什么时候进入也是没有迹象表明。

5.手机电视成为趋势

现实: 手机电视在哪里?

6.AMD 继续给英特尔施压

现实:预测正确。

7.排队抢购 “Windows 95” 一去不复返

现实: 预测正确。Vista 发布了。但是这是 2006 年,不是 Web 还没有普及的 1995 年。大家都在排队抢购 Wii.

8.思科将重新获得投资者追捧

现实:投资者现在都追捧 Google 呢。
严格来说, 8 条预测只有三条还算准确。我们对未来知之甚少。
2007 年的技术趋势,谁来预测一下?
EOF

Oracle 的 MBRC 与 SSTIOMAX

Oracle 初始化参数 DB_FILE_MULTIBLOCK_READ_COUNT (MBRC) 默认值一般是比较低的,在进行一些比较大的数据操作的时候,恰当的调整当前 Session 的 MBRC 的值可能会在 IO 上节省一点时间。
DB_FILE_MULTIBLOCK_READ 这个参数的值并不是可以无限大, 大多数平台下的 Oracle 都是 128。一般 Oracle 的 Block Size 是 8K 。128*8K=1M 。 这个 1M 是大多数操作系统一次最大 I/O 的限制。前面的限制要从这个 1M 推回去,初始化参数 DB_FILE_MULTIBLOCK_READ_COUNT 的最大值之所以定为 128 ,也是一个比较保守的策略。
Oracle 的 Metalink Note:291239.1 有一小段说明:

Each version of Oracle on each port, is shipped with a preset maximum of how much data can be transferred in a single read (which of course is equivalent to the db_file_multiblock_read_count
since the block size is fixed). For 8i and above (on most platforms) this is 1Mb and is referred to as SSTIOMAX.
To determine it for your port and Oracle version, simply set db_file_multiblock_read_count to a nonsensical value and Oracle will size it down for you.

SSTIOMAX 中的 SST 代表什么意思不为人知:

SSTIOMAX is an internal parameter/constant used by oracle, which limits the maximum amount of data transfer in a single IO of a read or write operation. This parameter is fixed and cannot be tuned/changed

要查看当前系统上的 SSTIOMAX 限制,可以通过如下做法简单的得到(trace 10046 的方法似乎麻烦了一些):

foo@DEMO> show parameters db_file_multiblock_read_count
NAME TYPE VALUE ------------------------------------ ----------- ------- db_file_multiblock_read_count integer 16
foo@DEMO> ALTER SESSION SET db_file_multiblock_read_count =256;
Session altered.
foo@DEMO> SELECT VALUE FROM v$parameter WHERE NAME = 'db_file_multiblock_read_count';
VALUE -------------------- 128

正常运行的库,MBRC 并非越大越好(除了 IO 效率有降低的可能,也会有可能影响 CBO 的运行)。后者是我的猜测,因为在 10gR2 上,’db_file_multiblock_read_count’ 参数引入了两个相关的隐含参数(Refer):

_db_file_exec_read_count
_db_file_optimizer_read_count

距离上一次写技术备忘似乎有好久了…这几天比较累
EOF