阿姆达尔定律（英语：Amdahl's law，Amdahl's argument），一个计算机科学界的经验法则，因吉恩·阿姆达尔(Gene Amdahl)而得名。它代表了处理器平行运算之后效率提升的能力。

1967年计算机体系结构专家吉恩.阿姆达尔提出过一个定律阿姆达尔定律，说：在并行计算中用多处理器的应用加速受限于程序所需的串行时间百分比。譬如说，你的程序50%是串行的，其他一半可以并行，那么，最大的加速比就是2。不管你用多少处理器并行，这个加速比不可能提高。在这种情况下，改进串行算法可能比多核处理器并行更有效。

阅读全文

我们在监测Linux的应用的时候，当CPU的利用率非常高，但是系统的性能却上不去的时候，不妨监控一下线程/进程的切换，看看是不是context switching导致的overhead过高。

一般我使用dstat工具用来监控，比如dstat -y:

1
2
3
4
5

---system--
 int   csw 
 367   561 
 274   439 
 279   363

或者vmstat 3:

1
2
3
4

[root@abc smallnest]# vmstat 3
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 3126192  31692 1521612  0    0   176   325  166  258  1  1 96  3  0

但是如何知道那些进程/线程做切换能，淘宝褚霸有篇文章:latencytop深度了解你的Linux系统的延迟介绍了一种方法。事实上，有一个工具pidstat,可以用来监控上下文切换。 它是sysstat包其中的一个工具，sysstat包含好几个很棒的工具，比如sar、iostat等。

执行pidstat -w

1
2
3
4
5
6
7
8
9
10
11
12
13
14

root@abc smallnest]# pidstat -w
Linux 2.6.32-358.el6.x86_64 (abc) 	04/11/2016 	_x86_64_	(2 CPU)
11:25:00 PM       PID   cswch/s nvcswch/s  Command
11:25:00 PM         1      0.60      0.03  init
11:25:00 PM         2      0.04      0.00  kthreadd
11:25:00 PM         3      0.36      0.00  migration/0
11:25:00 PM         4      0.58      0.00  ksoftirqd/0
11:25:00 PM         5      0.01      0.00  migration/0
11:25:00 PM         6      0.08      0.00  watchdog/0
11:25:00 PM         7      0.39      0.00  migration/1
11:25:00 PM         8      0.01      0.00  migration/1
11:25:00 PM         9      0.52      0.00  ksoftirqd/1
……

cswch/s是主动地上下文切换，nvcswch/s是被动执行上下文切换的次数。

如要要显示线程的上下文切换统计，可以执行:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[root@abc smallnest]# pidstat -wt
Linux 2.6.32-358.el6.x86_64 (abc) 	04/11/2016 	_x86_64_	(2 CPU)
11:27:57 PM      TGID       TID   cswch/s nvcswch/s  Command
11:27:57 PM         1         -      0.56      0.03  init
11:27:57 PM         -         1      0.56      0.03  |__init
11:27:57 PM         2         -      0.03      0.00  kthreadd
11:27:57 PM         -         2      0.03      0.00  |__kthreadd
11:27:57 PM         3         -      0.34      0.00  migration/0
11:27:57 PM         -         3      0.34      0.00  |__migration/0
11:27:57 PM         4         -      0.57      0.00  ksoftirqd/0
11:27:57 PM         -         4      0.57      0.00  |__ksoftirqd/0
11:27:57 PM         5         -      0.01      0.00  migration/0
……

更多的参数可以man pidstat获得。

前几天我写了一篇文章: 超全的Go Http路由框架性能比较，利用Julien Schmidt实现的benchmark测试框架对几乎所有的go web框架的路由功能进行了比较。我本来以为对Go web框架的性能考察就告以段落了，直到我写了一段简单的代码测试Irsi，用来模拟实际产品中的处理，才发现了Julien Schmidt测试框架的问题。

这段代码是这样的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

