2009年08月27日

转自草根网

Smashing Magazine从Technorati Top Blogs 中的前100位里面选出50位(排出那些非自然排名的博客)。然后对这些博客的界面设计进行调查、总结出30个博客设计问题并给出解决方案。

在看这份博客设计调查报告之前,我们应该搞清楚一些前提:

  • Technorati的排名是否权威这没有必要讨论,至少这些被调查的博客都是全球比较受欢迎的博客,通过对这些博客的调查所得出的解决方案还是比较具有参考性的。
  • 任何一份调查都仅为了供参考,并不会给出你一个好博客的最佳设计方案。它们只是要让你有一种直觉告诉你哪种方法好过另一种。但是你也得思考你正在做的内容,盲目地遵循我们的调查结果不一定会改善你的设计。
  • 了解这些全球知名博客做了什么,更重要的是了解他们不做什么,也是很有用的。

1. 布局

布局是每一个网页设计的基础,我们从这里入手。该使用两栏,三栏或杂志型设计?固定布局或是自适应布局?是否还应该使用表格?

1.1 多少栏?

设计布局时应该使用两栏还是三栏这个问题几乎无法回答。不幸的是,我们找不到任何实际研究结果来说明哪一个方案比另一个受青睐。一般而言,它取决于内容和你的目标用户。在某种程度上来讲,要在使用二栏结构的博客中找到主次内容之间的平衡点是不可能的。在这样的情况下你可能需要将次要的栏(边栏)划分成两部分——事实上这种方案使用的相当多。

在两种情况下都要使结构尽可能地透明清楚。四栏和多栏的布局常常不是好办法。

根据我们的发现,

  • 58%的博客使用三栏或多栏的布局(TalkingPointsMemo, CopyBlogger, Mashable, Lifehacker)
  • 42%的博客使用两栏的布局(Zen Habits, GigaOM, Google Blog, Seth Godin, Boing Boing)

tpm 全球著名博客设计调查报告

差不多50个博客就足以发现不寻常的博客布局。Drudgereport就用了我们称之为“反布局”的方法。TPM用了两栏、三栏和四栏的布局。

帕兰注: 如果你也想为自己的WordPress博客使用一个三栏或多栏主题,可以查看我们昨天发布的100款WordPress杂志CMS主题

1.2 布局居中还是居左?

帕兰注: 这里SM的调查结果是“94%的博客是布局居中“。这似乎是个根本没有必要讨论的问题,不管是博客还是其它任何类型的网站,居中布局所占比例都应该能超过90%。但设计优秀的居左布局也能有很好的效果,帕兰个人比较喜欢的两个居左布局,一个是著名的Adobe官方网站,另一个是个人博客Playground Blues

另外,这里没讨论到水平滚动布局和居右布局。居右布局我应该是几乎没见过。水平滚动布局的话,本身使用比例比较小,博客设计中使用的就更少。帕兰个人觉得水平滚动布局还是比较有其优势和特色的,只是一切缘于用户的习惯,当我们的视觉已经习惯了居中布局的时候,其它布局要么让我们觉得前卫大胆,要么就是烂透了。

1.3 固定,弹性还是自适应布局?

在50个博客里没有一个使用弹性布局(布局会随字体变化而变化),只有一小部分使用自适应布局(布局随浏览器的大小而变化),这着实引人注目。下面是有关的精确发现:

  • 92%的博客使用固定布局
  • 8%使用流动布局或夹杂了某些流动布局元素的混合式

自适应布局最好是根据用户喜好来调整,因为固定的布局更容易使设计者确信某一个设计决策不用考虑到字体大小和视窗大小。

engadget 全球著名博客设计调查报告

自适应布局的主要缺陷在于使用宽屏电脑时他们的宽度会增加,一行会变得非常宽(这里是一个Engadget的例子,每行有150个字符)。你可以用最大宽度分布来算一算。

1.4 固定布局的宽度

由于我们已经注意到固定的基于像素设计的布局占有优势,因此我们想要深入了解这些布局并试图发现这些布局的一般特征。特别是,我们已经考虑到固定格局的宽度通常与container或wrapper的宽度相对应。显然,

  • 9%小于等于800像素
    (PostSecret, Seth Godin, Google Blog, BeppeGrillo.it)
  • 15%介于801到900像素之间
    (Neatorama, Kottke, DailyKos, Perezhilton, TUAW, Yanko Design, Scobleizer)
  • 20%介于901到950像素之间
    (Huffington Post, BoingBoing, TreeHugger, Dooce, Blogoscoped, SearchEngineLand)
  • 56%介于951到1000像素之间
    (ars technica, Lifehacker, TechCrunch, ProBlogger, A List Apart, TMZ, Wired, GigaOM, Joystiq, Zenhabis, Copyblogger, Consumerist, Slashfilm)

结论:可以证实使用951至1000像素宽度的布局成为趋势。

1.5 内容区域和设计的比例?(如果是固定格局的话)

正如你上面看到的那样,每种布局都需要至少一个包含次要内容并向用户提供导航的边栏。但是,如果要清楚地展现出所有的导航条的话,什么是令用户感觉舒服的最佳方式呢?或者,换句话来说,主要内容区和整体布局之间的比例如何选择?主要内容区域空间越小,边栏的优势就越大,反之亦然。在哪里找到平衡?

boing 全球著名博客设计调查报告

根据我们的调查:

  • 96%的博客用一半以上的空间呈现主要内容;特例是:CopyBlogger (0.48), SlashFilm (0.48)
  • 54%的博客用50%到60%的空间;(Mashable, Lifehacker, Kottke, Blogoscoped, A List Apart, BoingBoing, DailyKos, TreeHugger, Scobleizer, Problogger, TUAW, bits.blogs.nytimes.com)
  • 46%的博客用60%到70%的空间;(ars technica, TechCrunch, GigaOM, Dooce, Zenhabits, CNN Political Ticker, CrunchGear)
  • 平均58%的空间用于呈现主要内容

1.6. CSS布局还是基于表格的布局

显而易见,那些一天多次更新的受欢迎的博客,会选择CSS因为它们允许更好更容易维护,并且减少缓冲时间。因此毫无疑问:

  • 排名前50的博客有90%都用基于CSS的布局;
  • 10%用的是表格或是表格与CSS的组合;
    (PerezHilton, Neatorama, CNN Political Ticker, Beppe Grillo, TreeHugger).

而且,TreeHugger用的是传说中的Onmouseout-JAVA事件去模仿环绕效果——一种我们多年来一直想要忘记的设计方案。

2. 排版

内容为王。这一条适用于一般的网站,也适用于博客。而且,让读者在阅读或看到文章的第一眼就感到舒服是设计者的职责所在。这就是排版发挥作用的地方。如何使你的内容的可读性做到最好?用什么字体?用哪个字号?我们的调查也许能为你的设计决策提供一些有用的起点。

2.1 亮底暗字还是暗底亮字?

可以预料到,98%的顶尖博客用的是白色背景黑色文字。只有PostSecret用的是黑色背景色和亮的文字。不过,这种设计策略有可能与站点的内容高度相关。

postsecret 全球著名博客设计调查报告

帕兰注: 文字为主的网站通常都白底黑字,黑底的网站多见于图片展示类网站或是比较个性化的博客。很久之前帕兰和一些朋友讨论过这个问题,有许多朋友都认为黑底白字更利于眼球的舒适度。直到现在其实我还挺疑惑的,白底黑字的主流是因为白底黑底就利于阅读还是又因为习惯问题呢?

2.2 每行多少字?

为了保证最佳阅读效果,我们需要让阅读令人舒适。有一些研究结果声称理想的情况是一行52到68个字符(包括标点和空格),其他研究表明更长的文字不会显著地影响其用法。因为没有明确的规则可以提供,所以设计师会运用不同行长进行实验。

