Performance

客户端应该去计算什么?

| Security | #performance | #scalability

这是一个很有意思的话题:随着计算机技术的发展,客户端的计算能力越来越强。想要提高在服务器端运行的系统的负载能力,最直接有效的办法就是把计算任务尽可能交给客户端去做,并减少两者之间的交互;然而,另一方面,这样做又可能会带来一些其他问题,例如,客户端完成某些计算任务的时候可能会比较慢(因为在客户端可以用到的资源比较少,想要保持兼容性最好的办法就是只使用普适的Java Script子集),或者,作为安全系统的一个最基本的原则,任何来自外界的数据都是不应被信任的,等等。

阅读全文…( 本文约 999 字,阅读大致需要 2 分钟 )

改一行代码带来的性能改进

FreeBSD先前的vesa framebuffer驱动有个问题,就是滚屏的时候会比较慢。jkim大长辈于是改了一行代码

好吧,我承认我之前一直以为是console驱动想要锁&Giant的问题。其实真正的原因是默认的pmap_mapdev并不做写合并,所以应该呼叫更低阶的pmap_mapdev_attr并传入PAT_WRITE_COMBINING参数。

阅读全文…( 本文约 230 字,阅读大致需要 1 分钟 )

可伸缩性 Scalability

关于Scalability这个词的中文译法,目前还没有一个非常确切的定论。一些文献中将其翻译为"可扩充性",而"扩充"指的主要是Scale up;而在一些实际的用法中,Scalability还包括Scale down,因此,“可伸缩性"也许是比较贴近原文意思的说法。

互联网应用的可扩充性体现在两个方面:其一,是能够对系统容量进行扩充,也就是说,这个系统各个组件能够提供的服务的量,能够在需要的时候予以扩充(特别是通过添加新的服务器等等)。其二,是这种扩充是有效率的扩充,即,增加硬件投入时,其投入与所产生的效果是接近甚至达到成比例增加的。通常说来,“可扩充"同时暗含的需求是用户的使用习惯尽可能保持不变。如果我们关注某一具体的计算节点,可扩充性还应体现于提高计算节点性能,例如增加其CPU数量或内存容量时,能够相应地改善系统的容量或响应时间,等等。

而另一方面,“可缩减性"主要指的则是说一套系统能够运行在尽可能少的软硬件环境之中。对于大型互联网公司而言,这一点可能并不重要,而对初创公司来说这一点则非常重要。

在设计互联网应用的时候,充分地考虑系统的可伸缩性,能够极大地减少日后的维护开销,并帮助决策者对于投资所能获得的回报进行更加精准的估计;另一方面,高可伸缩性的系统往往会具有更好的容灾能力,从而提供更好的用户体验。

与解决很多其他问题类似,改善可伸缩性最常用的方法就是分治法(Divide and Conquer)。分治属于大道理一类,在实践中,我们比较常用的分治策略包括:

阅读全文…( 本文约 2100 字,阅读大致需要 5 分钟 )

关于大量静态页的想法

上次在MeetBSD的时候Tim提到了一种处理大量静态页的办法。今天看Squid开发人员在NYC的BSD活动上的一个演讲里面也介绍了各种方法处理I/O的区别。

阅读全文…( 本文约 238 字,阅读大致需要 1 分钟 )

MeetBSD 2008 (1)

今天起了一个大早,9:00到了位于 1600 Amphitheatre ParkwayGoogle 总部。

手头没有精确的人数统计,不过目测来看,大概有120-150人。看到的第一个见过照片的人是著名的 Cameraman 同学, DragonFly 的 Matthew Dillon 老大!

由于今年是 FreeBSD 计划成立15周年,今年的 MeetBSD ‘08 California 很大程度上是一次 FreeBSD 的活动。

阅读全文…( 本文约 1462 字,阅读大致需要 3 分钟 )

YSlow

| Development | #performance | #website

An elegant tool for analysis of your website regarding its appearance slowness. Why is it slow?

What you need are:

参与评论

trac处理10万revision确实有点力不从心

| Development | #performance | #subversion | #trac

做了一个试验,导一个10万多revision的svn库进来到trac里面,结果整整一个上午过去了,才导了一半。估计得等到下班才能有结果了吧。。。

阅读全文…( 本文约 347 字,阅读大致需要 1 分钟 )