package main
import (
	"fmt"
	"os"
	"strconv"
	"time"
    "github.com/kataras/iris"
)
func main() {
	api := iris.New()
	api.Get("/rest/hello", func(c *iris.Context) {
		sleepTime, _ := strconv.Atoi(os.Args[1])
		if sleepTime > 0 {
			time.Sleep(time.Duration(sleepTime) * time.Millisecond)
		}
		c.Text("Hello world")
	})
	api.Listen(":8080")
}

当我将实际业务的处理时间模拟为10毫秒的时候，使用100并发进行测试：
wrk -t16 -c100 -d30s http://127.0.0.1:8080/rest/hello，Iris吞吐率才达到97 requests/second。详细介绍可以看我的文章： iris 真的是最快的Golang 路由框架吗? 。

虽然Iris的作者很快做了修改，临时解决了这个问题，但是也促使我重新审视Julien Schmidt测试框架,也促使我实现了一个测试Go web framework benchmak的框架： Go web framework benchmark。

2016/04/12 updated: 现在Iris已经改成了fasthttp实现，性能超级好。

阅读全文

原文： Golang自动生成版本信息

需求

golang程序在build时自动生成版本信息，使用 ./helloworld –version可以查看版本和build时间

实现原理

使用链接选项-X设置一个二进制文件中可以访问的变量

阅读全文

依照我的前一篇文章（超全的Go Http路由框架性能比较）对各种Go http路由框架的比较， Iris明显胜出，它的性能远远超过其它Golang http路由框架。

但是，在真实的环境中，Iris真的就是最快的Golang http路由框架吗？

2016-04-05 更新： 我已经提交了一个Bug, 作者Makis已经做了一个临时的解决方案，性能已经恢复，所以准备使用Iris的读者不必担心。
根据我的测试，最新的Iris的测试如下：

1. 在业务逻辑需要10毫秒时，吞吐率可以达到9281 request/s
2. 在业务逻辑需要1000毫秒时，吞吐率可以达到95 request/s
   性能已经很不错了。

我会做一个其它路由框架的测试，看看其它的框架是否也有本文所说的问题。

阅读全文

使用Java的时候很容易得到线程的名字， 比如"Thread.currentThread().getName"，这样就可以进行一些监控操作或者设置线程相关的一些数据。当转向Golang开发的时候，却发现Go语言并没有提供获取当前goroutine id的操作。这是Golang的开发者故意为之，避免开发者滥用goroutine id实现goroutine local storage (类似java的"thread-local" storage)， 因为goroutine local storage很难进行垃圾回收。因此尽管以前暴露出了相应的方法，现在已经把它隐藏了。

Please don't use goroutine local storage. It's highly discouraged. In fact, IIRC, we used to expose Goid, but it is hidden since we don't want people to do this.

Potential problems include:

1. when goroutine goes away, its goroutine local storage won't be GCed. (you can get goid for the current goroutine, but you can't get a list of all running goroutines)
2. what if handler spawns goroutine itself? the new goroutine suddenly loses access to your goroutine local storage. You can guarantee that your own code won't spawn other goroutines,
   but in general you can't make sure the standard library or any 3rd party code won't do that.

thread local storage is invented to help reuse bad/legacy code that assumes global state, Go doesn't have legacy code like that, and you really should design your code so that state is passed explicitly and not as global (e.g. resort to goroutine local storage)

当然Go的这种隐藏的做法还是有争议的，有点因噎废食。在debug log的时候goroutine id是很好的一个监控信息。本文介绍了两种获取goroutine id的方法。

阅读全文

Vert.x是一个在JVM开发reactive应用的框架，可用于开发异步、可伸缩、高并发的Web应用(虽然不限于web应用)。其目的在于为JVM提供一个Node.js的替代方案。开发者可以通过它使用JavaScript、Ruby、Groovy、Java，甚至是混合语言来编写应用。
使用Vertx.x框架，可以用JavaScript、CoffeeScript、Ruby、Python、Groovy或Java开发应用程序的组件，最终应用程序可以是混合语言构建的。