为了计算每行适用字符数的最大值,我们使用浏览器的默认设置和风格表单提供的默认排版设置。

  • 10%的博客每行是65到74个字符,如PostSecret, Beppegrillo, Perez Hilton, Scobleizer, Blogoscoped;
  • 18%的博客每行是75至84个字符,如Dooce, Blogs.nytimes.com, Joystiq, CopyBlogger, TUAW, Slashfilm;
  • 34%的博客每行是85到94个字符,如Lifehacker, Huffington Post, Kottke, ars Technica, Huffington Post, BoingBoing, Seth Godin, Treehugger, Problogger;
  • 18%的博客每行是95到104个字符,如Mashable, ReadWriteWeb, Smashing Magazine, Google Blog, A List Apart, Search Engine Land;
  • 16%的博客每行字符数超过105,如Engadget, TechCrunch, GigaOM, Wired, TMZ。

基于我们的发现,我们可以有把握地建议最常见的行长(不一定是用户友好性最好的)在80到100个字符之间。

2.3. 正文的主要字型

sans-serif体已经成为屏幕正文中实际使用的标准字体,尤其是网络上。有人建议说这是因为这种小号字体使得其他字体在屏幕上显得十分混乱。受欢迎的博客里这种观点是如何体现出来的呢?

ars 全球著名博客设计调查报告

根据我们的调查:

  • 34%的博客正文用的是Verdana字体(sans-serif体),如A List Apart, Kottke, TUAW, CopyBlogger, Dooce, ars technica, TechCrunch, Smashing Magazine;
  • 24%的博客正文用的是Lucida Grande(sans-serif体,包括Mac OS X),如Zenhabits, Mashable, Lifehacker, CrunchGear, Thinkprogress;
  • 18%的博客正文用的是Arial(sans-serif体),如ReadWriteWeb, Engadget, Google Blog, CNN Political Ticker;
  • 14%的博客正文用的是Georgia(serif体),如Scobleizer, GigaOM, Wired, BoingBoing, Huffington Post;
  • 6%的博客正文用的是Trebuchet MS(sans-serif体),如Andrew Sullivan, Seth Godin, Postsecret;
  • Helvetica Neue和Times New Roman字体只分别被ProBlogger和TPM使用。

帕兰注: 对于中文博客设计来说,使用最多的应该是Arial, Verdana, Tahoma, 宋体。另外值得一提的是,一些朋友喜欢使用微软雅黑字体,从字体本身上来说,微软雅黑是个非常漂亮的字体。但我个人觉得雅黑并不适合做为Web字体,尤其是如果你的内容字体比较小,比如12px,这个时候的雅黑锯齿效果是非常严重的,尽管总体效果漂亮,但不清晰,不利于阅读。

2.4. 文章正文字体多大?

字体越大,读者越容易看到呈现在网页上的内容。但是随着字体的加大,读比较长的文章时就越费劲,因为需要更频繁地滚动页面——并且需要眼睛更频繁地从一处跳到另一处。那么最佳选择是什么呢?

zen 全球著名博客设计调查报告

这里是一些我们调查所得最常用的字号:

  • 34%的站点用12像素的字号,如SearchEngineLand, TUAW, Mashable, ars technica, Engadget, Smashing, DoshDosh, TreeHugger;
  • 30%的站点用13像素的字号,如Consumerist, CopyBlogger, Zenhabits, Valleywag, Lifehacker, Huffington Post, BoingBoing, Seth Godin, Google Blog;
  • 14%的站点用14像素的字号,如TPM, GigaOM, Wired, ReadWriteWeb, Gigazine, ProBlogger;
  • 12%的站点用11像素的字号,如A List Apart, Kottke, Neatorama, Dooce, TechCrunch, Dailykos;
  • 4%的站点用15像素的字号,如Scobleizer;
  • 其余的站点用10像素、16像素和17像素,各有一个站点使用。

帕兰注: 在权衡正文字号的大小时,设计者往往会考虑整体美观和易读性。比如 帕兰映像的正文字号一直是使用12px, 尽管我自己也认为这个字号有些小了,大一点可能会更利于阅读,可我总觉得字号扩大后,哪怕是13px,很影响整体的美观 :)

2.5. 大标题的主要字型

由于sans-serifs体通常用于正文,因此人们常常以为设计者们会倾向于使用serif体来强化大标题。事实如此吗?

  • 30%的博客用的是Arial字体 sans-serif,如CNN Political Ticker, Scobleizer, TPM, Crooksandlliars, Joystiq, Dooce, PerezHilton, ReadWriteWeb, Engadget, Google Blog, TreeHugger;
  • 22%的博客用的是Georgia字体(serif),如A List Apart, Andrew Sullivan, Blogs.nytimes.com, GigaOM, Wired, Huffington Post, BoingBoing;
  • 8%的博客用的是Lucida Granda字体(sans-serif),如Tuaw, ThinkProgress, Lifehacker, Crunchgear;
  • 8%的博客用的是Helvetica字体(sans-serif),如Zenhabits, Mashable, ars technica, Smashing Magazine;
  • 6%的博客用的是Verdana字体(sans-serif),如Blogoscoped, Neatorama, DailyKos;
  • 6%的博客用的是Trebuchet MS字体(sans-serif),如Slashfilm, Postsecret, Seth Godin;
  • 4%的博客用的是Helvetica Neue字体(sans-serif),如CopyBlogger, ProBlogger;

此外,Calibri (SearchEngineLand),American Typewriter (Valleywag), Lucida Sans Unicode,,Franklin Gothic Medium和Tahoma (TechCrunch) 字体分别仅有一个博客使用,有一个博客Kottke压根儿就没有大标题。

2.6.大标题的字体多大?

最后,让我们来看看大标题的字号。标题越大,它被赋予的分量越重。但是,如果用太多的大标题争取用户的注意力,其认知的负担就会加重,这样用户实际上就很难顾及到导航条。因此有时候多不如少。首要的原则是:如果在起始页上有了很多文章,别忘了减小标题的字号,高亮处理,比如用一种能吸引眼球的颜色。

  • 24%的博客用的是20-22像素的字号,如BoingBoing, PerezHilton, Blogoscoped, Google Blog, TechCrunch, ReadWriteWeb;
  • 22% 的博客用的是23-25像素的字号,如CopyBlogger, ProBlogger, Lifehacker, Mashable;
  • 22% 的博客用的是17-19像素的字号,如Tuaw, Scobleizer, TreeHugger, A List Apart, Gizmodo;
  • 16% 的博客用的是14-16像素的字号,如YankoDesign, Dailykos, ars technica, Seth Godin;
  • 6% 的博客用的是26-29像素的字号,如Engadget, GigaOM, Wired, Dooce;

drowse 全球著名博客设计调查报告

此外,0%的博客使用的是30-31像素的字号;Huffington Post用的是32像素字号,Zenhabits用的是34像素字号,Kottke没有大标题。Smashing Magzine自然是“最大标题尺寸”那一型的:我们的字号是44像素。

我们的结论是似乎大标题使用17-25像素的字号是最佳选择。

3.结构

信息设计通常甚至比视觉设计更重要。内容的结构和分级(内容呈现的方式)对访问者如何感知当前信息以及他们在寻找某一特定信息时如何快速浏览当前信息具有非常大的影响。从信息架构的层面上讲,导航的地位最为重要。

3.1 导航菜单:置顶,居左还是居右?

几年前,在博客的浪潮席卷互联网之前,将导航菜单置于页面左手边是一条不成文的规则。当然到现在这条规则并不为顶尖博客们所采用。

我们发现:

  • 58%的博客使用居右(垂直)型导航(如Scobleizer, TPM, CrunchGear, Neatorama, Google Blog, DailyKos, Engadget)
  • 52%的博客使用在顶端水平对齐的主导航(辅之以居右的二级导航)(如A List Apart, Google Blogoscoped, Dooce, GigaOM, TreeHugger, Smashing Magazine, Mashable, ReadWriteWeb, Ars Technica, TechCrunch, Huffington Post)
  • 12%的博客使用居左的垂直导航

实际上,访问者并不在乎你的导航菜单放在顶端还是边栏。只要你的可用性测试证实大部分新访问者可以轻易地确认菜单栏并使用上面的可选项,你就做对了。因此从根本上来说你可以使用上面提到的任何一种方法。

readwriteweb 全球著名博客设计调查报告

ReadWriteWeb 使用的是在页面顶端的横向主导航

 

