Hunter的大杂烩

十月 23, 2008

构建的可伸缩性和达到的性能:一个虚拟座谈会

类归于: 架构 — hunter @ 11:52 下午

from: http://www.infoq.com/cn/articles/scalability-panel

简摘:

问题1:许多人把性能和技术混为一谈。你们怎么回应这种误解呢?

…性能是服务于一个单独请求时的资源使用问题。可伸缩性是当要服务更多(或更大)请求时资源消费量如何随之增长的问题…

 — 这里可能有一个笔误,应该不是“技术”,而是“可伸缩性”

问题2:当你碰到性能瓶颈时,你如何开始调查是什么导致了这一问题?

通常是一个搜集观测资料(即,与许多人进行交谈)并缩小问题范围的过程..

…直觉(快速但不可靠,而且容易产生错误)和监测(需要预先的工作,但是这能让你随心所欲地分析问题)..

  — 我们一般会做较多的log和监控

(全文…)

可伸缩性原则

类归于: 架构 — hunter @ 11:03 下午

from: http://www.infoq.com/cn/articles/scalability-principles

来自Simon Brown的笔记:

1. 减少处理时间

    并置(含义):将相关数据放到一起

    缓存

    池化

    并行化

    分区处理

    远程处理:

          减少访问远程服务所花费的时间,比如可以通过更粗粒度地划分接口。远程还是本地是明确的设计决策,不能随意来回更动,这一点应当牢记。还要考虑分布式计算的第一准则——不要分布你的对象

            ^^^^^^^^^难难难,如何平衡,还在探索中 

          …尤其是在每层的数据表示之间都需要转换的情况下…

                                       ^^^^^^^^^^^^PO 2 DO ?

(全文…)

十月 21, 2008

97 Things Every Software Architect Should Know

类归于: 技术话题 — hunter @ 4:52 下午

from: http://97-things.near-time.net/wiki/97-things-every-software-architect-should-know-the-book

 

金牌作者、技术分析师Richard Monson-Haefel在自己网站上发布了“架构师必须知道的97件事”,简单翻译如下:

  (全文…)

十月 20, 2008

关于mysql 数据库表设计建议

类归于: 技术话题 — hunter @ 6:56 下午

1. 要有一个主键(int类型最好)

     —- 方便分表、分区

            不要用auto_incream来生成主键,这样当你分区扩展时会遇到大麻烦

2. 尽可能逆范式设计,多存储一些外联数据的信息;

     —- 减少关联查询,但是不要存储重要,跟业务逻辑相关的数据,最好只是纯粹展示用,要保留异步更新这些数据的能力;

3. 增加版本号和最后修改时间;

(全文…)

十月 19, 2008

讨论:为什么大多数社交软件会失败,又该如何避免

类归于: 技术话题 — hunter @ 1:40 下午

讨论内容见:http://www.infoq.com/cn/news/2008/08/why-social-software-fails

 

几个有意思的观点摘抄如下:

推出最少特性的软件往往大受欢迎

“所有用户都共享的简单心智模型”

“很容易就会陷入去做那些让单一用户的体验更好的事情,但这却会让用户关系网的体验更差。”

(全文…)

早前文章 »

WordPress 所驱动