本文试图揭示Vert.x的线程模型的应用，通过源代码分析Vert.x如何使用线程池处理请求的，以及比较Netty和Vert.x使用线程池的异同。

也许你觉得奇怪，默认启动一个Vert.x Verticle实例，它只用一个线程处理事件，在多核的情况下你需要创建多个Verticle实例以充分利用多个CPU Core的性能。

阅读全文

使用Go开发Web应用非常方便，它自己的路由器default request multiplexer超级简单，但是功能也有限，所幸net/http库的设计非常好，很容易实现自己定义的路由器，所以你如果在github搜一下，会找到很多的第三方的路由库。

但是这些路由库良莠不齐，尤其是早期实现的路由器，有些实现了很差的路由算法，有些没有仔细考虑内存的分配，导致垃圾回收的问题。

Julien Schmidt在实现HttpRouter库的时候将测试代码抽象出一个测试框架，用来测试Go的各种的路由器，测试的库相当的全。这个测试框架放在了github上。

对于架构师和Go Web开发人员来说，这个测试确实是一份值得参考的资料，在选择一款路由框架的时候非常有帮助。

路由是Go Web框架的一个功能，它可以将不同的URL映射到相应的处理方法上。一些库只实现了路由的功能，也有一些库实现了完整的Web框架的特性，如上下文管理，Session的维护，模版的处理，ORM等。本文只比较路由的性能。

阅读全文

一致性哈希最早由 MIT的 Karger 提出，在发表于1997年的论文 Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web， Karger et al 和合作者们提出了一致性哈希的概念(consistent hash)，用来解决分布式Cache的问题。这篇论文中提出在动态变化的Cache环境中，哈希算法应该满足的4个适应条件：：Balance(均衡)、Monotonicity(单调性)、Spread(分散性)、Load(负载)。

在分布式缓存系统中使用一致性哈希算法时，某个节点的添加和移除不会重新分配全部的缓存，而只会影响小部分的缓存系统，如果均衡性做的好的话，当添加一个节点时，会均匀地从其它节点移一部分缓存到新的节点上；当删除一个节点的时候，这个节点上的缓存会均匀地分配到其它活着的节点上。

一致性哈希缓存还被扩展到分布式存储系统上。数据被分成一组Shard,每个Shard由一个节点管理，当需要扩容时，我们可以添加新的节点，然后将其它Shard的一部分数据移动到这个节点上。比如我们有10个Shard的分布式存储系统，当前存储了120个数据，每个Shard存储了12个数据。当扩容成12个Shard时，我们从每个Shard上拿走2个数据，存入到新的两个Shard上,这样每个Shard都存储了10个数据，而整个过程中我们只移动了20/120=1/6的数据。

Karger 一致性哈希算法将每个节点(bucket)关联一个圆环上的一些随机点，对于一个键值，将其映射到圆环中的一个点上，然后按照顺时针方向找到第一个关联bucket的点，将值放入到这个bucke中。因此你需要存储一组bucket和它们的关联点，当bucket以及每个bucket的关联点很多的时候，你就需要多一点的内存来记录它。这个你经常在网上看到的介绍一致性哈希的算法(有些文章将节点均匀地分布在环上，比如节点1节点2节点3节点4节点1节点2节点3节点4……， 这是不对的，在这种情况下节点2挂掉后它上面的缓存全部转移给节点3了)。

其它的一致性算法还有Rendezvous hashing, 计算一个key应该放入到哪个bucket时，它使用哈希函数h(key,bucket)计算每个候选bucket的值，然后返回值最大的bucket。buckets比较多的时候耗时也较长，有人也提出了一些改进的方法，比如将bucket组织成tree的结构，但是在reblance的时候花费时间又长了。