实际上,当导航栏的设计没有完全遵循惯例时,访问者也不会真的感到困惑。但是,确保导航清楚不含糊是设计师的职责所在,这与到底如何设计导航无关。有一些用户偏好居右的菜单,因为从人机交互的角度来看,它更便于使用。因此75%至95%的人是右撇子,这也不难推测鼠标的指针通常会回到视窗的右半边。

为什么?滚动条被置于浏览器窗口的右边。因此,如果鼠标没有滚轮,用户使用滚动条的需要就更甚于使用浏览器工具栏上的浏览按钮。由于在大部分(至少是很多)网站中都需要使用滚动条,所以鼠标的指针更有可能靠近滚动条。因此,去往右边导航栏需要的位移就比去往左边导航的要小。

3.2. 起始页上多少贴子?

从用户的立场来看,没有什么情况比某个网站给人造成的过度的认知负担更糟糕了。我们Smashing Magazine清楚地知道要找到长篇文章和信息过多之间的平衡是多么地困难。

当呈现过多的信息给用户时,他们会试着逃避这种认知负担--他们将该页面加入书签以备将来访问(其实再也不会来了)或是干脆关掉窗口,因为他们无法应付呈现给他们的信息。

呈现适当数量的内容对留住访问者很重要,更重要的是,要确认他们还会回访。

  • 28%的博客在起始页上有14至18篇贴子。(如Tuaw, Slashfilm, Gizmodo, TMZ, Lifehacker, ArsTechnica)
  • 26%的博客有10到12篇。(如ProBlogger, TechCrunch, Dooce, ReadWriteWeb, CrunchGear)
  • 14%的博客有20到26篇。(如ValleyWag, Seth Godin, Search Engine Land)
  • 10%的博客有2到6篇。(如A List Apart, Smashing Magazine, CopyBlogger)
  • 10%的博客有27到35篇。(如Kottke, Boing Boing, ThinkProgress, Neatorama)
  • 8%的博客有7到9篇。(如GigaOM, Mashable, TreeHugger)
  • 2%的博客有36篇以上的贴子。(如Andre Sullivan有50篇)

arstechnica 全球著名博客设计调查报告

Ars Technica在首页上有18篇贴子的摘要。28%的受欢迎博客在首页上有14到18篇贴子。

3.3. 相关贴或受欢迎的贴子要显示出来吗?

我们无法证实将与用户当前浏览的贴子相关的文章链接显示出来是否是一种趋势。54%的受欢迎博客显示了相关链接(如GigaOM, CopyBlogger, ProBlogger, ReadWriteWeb, Mashable, Engadget, TreeHugger),但其他的没有(如Dooce, TechCrunch, BoingBoing)。

  • 只有48%的博客显示了受欢迎的贴子。其中有Zen Habits, CopyBlogger, DailyKos, Mashable, ReadWriteWeb, Smashing Magazine and Huffington Post。
  • 16%的博客显示了最新的评论(如ReadWriteWeb, BoingBoing, TreeHugger, TMZ, Tuaw)。但是大部分的博客完全没有在首页上显示最新评论。

gigaom 全球著名博客设计调查报告

GigaOM 是那54%博客之一,每一篇文章都有相关贴的链接列表。事实上,这个博客显示了两次相关文章的链接。

3.4. 页脚放什么信息?

大部分网站的页脚都用来展示诸如服务条款、互联网联盟协议、帮助、版权和“关于我们”的链接。但其实可以有更多的选择(见现代网络设计中的页脚:创意实例与理念)。非常有意思的是,我们的调查也提供了一些页脚设计的实用方法。

页脚可以包括:

  • 版权、合法性、隐私条款、服务条款、用户条款(90%),如GigaOM, TMZ, ProBlogger, ReadWriteWeb, Ars Technica
  • “关于我们”的链接(38%),如Slashfilm, Dooce, GigaOM, ReadWriteWeb, Gizmodo
  • 相关信息的链接(30%),如Kottke, GigaOM, ReadWriteWeb, ProBlogger
  • RSS订阅的链接(22%),如Slashfilm, Ars Technica, BoingBoing
  • 常见问题或帮助的链接(22%),如Gizmodo, ArsTechnica, Andrew Sullivan
  • 搜索框(14%),如Dooce, Tuaw, Engadget
  • 到页面顶端的链接(10%),如TreeHugger, Zen Habits
  • 到起始页的链接(10%),如Kottke, CrunchGear, Joystiq, TPM
  • 网站地图的链接(8%),如Andrew Sullivan, Wired, Tecaucus @ NY Times

Joystiq 的页脚既不美观也不实用。有时候少一点更好。页脚下面的图片是一个广告。

44%的博客展示一个以上的简单的版权声明和少量链接。比如,Zenhabits(有网站地图)和Netorama(有下级导航菜单)。Problogger还显示了“关于”页面的链接。58%的博客用了一种使用得很少的“标准”方法(如Techcrunch)。其余的压根儿就没有页脚。

4. 广告

很多情况下,尤其是排名前列的博客,要维持其生存、支付流量费用、支持编辑团队从而使作者们真正出版其作品,广告对是必需的。大部分的用户希望将广告放在他找到的信息后面。不过尺度在哪里?并且受欢迎的博客网站上广告是怎么呈现的?用户习惯于什么?让我们一起来找原因。

4.1. 每页多少广告?

坏消息:博客空间广告泛滥。只有极少数的网站完全没有广告而且大部分情况下每页只有2到3个广告条。通常博客由主打广告和类似google广告链接组成。12%的博客上有扰人的情景广告(突然冒出来的带下划线的链接)。

一篇文章页面上广告条的数量通常与起始页上的广告数量相同,甚至要稍微多一些。其理由是:很多博主倾向于在文章里或贴子下方使用诸如google广告一样的文字链接广告。更多的发现:

  • 平均每个起始页使用5.84个广告条,如Mashable 广告最多,有20个,TechCrunch位列第二,15个
  • 平均每篇文章页面使用5.96个广告条
  • 68%的博客使用google广告,只除了Kottke, Scoble, Joystiq, Tuaw, CopyBlogger, Valleywag, GigaOM以外

最宽的广告条莫过于Kotaku,它在页面中间的广告条有1000像素宽。

4.2.广告要放在正文里吗?

在页面的内容区域,广告通常被置于贴子的下方。我们观察到文章中间的广告仍然常见,但是使用得相当少。

根据调查,

  • 76%的文章中没有广告(但文章下方或上方可能会有),如Dooce, A List Apart, ReadWriteWeb, Mashable, TechCrunch, BoingBoing
  • 44%在文章下面和评论前有广告,如ProBlogger, Zen Habits, Engadget, Smashing Magazine, Tuaw, CopyBlogger, GigaOM
  • 18%的博客在正文里有广告,如Huffington Post, Yanko, PerezHilton, Slashfilm, Search Engine Land
  • 6%在标题正下方和文章正文前显示广告,如Smashing Magazine, Neatorama, Yanko

4.3.广告放在页面什么位置?

除了正文,人们通常希望广告…嗯,到处都是:页面顶端、右边甚至底端。其实,在调查过的博客中只有12%遍地是广告——顶端、底端、主要内容的左右两边。这不好。但是显然,用户已经习以为常了,硬是漠视了与内容一起强加给他们的扰人的广告。

其他发现:

  • 88%的博客右侧有广告,如GigaOM, CopyBlogger, Engadget, TechCrunch, Smashing Magazine
  • 42%的博客顶端有广告,如Gizmodo, Talking Points Memo, Autoblog, TreeHugger, TMZ, PerezHilton
  • 34%的博客左边有广告,如Lifehacker, Mashable, Gizmodo
  • 24%的博客底部有广告,如Andrew Sulivan, Tuaw, Wired
  • 8%的博客没有广告,如Google Blog, Think Progress, Seth Godin

5. 功能

为了达到设计的主要目标,要兼顾用户友好性和功能性。所有主要的功能都要有并清晰地呈现,使用者必须有一种简单的直觉,知道使用这些功能需要做什么。比如,新访问者应该知道哪里是RSS按钮,哪里是互动性按钮,哪里是搜索框以及如何与博主联系。

5.1. 使用互动性按钮和图标吗?

