[fix] solve concurrent coroutine request problem

[ronething-bot]

fix #10

[ronething-bot]

双检锁：https://segmentfault.com/a/1190000041903401

[ronething-bot]

原子操作(atomic)：

• https://gfw.go101.org/article/concurrent-atomic-operation.html
• https://www.cnblogs.com/ricklz/p/13648859.html

[ronething]

• 可新开分支进行测试，加锁理论上对分数有一定的影响。

[ronething]

• 需要注意一点：client-go 内部有实现退避重试算法，所以假如开 1000 个协程，edge-proxy 计算出来的 count 不一定是 1000，即使使用了 atomic add.

edge-proxy

benchmark

client-go request.go

目前测试 200 协程没问题，500 协程有一部分(几十个)会 error，1000 的话就 error 的更多。

• 还有 klog.Infof 可能成为瓶颈，可以通过注释或者提高级别 V(5) 进行打印

• list resource usage 可参考 benchmark ，目前是可以考虑同时开 25 个左右的协程，达到 460+ tps

[ronething]

详见 commit: ebaec51

[ronething]

并发 docker image 目前评测资源分：48917.3797(submit time: 2022-08-13 15:56:54)，当然也可以再测试几次，先 close，主要是为了验证并发下的请求 count 一致性问题以及类似 redis 缓存击穿问题。

缓存击穿： 一个热点的Key，有大并发集中对其进行访问，突然间这个Key失效了，导致大并发全部打在数据库上。

[ronething]

47870.4015(submit time: 2022-08-13 16:12:59)

[ronething]

49928.8520(submit time: 2022-08-13 18:45:43)

[ronething-bot]

• 关于 no buffer space available 的问题，可以考虑增大 buffer 测试下
  net/http: make ResponseWriter buffer size configurable golang/go#7467
  proposal: net/http: configurable Server.WriteBufferSize golang/go#13870
  https://stackoverflow.com/questions/68778961/how-to-configure-the-buffer-size-for-http-responsewriter
  https://hub.docker.com/layers/library/golang/latest/images/sha256-b70f158b8d0939963f21d81523bc3a5f189fd687cf305504a91d6281bd2f732a?context=explore

• Golang 网络编程: https://www.cnblogs.com/ZhuChangwu/p/13198872.html

• ENOBUFS 解决方法: https://blog.csdn.net/cao849861802/article/details/117714422

• socket 缓冲区: https://blog.csdn.net/mayue_web/article/details/121531311

[ronething-bot]

• 先本地构建二进制，再复制到镜像：c9a4e88

[ronething-bot]

• 有趣的是，在 linux 上暂时没有测试出 no buffer available 的情况：

4k or 8k 表示 net/http/server.go newBufferSize 的 size 大小

4k nums: 10, count is 24177, tps: 402/s
4k nums: 20, count is 26753, tps: 445/s
4k nums: 30, count is 27273, tps: 454/s
4k nums: 50, count is 28636, tps: 477/s
4k nums: 10000, count is 38265, tps: 637/s

8k nums: 10, count is 25842, tps: 430/s
8k nums: 20, count is 28038, tps: 467/s
8k nums: 50, count is 28001, tps: 466/s
8k nums: 100, count is 29345, tps: 489/s
8k nums: 1000, count is 31493, tps: 524/s

[ronething-bot]

• 目前主要呈现的瓶颈在于 rw.Write(无论是并发安全版本还是单协程版本)，通过修改 go 源码(newbuffersize)重新编译效果不是很显著，考虑躺平。
• 经过两天测试，tag: v0.0.37 目前最高是 13w 左右(130075.7496)