Java程序员熟悉的Memcached的客户端Spymemcached、Xmemcached以及Folsom都提供了Ketama算法。其实Ketama算法最早于2007年用c 实现(libketama)，很多其它语言也实现了相同的算法，它是基于Karger 一致性哈希算法实现：

• 建立一组服务器的列表 (如: 1.2.3.4:11211, 5.6.7.8:11211, 9.8.7.6:11211)
• 为每个服务器节点计算一二百个哈希值
• 从概念上讲，这些数值被放入一个环上(continuum). (想象一个刻度为 0 到 2^32的时钟，这个时钟上就会散落着一些数字)
• 每一个数字关联一个服务器，所以服务器出现在这个环上的一些点上，它们是哈希分布的
• 为了找个一个Key应该放入哪个服务器，先哈希你的key，得到一个无符号整数, 沿着圆环找到和它相邻的最大的数，这个数对应的服务器就是被选择的服务器
• 对于靠近 2^32的 key, 因为没有超过它的数字点，按照圆环的原理，选择圆环中的第一个服务器。

以上两种算法可以处理节点增加和移除的情况。对于分布式存储系统，当一个节点失效时，我们并不期望它被移除，而是使用备份节点替换它，或者将它恢复起来，因为我们不期望丢掉它上面的数据。对于这种情况(节点可以扩容，但是不会移除节点)，Google的 John Lamping, Eric Veach提供一个高效的几乎不占用持久内存的算法： Jump Consistent Hash。

阅读全文

我创建了一个项目，用来比较Java memcached client的性能：Java-Memcached-Clients-Benchmark

spymemcached 和 xmemcached是Java中常用的Memcached的客户端。

spymemcached最早是由Dustin Sallings创建，至少从2006年就开始开发spymemcached，作为共同创建者加入到Couchbase以后到现在spymemcached由Couchbase来维护，2014年2月他加入了Google，兴趣也似乎转为了Golang。

xmemcached是原淘宝员工killme2008(庄晓丹, 花名“伯岩”)，现在在LeanCloud工作， killme2008的兴趣在于clojure。xmemcached也是一个历史悠久的项目了，1.2.5版发布于2010年。

Folsom是一个比较新的Java Memcached client,它是现在如日中天的正版流媒体音乐服务平台Spotify的工程师们创建的，并且应用于公司的平台中。因为新(2015年初才第一次提交)，所以多扯几句。Folsom基于Netty实现，并在编程风格也更现代，异步，链式调用，metrics，代码简洁而有效。由有丰富经验的工程师维护，并且深度应用于他们公司高并发的产品应用中，没有遇到什么问题，值得信赖。

spymemcached和xmemcached开发比较早，代码容易带有历史的包袱，但是因为它们已经广泛地应用于许多实际的项目中，开发人员比较熟悉。

spymemcached的项目描述是这样的:"A simple, asynchronous, single-threaded memcached client written in java. "， 异步和单线程是它的特点，单个的client只使用单个的IO线程，这有一个陷阱，如果你的应用中有很多线程，那么分配给spymemcached client的线程的CPU时间片可能很少，这会降低spymemcached性能。这一点xmemcached也好很多。

我还遇到过spymemcached的一个坑。

xmemcached我觉得有问题的是没有提供异步接口，尽管它有一些方法提供了xxxWithNoRely,但是实际并不是异步的编程方式，只是忽略了memcached的返回,因为你想想异步地处理get方法，没办法，只能自己再包装。而且我测试的时候发现setWithNoReply还不稳定，抛出异常。

Folsom API非常的现代，但是了解它的人不多，所以没有经过广大的人民群众的检验，或许还没有暴露问题，另外文档也缺乏，只能看它的API和单元测试了解它的使用。

我还增加了一个Go memcached客户端的测试 gomemcache， 它是目前最常用的Go的客户端库。因为Go语言编程风格的原因，它所有的操作都是同步的，业务访问可以通过goroutine的方式实现异步访问。

阅读全文