互动性图标正在普及,但还远远不是一种标准。图标比单纯的文本链接使用得要多一些。网络服务商如Addthis将大量的流行互动按钮藏在一个“交互”按钮后面,当这个按钮非常受欢迎时才显示出来。这种办法的好处是:正文区保持整洁,为可选项提供了好的视觉效果。缺点在于:某些用户在一个互动性网站上找不到为文章投票的路径。

根据调查:

  • 54%的博客在文章下面使用了互动性图标,如GigaOM, ProBlogger, Mashable, Ars Technica, BoingBoing, ReadWriteWeb
  • 38%的博客没有用互动性图标,如Dooce, Google Blogoscoped, Scobleizer, Political Ticker
  • 8%的博客在文章上方使用互动性图标,如Smashing Magazine, TreeHugger, The Huffington Post

social icons neatorama 全球著名博客设计调查报告

Netorama 有很多交互性图标,也有RSS订阅和email订阅。

5.2.RSS订阅:位置和视觉外观

由于RSS按钮可能是将访问者与博客联系在一起的最重要的设计元素,因此应该在网站布局中给它一个醒目的位置。实际上,在Web 2.3 时代设计大而炫的RSS按钮的一个好理由就是:这些按钮需要第一眼就看得到。

所以在博客的顶端仍然并且通常看得到RSS按钮并不奇怪。实际上,

  • 只有38%的受欢迎博客在顶端有RSS按钮
  • 但有28%的博客将其放在边栏的顶部
  • 8%放在边栏的中间区域,14%放在边栏底部,8%放在页脚,但这些都不如放在页面上方那么常见。然而,这里的RSS按钮常常是对页面上方按钮的补充。

有意思的是,只有66%的站点使用了标准的RSS图标显示订阅,其余的则使用了简单的文本链接。

关于RSS订阅的数量:

  • 我们发现64%的博客只有一个主要的RSS订阅。 往往也具备评论的订阅和标签的订阅;但是似乎只有少数博客真正提供了多种渠道(如对某些特定主题的订阅)。
  • 56%的博客提供了email订阅,作为RSS订阅的另一选择。
  • 24%的博客一般借助Feedburner,公开了RSS订阅者的数量。Wordpress的用户可以考虑将Feedcount 作为一种方便的选择来订制自己的RSS图标。不过,在这里也一样需要Feedburner。

5.3. 使用标签云?

标签云为一篇博客所涉及到的流行话题及其在文章中的分量提供了良好的概括。但是,90%的博客并没有任何标签云或是给出标准导航的选项。我们的直觉是只是没有空间,这就是为什么即使标签云被使用,它也是相当的小而紧凑。

在调查的站点中有一个标签云的是The Huffington Post, ReadWriteWeb and Joystiq。你可以在我们的文章标签云集锦:实例与实践中了解更多相关信息。

5.4. 使用分页?

令人惊讶的是,在我们调查的站点中只有22%使用了分页(其中有Dooce, GigaOM, Mashable, ReadWriteWeb)。大多数情况下(60%)使用的是“下一页”“上一页”这样的标准导航。

分页有很多好处,因为它告诉访问者有多少内容并能使他们快速跳转到以前的文章去。标签群集锦:实例与实践提供了一些用分页取得成效的创造性例子。

有些博客也用日历导航(6%,如 Thecaucus, Andrew Sullivan)或是档案文件包(12%,如A List Apart, TPM, The Huffington Post)。

treehug 全球著名博客设计调查报告

Treehugger的不寻常的导航。不是分页和常用的下一页/上一页的导航,该站点显示了当前文章的前几篇和后几篇。

5.5. 搜索框放在哪里?

  • 只有62%的博客在页面的右上角有搜索框。
  • 其中58%的搜索框是放在顶端的。其余的放在边栏的顶部。
  • 边栏中间和更低位置的搜索框不多见(占16%)。
  • 只有一个站点在页脚位置放搜索框(Dooce),Kottke根本就没有搜索框。

5.6. 联系页面的链接放在哪里?

大部分博客将联系页面的链接放在边栏。通常这个链接在右侧导航或左侧导航菜单提供的下一级导航选项中。有时候也使用图标(尤其是email图标)来表达该链接的目的。

  • 52%的博客将联系页面的链接放在边栏(如Engadget, TMZ, DailyKos, Smashing Magazine)
  • 40%放在顶端(如A List Apart, Dooce, CopyBlogger, ProBlogger, Ars Technica, Tech Crunch)
  • 30%放在页脚(如ReadWriteWeb, ProBlogger, Mashable, TMZ)
  • 4%藏在“关于”部分里(如TreeHugger)

值得一提的是大部分博客(64%)都为读者提供了联系邮件,只有28%的博客有需要在线填写的联络单。8%的博客两者皆有(如Yanko, TechCrunch)。Zen Habits请读者在博客首页写评论来与博主取得联系。

5.6. 受欢迎的博客遵循一致的标准吗?

实际上,在开始这项调查之前我们已经预计到对大部分博客来说内容比设计更为重要。但是我们并没有料到只有4%的博客在实际上遵循了标准。

显然:

  • 96%的博客没有统一的标准
  • 8%的博客有500个以上的错误,如Ben Smith’s Blog, Neatorama, Search Engine Land
  • 28%的博客有200到499个错误,如BoingBoing, ProBlogger, Google Blog, Engadget
  • 24%的博客有100到199个错误,如TreeHugger, Mashable, ReadWriteWeb, Gigazine, TUAW
  • 22%的博客有50到99个错误,如TechCrunch, CopyBlogger, Dooce, Ars Technica, Lifehacker
  • 10%的博客有1到49个错误,如Kottke, GigaOM, AutoBlog, Google Blogoscoped
  • 4%没有错误,如A List Apart
neatorama 全球著名博客设计调查报告

Neatorama 不支持XHTML1.0转换。毫无疑问,其页面是用表格做的。

 

错误最多的非Ben Smith’s Blog莫属,它有2286个错误,没有文本格式定义,其次是Neatorama(1428个错误)和Search Engine Land(1116个错误)。

导致无效HTML代码的唯一理由是:从网络标准的角度来看,广告服务商太可怕了。他们几乎从不生成有效的代码,这就是为什么大部分的博客几乎都没有遵循统一标准的原因(他们需要广告来生存)。作者们常常别无选择,要为了得自于广告商的“糟糕的”源代码的收入而向代码的质量妥协。

结论

让我们对上述主要调查结果进行简述,作为第一部分调查的总结。请记住不要拿这个调查的结果作为一个好的博客设计的指南,这个问题要另外撰文叙述。

  • 大的博客需要多栏布局,通常三栏就够了;(58%)
  • 页面布局要居中;(94%)
  • 布局要有固定的宽度(按像素计算);(92%)
  • 固定布局的宽度介于951至1000像素之间;(56%)
  • 整个站点布局的58%用来呈现主要内容;
  • 使用CSS布局;(90%)
  • 背景用亮色,文字用暗色;(98%)
  • 最常见的(不一定是最具备用户友好性的)行长是介于80至100个字符之间;
  • 在正文中使用Verdana, Lucida Grande, Arial 和 Georgia;(90%)
  • 正文的字号介于12至14像素之间;(78%)
  • 大标题用Arial和Georgia体;(52%)
  • 大标题的字号介于17至25像素之间。
  • 52%的博客通常使用右边栏(58%)和顶端横向导航
  • 50%的博客起始页显示10到20个贴子的摘要
  • 50%的博客在每篇文章的页面上显示相关贴和最受欢迎的贴子
  • 90%的博客页脚包含版权信息,40%的博客有“关于”页面的链接,30%的博客有联系信息的链接
  • 平均每个起始页上有5.84个广告条
  • 平均每篇文章页面上有5.96个广告条
  • 76%的博客文章通常不包含广告
  • 88%的博客广告常常在右边栏
  • 54%的博客其交互性图标常常在贴子下方
  • 66%的博客的RSS按钮显示在页面的上部
  • 66%的博客使用“标准的”RSS图标,用得比文本链接要多
  • 64%的发布方只用一个主要的RSS订阅而不是多个订阅
  • 90%的博客不使用标签云
  • 分页少见,只有22%的博客使用
  • 62%的搜索框放在页面的右上角
  • 96%的博客都不规范

本文是来自Smashinag Magazine总结的一份博客设计调查报告(1,2),中文译文由网友春水碧于天首发于译言(1,2),帕兰映像重新精简整理和加注后发布。

