这些广告的受益者并非本人,而是 Wikidot。我个人从不掩饰对 Wikidot 的喜爱,它给了我想要的东西,我们为它赚点广告费,我觉得这是很正常事情。Wikidot 也是很有原则的一家公司,她对客户的尊重是我喜爱她的另一个重要原因,要想进入本站而不出现广告很简单,注册个 Wikidot 账号,在浏览本站的时候保持登录状态就好了,你会看到一个很干净的界面。
如果你不考虑具体的使用场景,建议选择 golang。erlang 的适用范围相对狭窄。
两者目前都重服务端,所以客户端开发来说,都不是特别适合,如果非要用,建议用 golang。
服务端开发,如果团队比较小,喜欢函数式编程,而且网络模块偏重 io,逻辑不复杂,用 erlang 可以获得比 go 更好的性能,目前 go 语言在性能上还没做过非常大力度的优化。其他情况我建议用 golang。
许哥您好:
看到您编写的winx, 我有一个问题请教, 为什么MFC的消息映射要提供_AFXDLL和非_AFXDLL两个implementation, 比如
#ifdef _AFXDLL
#define DECLARE_MESSAGE_MAP() private: static const AFX_MSGMAP_ENTRY _messageEntries[]; protected: static AFX_DATA const AFX_MSGMAP messageMap; static const AFX_MSGMAP* PASCAL _GetBaseMessageMap(); virtual const AFX_MSGMAP* GetMessageMap() const;
#else
#define DECLARE_MESSAGE_MAP() private: static const AFX_MSGMAP_ENTRY _messageEntries[]; protected: static AFX_DATA const AFX_MSGMAP messageMap; virtual const AFX_MSGMAP* GetMessageMap() const; #endif
为什么直接用非_AFXDLL的版本的不行? 非要用一个函数_GetBaseMessageMap()去取基类的messageMap?
许哥您好,请教一个问题:
golang http.ResponseWriter 的Write()方法,服务的QPS由3万降到7000。附上我的测试代码和boom测试结果:
现在我测试到的情况是这样的,如果我只填写http的header,那么服务端的处理速度很高,单纯测试(没有业务逻辑),QPS能达到3万,但是如果我添加payload,那么QPS就只能达到不足8000了,只有6000的样子。这个落差太大了,我尝试直接使用http.ResponseWriter 接口中的Write方法写入一个[50]Byte,效果一样。根据我的测试和你们的分析,应该是IO的问题,不过这个也太夸张了。
func handleHeader(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "0") }
func handlePayload50(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "50") w.Write(make([]byte, 50)) }
func handlePayload128(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "128") w.Write(make([]byte, 128)) }
func handlePayload1024(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Length", "1024") w.Write(make([]byte, 1024)) }
func main() { runtime.GOMAXPROCS(runtime.NumCPU()) http.HandleFunc("/header", handleHeader) http.HandleFunc("/payload50", handlePayload50) http.HandleFunc("/payload128", handlePayload128) http.HandleFunc("/payload1024", handlePayload1024) host := fmt.Sprintf("%s:%d", "0.0.0.0", 5001) http.ListenAndServe(host, nil) }
and the boom test result: ./boom -c 1000 -n 500000 -cpus 12 XXXXXX/header 500000 / 500000 Boooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 %
Summary: Total: 12.8799 secs. Slowest: 3.2799 secs. Fastest: 0.0018 secs. Average: 0.0239 secs. Requests/sec: 38810.4907
Status code distribution: [200] 499875 responses
Response time histogram: 0.002 [1] | 0.330 [499306] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.657 [0] | 0.985 [0] | 1.313 [312] | 1.641 [0] | 1.969 [0] | 2.297 [0] | 2.624 [0] | 2.952 [0] | 3.280 [256] |
Latency distribution: 10% in 0.0125 secs. 25% in 0.0172 secs. 50% in 0.0216 secs. 75% in 0.0257 secs. 90% in 0.0295 secs. 95% in 0.0327 secs. 99% in 0.0549 secs.
./boom -c 500 -n 500000 -cpus 12 XXXXXX/payload128 500000 / 500000 Boooooooooooooooooooooooooooooooooooooooooooooooooooo! 100.00 %
Summary: Total: 62.5205 secs. Slowest: 3.0714 secs. Fastest: 0.0112 secs. Average: 0.0601 secs. Requests/sec: 7997.1501 Total Data Received: 63998208 bytes. Response Size per Request: 128 bytes.
Status code distribution: [200] 499986 responses
Response time histogram: 0.011 [1] | 0.317 [495652] |∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎∎ 0.623 [0] | 0.929 [0] | 1.235 [4092] | 1.541 [0] | 1.847 [0] | 2.153 [0] | 2.459 [0] | 2.765 [0] | 3.071 [241] |
Latency distribution: 10% in 0.0405 secs. 25% in 0.0436 secs. 50% in 0.0481 secs. 75% in 0.0546 secs. 90% in 0.0629 secs. 95% in 0.0731 secs. 99% in 0.1054 secs.