在Go web服务器中实现prefork和affinity

Apache服务器可是使用prefork技术,启动多个独立的进程,每个进程独立的处理http请求,不需要担心线程安全的问题。

This Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server that handles requests in a manner similar to Apache 1.3. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries. It is also the best MPM for isolating each request, so that a problem with a single request will not affect any other.

尽管prefork在处理高并发的情况下并不高效,但是作为一个技术,倒是有启发我们的地方。我最近在调研Go服务器的性能看到一段代码,很优雅的实现了prefork和affinity的的功能,特地抄写在本文中,看看他是怎么实现的。

阅读全文

使用visual studio code开发Go程序

在visual studio code 1.0发布之前我也曾多次尝试使用visual studio code开发Go程序,但是都放弃了,一是Go的插件还没发布或者不完善,而是vscode还不是那么方便,所以我一直使用atom + goplus + godebug编写Go的代码,而且用起来也非常的顺手方便。 现在vscode 1.0发布了,而且支持10种本地化语言,我尝试使用它编写Go程序,功能和性能都不错,所以目前atom和vscode都是我的菜。

本文简单介绍一下使用vscode开发Go的一些配置,速览vscode + Go 的功能。

阅读全文

Go Channel 详解

Channel是Go中的一个核心类型,你可以把它看成一个管道,通过它并发核心单元就可以发送或者接收数据进行通讯(communication)。

它的操作符是箭头 <-

1
2
ch <- v // 发送值v到Channel ch中
v := <-ch // 从Channel ch中接收数据,并将数据赋值给v

(箭头的指向就是数据的流向)

就像 map 和 slice 数据类型一样, channel必须先创建再使用:

1
ch := make(chan int)

阅读全文

Go泛型提案

Go泛型特性已经被讨论了多次了1, Andrew Gerrand现在把这个提案加入到了Go的issue列表中2,并标记为Go2标签。当然这不代表着要将泛型加入到Go中,而是演示一个完整的提案应该是什么样子。

阅读全文

使用Golang实现Futures 和 Promises

其它语言中Future和Promise的概念大量存在, 比如Node.js、Scala、Java、C#、C++ 11、Scheme、Swift等,可以方便的实现异步执行和回调。但是在Go语言的世界里,我们是通过goroutine/channel实现这种类似的功能呢,goroutine之间可以通过channel进行通讯, 但是,如果我们还是想使用Future/Promise的功能的话,该如何实现呢?

Future,Promise或Delay是用于并发编程的一种设计模式。它们表示一个对象,这个对象用来作为一次计算结果的代理,而该结果开始的时候是未知的,因为计算还没有完成。Promise与Future的区别在于,Future是Promise的一个只读的视图,也就是说Future没有设置任务结果的方法,只能获取任务执行结果或者为Future添加回调函数。

阅读全文

谁是最快的Go Web框架

前几天我写了一篇文章: 超全的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实现,性能超级好。

阅读全文

iris 真的是最快的Golang 路由框架吗?

依照我的前一篇文章(超全的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
    性能已经很不错了。

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

阅读全文