再提醒一下各位爱好设计的朋友, 调查只是为了参考, 设计应该遵循基本理论和潮流趋势,但也要大胆创新和勇于实验, 才不会扼杀设计中的创意.

2009年08月19日

苹果软件商店(App Store)已经启动一年了,现在已经拥有6万多个软件。但普通用户如何从这么多软件里找到自己喜欢的软件呢?以下是由AppVee(一个专注于苹果软件商店点评的网站)选出的09年最佳软件。

最实用

1. Slacker Radio

Pandora的绝佳替代品,曲目众多,收费账户可提供无线歌曲跳进。(同类软件:Last.fm)。

2. 嗨你在哪儿
一个提供推送通知功能的简单软件,允许用户提出和回答这个问题:“嗨,你在哪儿?”(类似软件: Loopt)

3. Textfree Unlimited
通过推送通知提供免费手机短息服务。

4. Bento
通过创建简单数据库存储生活中的各种信息。

5. TweetDeck
令人惊艳的Twitter客户端。(类似: Tweetie, Twinkle, TwitterFON)

6. 打印和共享(Print and Share)
直接通过手机摄像头在家庭打印机上打印文件、email、网页、联系人、图片和截图。

7. 航班跟踪器
即时查看航班信息。

8. 稍后阅读(Read It Later)
存储网页,供稍后离线阅读。

9. iEmoji
在emai和短信中插入丰富的表情。接收方无需安装该软件。

10. 生日提醒(Birthday Reminder)
离线查看Facebook好友的生日信息。

11. Mover
和其它iPhone用户交换联系人和图片。

12. Simplify Music 2
从家用电脑上收听iPhone上所有音乐,快捷,没有时滞。

13. Cell Minute Tracker
帮助用户管理用户数据(短信、通话和账单等)。

14. QuickOffice
编辑Word、Excel文档。

15. Photogene
图片编辑器。支持剪切、旋转、调色、添加滤层。

16. Skype
通过WiFi进行高质量Skype会话。

17. Kindle
提供很多免费图书,但不能替代你的Kindle。

18. Beejive IM 3.0
iPhone上最好的即时通讯工具。

19. Redlaser
通过手机扫面产品代码,进行价格比较。

 

最佳游戏软件

20. Real Racing
赛车游戏。

21. 模拟人生3(Sims 3)
对《模拟人生3》进行了少量简化,画质优美,运行流畅。

22. My Brute
格斗类游戏。

23. Mecho Wars
战争游戏。

24. Zenonia
第一款iPhone上的二维RPG游戏。

25. Peggle
一款弹珠游戏。

26. Marble Blast Mobile
球类游戏。

27. 神秘岛(Myst)
神秘岛。

28. Merlin’s Legacy
一款融合了RPG和塔防元素的游戏。

29. 刺客信条(Assassin’s Creed)
iPhone版《刺客信条》。

30. 俄勒冈小路Oregon Trail
一款反映早期西部生活的游戏。

31. 奥兰多2(Rolando 2)
闯关游戏。

 

消遣类游戏

32. 涂鸦跳跃(Doodle Jump
一款类似下楼梯的游戏。

33. 自吹自擂(Mouth Off)
把手机放到你的嘴巴前面,然后就可以得到卡通版照片。

34. 口袋上帝(Pocket God)
让你扮演上帝,决定几个岛民的命运。

35. 飞行控制(Flight Control)
一款飞行模拟游戏。

创业板

2009年08月04日

许多大流量的网站都是由Rails支撑的,《WEB开发之道——应用RAILS进行敏捷WEB开发》(第二版) 这本书对于扩展你的应用是非常有帮助的.这个系列的文章是一个实际的例子,例子说明了“如何扩展你的Rail应用?”我会讲述一下我们在提高应用性能时所作的事情。

我们的整个性能调优过程,将分四篇文章来讲述,每一篇都是在我们扩展我们eins.de网站的一个里程碑。文章计划在一周内全部发表出来。

 

实际情况

我们的任务是重写全部代码,这个在线社区网络eins.de以前是用php写的,原来是一个代码膨胀而且架构的非常糟糕!作为一个在线社区,正如你知道的一样,网站包含如下功能:论坛、评论、个人主页、个人站内消息、编辑内容等等。另外,eins.de在德国的几个大城市都有当地的合作伙伴,他们是各个子版块的重要驱动力。各地的用户是在一个统一的单个数据集中。

原有代码大概由5万行php代码和另外一个闭源的CMS组成(CMS不计入代码行数统计中)组成。这次重写大概只用了5千行Rails代码,就实现原来的大部分功能(原来的一些个功能按计划在这此重写中被剔除了)。

eins.de 每天包含大概120万个动态页面,服务于25个子社区,每个社区是用不同的域名,但所有这些都在一个Rails应用中。然而,还没有到今年的二月,我们对系统配置和代码都做了优化,这样在才能处理如此巨大的流量。

这个网站存在许多动态页面和信息,动态信息是基于用户设置或像在线状态和相互关系状态。这些都是阻碍我们使用Rails本身提供的非常简单的页面缓存或局部缓存。

该应用服务器配置是dual Xeon 3.06GHz, 2GB RAM, SCSI U320 HDDs RAID-1.数据库服务器dual Xeon 3.06GHz, 4GB RAM, SCSI U320 HDDs RAID-1. 代理服务器是单台 P4 3.0GHz, 2GB RAM, SCSI U320 HDDs RAID-1.

在不改变硬件条件的前提下,我想准备通过配置优化和修改代码来提高性能,与此同时还要加上一些新功能。

在11月,我们最高每天能够支撑75w的PV(大约有60G的流量),到了来年的3月份,我们很轻松的能够支撑120w的PV(大约有100G的流量),最终性能提升了1.6倍。(译者评:技术真的都变成钱了啊!)

高峰时期通大概20M/每秒的数据通过代理服务器的网卡。(译者评:饿滴神)

dcfq8s4f_8dz9h9xhg
well,任何人都不能改变历史,以下是我们以前的系统配置,也就是上面这个图中所示的软件的详细信息。

  • Debian 3.1
  • Kernel 2.4.27
  • lighttpd 1.4.6
  • Ruby 1.8.3 from Debian packages
  • MySQL 5.0.16 from Debian packages
  • Rails 0.14.3 from RubyGems
  • Ruby-MySQL 2.7 from RubyGems
  • Ruby-MemCache 0.0.4

    我们使用Rails中的 ActiveRecodStore来管理session,用 在数据库服务器上的token based single-signon 机制和 memcached来在内存中存储大数据量的计算。

    两台数据库服务器通过master-master的方式相互复制,他们的自增ID是相互间隔的。(译者评:比如,一台的ID增长是1、3、5,另一台是2、4、6).具体实现参看《mysql手册》的auto_increment_incrementauto_increment_offset.

    haproxy 被用于外部的FastCGI 侦听的负载均衡,以及应用服务器的数据库链接通过它分发到两台数据库服务器上。

    以 上基本上是一个总体的介绍,性能的优化是非常难的一件事情。基于PHP的老系统处理到90万PV时就会崩溃(这就是说,只要以前一半的应用服务器就行 了),而新的架构在巨大的150万PV的时候才会崩溃。这里面不存在突然会变成你所想像的那样好,所有这些变化都在此以前用了无数的日日夜夜coding 才达到的。

    紧急情况设计
    是的,我们曾经正在缴费准备飞到巴哈马群岛,并呆在那。

    FastCGI 监听数目作为首要的方法从20下降到了10.说实话,原来系统的设置根本没法用.页面每次从开始load都有延迟,与此同时,对于系统做大可支持的负载的 失望和一些没有耐心的用户还会重复load让事情变得更糟。用新的设置,这些事情会减少一些,而且快了许多。

    过了几天,在新系统上线后,我们又采用了其它几个方法来提高性能,并且修复了一些在测试中没找到的bug.睡觉是多么美好和奢侈的啊。

    我们做的几件重要的事情,使得这次升级更加成功:
    >强烈指出haproxy,它仍有另外的变量能更调整,直接使用它并不会有明显的效果。所有应用服务器对于Mysql的链接都可以在文件中配置成像连接单个Mysql主机。
    FastCGI 连接的分发由lighttpd返回。提示:我们发现要想请求真正均匀的分配到多台应用服务器上,你应该定制fastcgi。服务器的端口和IP的配置应该如下:

    "http-1-01" => ( "host" => "10.10.1.10", "port" => 7000 ),
    
    "http-2-01" => ( "host" => "10.10.1.11", "port" => 7000 ),
    
    "http-3-01" => ( "host" => "10.10.1.12", "port" => 7000 ),
    
    "http-4-01" => ( "host" => "10.10.1.13", "port" => 7000 ),
    
    "http-1-02" => ( "host" => "10.10.1.10", "port" => 7001 ),
    
    "http-2-02" => ( "host" => "10.10.1.11", "port" => 7001 ),
    
    "http-3-02" => ( "host" => "10.10.1.12", "port" => 7001 ),
    
    "http-4-02" => ( "host" => "10.10.1.13", "port" => 7001 ),

    >虽然局部缓存被认为对于用户是不灵活的(数据延迟,不再个性化),并且没有改进,但是还是要使用它。毕竟稍后问题都有反馈。
    >停止同时使用两个memcached主机的想法,由于Ruby-MemCache库显然不能很好地处理。实现分布式的方式不是基于一个key,而是随机。让我们最头疼的就是分布式垃圾数据的到期问题。
    >重构了工具条的代码,原来这段代码是用Rails中的component,有显示它是性能杀手。一般可以为每一个sidebar的显示设置完整的controller环境。(具体参见 RailsExpress)
    >添加gzip的压缩作为after_filter(参见Rails 书中的例子)
    >用Mysql slow query log参数来找出速度慢的sql语句,减少表的joins,优化索引。(呵呵,这个显然不是Rails的范围)

    这时候已经到了11月,这个时候我们每天可以处理85万PV,似乎没做什么事情,你可以说“太简单了!”

    我们新的简化过的设计如下:

    dcfq8s4f_9gr2zs4nv

    第二部分将会着重讲述性能调优,包括mysql调优小技巧,FastGCI 请求分派调优,和更多的系统优化技术。

    圣诞节前

    11月份,仍然还在旧系统的框架下,一些新的想法还是出的比较慢。

    这并不能说是一次失败,我们尝试将一些可能的影响性能的因素都做了调整。

    首先,我们用源码重新编译 了Ruby,而不是使用Debian系统提供的二进制包。Debian有些时候基于某种考虑打了一些不太正规的补丁。在某些情况下,这样不失为一种好办 法,然而为了性能,我们还是从源码重新安装了Ruby,甚至安装了专为i686优化过的libc6包。

    与此同时,我们还将Debian提供的Mysql二进制包,改成了Mysql官方提供的安装包,并且将版本从5.0.16升级到5.0.17。

    (译者评:Debian/Ubuntu这类linux发行版中,还是自己编译吧)

    一般说来,Mysql5已经被证明是非常稳定的产品。我们曾经碰到过一点点数据同步复制 的问题(master-master中有出现重复自增ID的情况,这个在5.0.19中已经修复了这个bug),但有时候Mysql数据库每秒中查询达到 2000-3000次的时候,后台守护进程经常会在几个月内崩溃一两次。

    让我们具体谈谈Mysql吧


    如果针对数据库的配置错误或者优化不好的话,它很容易拖慢整个系统。有许多书都是专门讲数据库优化的比如whole bookswebinars 。我在这里就简单的介绍一下。

    eins.de利用了Mysql的 全文检索 Full TEXT来做搜索功能。MyISAM存储引擎不能支持事务。你可以用InnoDB和MyISAM两种引擎结合起来用。

    解决问题有一下几个办法:

    1.另买一台数据库服务器,用MySIAM类型的表,然后从类型是InnoDB的 Master数据库表中(我听说Flickr是这么做的)。然而这样就需要仔细的设计程序,得以突破Rails的局限性,Rails不能很好的区分读数据 库和写数据库。即便能这么弄,我们也不会走这条技术路线,因为我们没有预算来买第三台数据库服务器。

    2.不去使用全文检索, 可以使用类似Ruby-Odeum 这样的搜索引擎。这里面比较头疼的是,如何让数据库地更新时,同时搜索引擎索引也重建索引保持数据同步。这条路我们也不选择。

    这样我们最终使用了一种混合的方式。

    当前,可用的内存有4G,将它分成InnoDB和MyISAM两部份。2/3的内存给InnoDB用(因为这系统主要的表用的是InnDB,还用于缓存MyISM表的索引数据)

    剩下的1/3是给MyISAM的。另外,我们使用了查询SQL结果的大缓存,也就是Mysql中的query cache。(这个参数是否被用起来了可以通过Mysql的show status命令来看)

    我们数据库参数设置如下:

    key_buffer=700M

    myisam_sort_buffer_size=128M

    query_cache_size=64M

    innodb_buffer_pool_size=1600M

    如果前端的分发器是单个服务器,并且是持久连接,数据库连接数的参数设置就没有什么必要了。

    继续进行应用服务器的优化

    对于系统进行反复的研究找出一共有多少请求是非常有用的。这个是没有“一劳永逸”的解决办法。一般说来,你需要包含系统高峰时期并且不能当机,如此大量的线程并行运行以至于机器变慢,这是因为对于CPU来说线程相互之间是阻塞的。

    以前我们在每台服务器上设置20个并发时,系统的负载一般都是在30或30以上。事情进展的非常顺利,我们降低了并发数量。这样的效果非常明显。

    通过简单的计算,我们从一天PV数量计算出整个的监听数量。eins.de那时大概每天100万PV,所有的用户都在同一个时区,访问遍布在一天的14个小时中(从早上9点到晚上11点)。我们再做一个简单的计算:

    1M page requrest / 14 hours = 20 requests per second

    假设系统平均处理每个页面请求都会少于1秒中,那么我们需要20个并发进程来监听请求。以上计算是根据平均值进行的,为了能够处理高峰时的峰值,我们将每台应用服务器的监听数目从10减小到7,这样四台应用服务器加起来一共有28个监听,应该能满足当前压力的要求。

    (译者评:一般峰值是平均值的5-10倍,根据各自的网站特点来确定)


    另外,每台机器上安装的Rails从0.14.4逐步升级到了1.0.虽然这对性能不一定有帮助,但是说不定是有用的。

    到了11月中旬,据报道Linux 内核2.6对于性能、内存管理和进程管理等等都是非常好的,因此我们将所有的系统的内核从2.4.27升级到了2.6.14。

    大家对这个内核升级对性能的提升将信将疑,后来根据监控软件Cacti的显示,系统升级后确实提高了不少。数据库服务器虽然提高不少,但应用服务器的负载却

    下降得非常明显。记录显示内核的升级使得系统在高峰时期的负载从8降到了5。

    升级内核所取得的效果让我们有了些兴奋,我们继续所做的事情是将应用服务器的压力再次给到两台数据库服务器上。在此以前,所有的压力都是由一台机器支撑的,另外一台只是安静的呆在那儿复制主力数据库的数据,仅仅是主力坏了它来顶上的灾难恢复而存在的。

    我们没有去考虑haproxy的灾难恢复,只是简单的将请求按照2:1的比率分配到两台数据库服务器上。

    在写的压力很大的时候,偶尔会出现两台数据库同步不能跟上的问题,直到 一台的写处理完才能恢复。如果碰上几秒钟这种倒霉的事情,一个用户可能一次请求在一台数据库服务器上,而另外一次则在另一台上,这样就比较尴尬。举一个最 糟糕的例子,AJAX开始的时候请求了一台机器,而后AJAX执行的操作却从另外一台获得,数据是不同步的造成了混乱。

    为了减少写操作,我们经用户证明发现在用户没有获取任何有用数据的时候,系统不仅通过ActiveRecordStore 更新了session,而且更新了用户的在线状态表和token数据。事实是,虽然多个MySQL线程能够更新多张表(甚至能通过InnoDB的行级锁来 一次更新一张表里面的多行),但是你只能有一个线程来处理将所有的写操作写到另外一台服务器上。这个问题困扰了我们不止一次。

    另外,我们将缓存memcached在两个数据库上移来移去以更好的分摊机器的压力,让另外一台机器来处理广告信息phpAdsNew(译者评:一个广告投放系统)

    在11月底,我们完成了以上这些事情,到目前为止我们已经多次达到了百万PV的情况,流量每天已经达到了85G。

    整个系统配置如下:

    dcfq8s4f_10g6dt93fw

    到此系统调优的文章已经写了2/3,后续文章将会包括memcached的最佳实践,session的优化以及更多系统优化技术。

    第三篇 新年了

    随着圣诞和新年的来临,我们准备从另外一个方面来改变和优化系统以提高网站的性能和响应速度。(从以往看来节日期间是我们流量比较小的时候,人们更愿意花时间跟家人团聚而非泡在社区里)

    ×××,再次回到memcaced的优化上来了。通过debug发现了我们 memcache封装的问题(它是负责通过key来自动查找社区名和用户名,或者社区名或用户名),许多在memcached的查找都失败了。查找本身并 没有失败,而是从memcached中返回的对象实例有部分“失败”了。

    这句话什么意思?也就是说花费时间很长的计算结果被放到了缓存中,但是重新从缓存中获得它们的时候失败了。结果再次从新计算(这时memcache封装里面的一个回退机制)。因此没有达到我们认为的节省时间、降低负载的效果。

    然而,这个跟先于对象定义的Ruby声明的类没有关系,显然和返回的marshalled数据有关。在Google上面搜索了这个错误信息没发现任何明显犯同样错误的人,也没有任何解决办法。

    (译者评:看看别人解决问题的过程比知道优化技巧这样的结果更加重要,比如作者也走过很多盲目的弯路,但这些弯路也是思考问题的方式

    通过查看Debian的更新日志提到了一些 Ruby 1.8.4关于marshalling,并一次同时在Rubyonrails.org’s download page 看到了如下信息:

    We recommend Ruby 1.8.4 for use with Rails. Ruby 1.8.2 is fine too, but version 1.8.3 is not.

    因此升级了Ruby,我们从升级到了1.8.4,重新编译了所有C扩展的的包,比如Ruby-MySQL和RMagick,然后上线看看。

    结果是没有变化!

    接着在一月的第三个星期,Robot Coop 发布了他们的memcache-client 库,作为Ruby-Memcache的替代,现在后者的开发停止多时了。

    使用新的memcache-client库系统运行得非常流畅。它甚至做了我们自己封装的memcached包装器的大部分工作,请大家为Robot Coop的工作欢呼三次,太伟大了!

    由于有了如此好性能的memcahced我们冒险向前走了另外一步。我们将session的存储从 ActiveRecordStore(读Mysql表的存储)移到了memcached中。我们希望通过这样做也是为了减少前面所述的Master- Master模式中只有一个线程往另一个Master中写的压力。同时,这样也能将每次请求页面而需要到数据库的比例比11月份上线时减少了1/3。

    另外通过Robot Coop memcache 客户端我们可以有理由去跨多台机器做分布式缓存。memcached对于我们大部分的机器无论是在内存消耗上,还是CPU使用上都是非常不错的。
    我们临时将所有机器都配置上memcache来应对它的连接数问题。为什么说是临时的?因为我们有个登录问题需要debug出来。有时侯我们不能去再次使用我们自己的机器。用户像是坐在一个很大的公司中,有太过敏感的防火墙和内容过滤器,以至于其它人不能再登录进来。
    许多问题随之被发现了,他们甚至没有看见我们种的且将过期时间设置为2010年的cookies。为了让他们看见,我们甚至尝试换个cookie名字(这样做是为了想避免一个自己的胡乱猜测,什么以session命名的cookies会在浏览器关闭的时候就自动过期)
    (译者评:笑可笑之人,有时候找不到问题,不就是根据自己一点点经验去胡乱尝试么?这也是技术的一部分)

    多台机器分布式的memcached的配置和session的存储有过什么联系么?哦,天知道?最后没有人清楚的记得当用户登录正常时,是不是我们只是做了将用memcached做session存储这一件事让它的好的。(这一个改变对于我们系统减轻了许多压力)

    为 了简化调试(也为了减少潜在的隐患)我们又返回去用单台机器配置一个memcached和一个MySQL的做法。memcached放在一台(只做数据同 步和广告服务)比较空闲的数据库服务器上。顺便提一下memcached的配置非常简单。经常需要去变的参数是分配的内存大小,需要记住的是分配的内存可 以很大,但memcached也必须去调度这么大的内存空间。到了一定时候它将会到达它的极限。我们当前给memcache了1024M的内存空间,这个 对于文本信息绰绰有余。

    这是基于我们系统7周时间的memcached的统计数据。(不要问过关于二进制字节的读写比率,我认为这是颠倒的???)

    get_misses: 59,571,775
    
    get_hits: 235,552,563
    
    total_connections: 2,002,697
    
    bytes_read: 79,799,051,834
    
    bytes_written: 734,299,301,670
    
    curr_items: 1,421,982
    
    total_items: 76,452,455
    
    cmd_set: 76,453,343
    
    cmd_get: 295,124,338
    
    bytes: 717,612,826登录的错误也在不久以后解决了,原因是当关闭浏览器的时候cookie就过期了。无论什么原因?这个问题的解决没有太多的逻辑推理。仅仅是找一种便于管理的
    
    折中办法才行。
    
    (译者评:对称是种美,与其将cache散落到各处,不如简单点让一台没有压力的机器单独来承担。不对称也是一种美,两台数据库服务器,只在一台上装了
    
    memcached)
    
    
    

    出现新的访问速度变慢的问题

    在一月份的前半个月我们一天就可以支撑110万的流量,此时的流量达到了95G。接着到了一月份的后半个月系统出现问题,几乎不能工作了。虽然以前我们所做的所有修改和调优(原本这些都非常好),但我们碰到了新问题,发现系统在变慢。

    是 正常的变慢,还是糟糕的变慢?实际上是不好的变慢。到了一月份的最后一周变得跟去年11月份一样慢了。为什么会这样?哦,这是一个好问题。我们已经优化了 系统的每一个部分(如果你读完了这一系列文章,你也应该清楚)。在过去的几周内,事情看上去都不错,但现在我们又回到了开始时那样。

    先还是把系统结构图图画出来吧,这样清楚些,不如从图中找问题。(译者评:我就是在机器上傻看数据,退一步看看整个架构更容易发现问题)
    我 们首先发现是整个系统全部变慢,甚至有时候不能访问,但所有的机器压力还是很小,应该说是太小了。调整lighttpd的fastcig。debug发现 侦听虽被指定去处理连接,但是它坐在那里一动不动。当有一般的请求焊死在那里,这再明显不过是说它不能响应所有的请求。

    (对于这些似乎你很眼熟,我以前在poocs.net写过一篇文章叫“温柔地杀死我”)

    使 用tpcdump来监控侦听端口的流量,什么也没有,没有一个字节通过管道。使用strace来看看那些忙一些的侦听在干什么,它们在wait,也没有做 任何事情。郁闷的是,如果你重启lighttpd或者×××,最终和开始看到的一样。我的同事对防火墙做了各种配置,我开始调整应用服务器和 lighttpd代理服务器的/proc的参数,我猜测是到了某个参数的上限。用netstat也发现有几百个连接在那些管道中,状态都是 TIME_WAIT和CLOSE_WAIT,很像遭受了synflooed攻击。但这是我们内部机器,不会被外面看到。下一步,根据公共可利用的资源来调 整/proc中的参数,具体如下:

    
    
    echo "1024 65535" > /proc/sys/net/ipv4/ip_local_port_range
    
    echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
    
    echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
    
    echo 1800000 > /proc/sys/net/ipv4/tcp_max_tw_buckets
    
    echo 256000 > /proc/sys/net/ipv4/tcp_max_syn_backlog
    
    echo 1024 > /proc/sys/net/core/somaxconn
    
    echo "128000 200000 262144" > /proc/sys/net/ipv4/tcp_mem
    
    echo 2097152 > /proc/sys/fs/file-max
    
    echo 0 > /proc/sys/net/ipv4/tcp_timestamps
    
    echo 0 > /proc/sys/net/ipv4/tcp_window_scaling
    不要在家使用这些命令,因为它一点都没有帮到我们。请求始终停在那,网站的性能让人看上去恶心。另外一个人企图在每个应用服务器上都启动一个lighttp
    
    (这样来代替远程的fastcgi侦听),然后放一个lighttp的负载均衡的方向代理在前面。事实证明系统还是慢。
    
    剩下比较“土”的办法,我写了一个脚本来搜索所有的可用侦听,如果它们在一定周期内没有响应,就kill它。被kill的请求会有Rails的spinner/spawner很快的重新
    
    启动,lighttpd只是多花几秒钟来重新连接socket。虽然对于业务来说不能持续的来监控它们了。
    
    这个方法虽然看上去不漂亮,但它工作的很好,并且让我们熬过了一月来到了二月,配置如下:
    February

    剩下最后一篇是关于系统扩展性的问题,也总结一下,哪些有帮助,哪些没有,同时展望一下将来系统调优的计划。

    第四篇 速度快和稳定

    在2005年的11月至2006年的3月,许多优化的工作都在这期间完成。这里面不少工 作都不得不变成了配置的一部分(比如第三篇提到的请求分发的监控脚本)。最终经过了几周的运行,这个网站被证明是稳定且速度快的。另外,我们也已经能完成 一点从用户和社区运营人员那里的需求。

    完成过程中的闪光点

    二月份,一些小的调整让系统性能变得更好。

    第一,当用户编写个人消息和在论坛发帖时,我们利用AJAX来对其内容进行预览。虽然这不是性能的杀手,但把这因素剔除来减轻压力是有意思的。呃,在AOL浏览器中prototype会崩溃。

    另外,将作为lighttpd守护进程对待。这样崩溃的现象在1.4.8及以后的版本就很少出现了,但仍然需要监控进程的情况。要知道如果lighttpd down了整个网站就down了。所以得看好它。(译者评:这里可能会出现单点失败的情况,clear & dirty)

    lighttpd作为daemontools 来跑是非常简单的。简单配置以后(具体配置这些写得很清楚 http://www.thedjbway.org/daemontools.html)你在ROR的service树下面用一行脚本来用damontools 配置lighttpd服务。你会知道并且爱上Rails最初的script/server。

    #!/bin/sh

    /usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

    这样就启动好就运行了。你可以通过lighttpd的配置来简单的设置一下,发送 lighttpd的进程ID或这信号SIGINT到你后台的监控中。然后需要注意的是如果你的网站流量非常大就需要把那些不能再完成了服务请求通过 SIGKILL杀死。新发布的lighttpd1.4.11分发请求时候的僵死越来越少了,似乎这种情况完全没了。但我们将继续通过脚本监控它。

    到此是这一些列文章的结束了。现在服务器每天支撑1.2M的PV(100GB的流量)。

    March

    总结以及以后的计划

    以下是这四个月被证明是非常有用的优化手段:

    系统优化:

    >使用Linux 2.6代替2.4

    >使用自己编译的Ruby 1.8.4

    >使用Mysql官方的二进制版本

    >使用lighttpd 1.4.11代替以前的

    >使用memcache-client代替Ruby-MemCache

    >使用了更少数量的dispatchers

    >并且监控你的dispathchers

    代码优化:

    >避免使用ROR的组建 components

    >用memcached储存费时的计算

    >用memcached来存储session

    >如果你的站点很受欢迎就不要使用live-previews

    >使用异常通知exception notification来捕捉可能的异常

    另外不要完全相信这些总结。优化是一个发展中的东西。

    你需要一直对网站进行监控,包括你的服务器和所有相关的软件。

    强烈建议不仅仅只监控服务是否起来了,还好监控服务器的压力,响应时间等等。用Nagios和Cacti结合起来做这些工作被我们证明是很有用的。

    提 醒注意的是,需要读读所有你使用的软件包的改变日志,看看新的版本中解决了什么已经存在的问题,可能产生哪些新问题。不需要强制升级所有的更新,但对你正 困扰的问题在新版本中别解决了,你就一定要升了。你可以在测试环境中进行测试,减少当机时间,避免升级带来的潜在问题。

    请留心你网站代码的变化。一般来说,应该多想想我要做什么。一个像Rails这样聪明的框架会让你有机会去思考,而不是每天写些重复性的代码。要聪明的使用时间。

    一条SQL语句或单个循环可能在你开发用的笔记本上跑的很快,但是在产品环境中同时并发执行成百上千次或产品中数据量比较大都有可能导致网站变慢。

    性能调优准则
    总的来说,不太容易把网站的性能调节好。
    一种方式是让网站处于非生产状态,也就是测试状态,自己产生一些流量来测试,这样的流量不同于真实的用户产生的流量。这样模拟的网站数据集也不同于线上的正式产品。这种情况下所有的调优结果都要根据线上真实网站的情况进行一下转换。
    另 一种方式是对线上实际网站逐步地进行性能调优。这样有许多好处,你有真实的用户在使用你的功能,使用你的系统,正如数据一样所有这些都是真实的,比测试环 境有价值的多。但这种方式主要问题是,如果你的网站访问量特别大,系统的日志production.log将会大量快速的被写到硬盘上,这样你就很难找到 问题。如果做日志的分离,将实际的日志相互关联起来也不太容易。那么将日志重定向成系统日志Syslog(通过 SysLogger,在Rails Analyzer Tools包里面),它能将每个日志同一个线程ID关系,这样就非常方便了。

    写大文件的日志意味这你整个系统的IO补偿糟糕,如果你在产品环境中不要写太多太详细的日志,系统将会比你测试的结果跑得好得多。
    哦,当网站调优时,拆分用户将会有比较好的效果,但更重要是的要不断听声网站的使用体验。

    使用过的工具:
    将前面提到的Rails Analyzer Tools 包放在手边,这些工具在类UNIX系统里面非常管用。你还需要会几个命令,cat,tail,grep,awk,ps,netstat。另外,安装一下ngrep和tcpdump来debug网络流量,还可以用mytop来查看Mysql线程列表。

    把这些都准备好需要一些时间、耐心和知识,也偶尔需要Google搜索一下。

    将来还要处理的事情

    随着memcache-client库的发布,Robot Coop公司又发布了另一个小的库,名字叫做cached_model ,这是基于memcached用于减轻数据库重复查询,原理就是在查询之前通过子类Active::Base来检查memcached中的内容。

    我在1.0版本它出现的时候,看过一下,觉得还是很有发展的。那个时候它不能很好的集成,经常胡乱抛错。由于当时我们忙于调试其它的问题,就没有仔细地去 解决这些问题。在此期间,cached_model版本升级到了1.1.0,也修复了多个bug。这个东西也将包括与我们将来优化的路线图当中了。

    在第三篇的时候我们碰到了一个“分发请求僵住”的问题,我们将回来再看看FastCGI ,更通常的办法是用lighttpd也支持的SCGI。

    有Zed Shaw发布了新的软件Mongrel 已经开始出售了。它作为“比WEBrick”更好的应用服务器,将纯HTTP放到FastCGI中,非常值得多看看。在读者评论中

    有人说早期Dan Kubb提到用Canditional GET ,它的潜在好处是在缓存页面不变时它可以用浏览器来缓存页面。我只是简单地看了一下它的标题,Rails插件看上去还不错,很容易集成进来。

    有个比较大的变化,尽管我曾经提倡使用Mysql的全文检索,但现在我正在基于Rails的一个搜索插件工作,它很容易无缝滴集成到Hyper Estraier 搜索引擎中。如果它跑的很好(性能好和数据保护),我们将丢掉全文检索,弄一个纯InnoDB的数据库配置,并且向锁表和非事务的测试说再见了,同时这样也不能使用ROR的schema.rb了。

    说道这里,我们升级到了了最近的Rails1.1。尽管这次升级对于性能并没有太大的必要,但是它有另外受欢迎的地方,它使得我们代码变得漂亮简介了。

    谢谢看过这一系列文章的人们。我真诚的希望我对我们案例的详细描述能够避免再去做我们已经做好了的一些研究和调试工作。如果你需要任何帮助,只要记下我的email,通过联系limited overload我可以作为咨询顾问来帮助你。