罗杰2022-01-28什么时候能和老师一样有如此丰富的优化经验呢，讲的非常精彩。作者回复: 👍
共 2 条评论6
多选参数2022-05-05原本以为最后的实战课只是写一个稍微大点的项目。结果，恰恰相反，老师使用一个极小的项目，带着走了一遍 Go 开发和调优的过程，这种方法论或者思想的传授，真的比单纯写代码可以学到更多，是在其他书籍或专栏所没有的，很喜欢这种方式！感谢老师！ 简单总结下，最后实战课核心的内容： 1. Go 开发的流程结合自己的几个月的经历，总结下：（1）首先是明确问题或需求，之后根据问题或需求，提炼出需要用到的技术点，比如 socket 技术；（2）之后，去调研相关的技术或相关项目；（3）最后写设计方案；（4）根据设计方案，实现代码。（PS：这个过程可以循环迭代） 2. Go 程序优化的过程：（1）首先是明确衡量指标，比如某个函数的执行时间、程序在一定时间内可以处理的请求量、接受的数据包数量等等（并获取首次的指标情况）；（2）之后，使用 pprof 获取 CPU、内存的使用情况，并分析使用情况，得到整个程序的瓶颈所在；（3）最后，根据分析得到的结果，优化源码；（4）优化源码后，再次测试衡量指标，根据新获取的指标情况，决定是否继续分析和优化。 另外，可以继续优化点的应该就是与 Submit 使用相同的地方，比如 submitAck。展开作者回复: 👍
5
@%初%@2022-06-19老师，有个问题，sync.pool也就是内存池那块，请求过来之后，我看到是直接放到内存池，没有置空数据，那么在内存池获取的时候，会不会出现数据错乱的问题呢？作者回复: 好问题。使用sync.Pool时，复用内存对象当前数据可能会造成数据错乱的情况。因此如何处理这种问题，要看pool中的对象是什么以及如何用？ 像我们这里，pool中对象是一个Submit的指针，而submit的结构如下： type Submit struct { ID string Payload []byte } 这个结构在每次decode时都会被全量覆盖： func (s *Submit) Decode(pktBody []byte) error { s.ID = string(pktBody[:8]) s.Payload = pktBody[8:] return nil } 也就是说虽然put时没有重置，但取出后重置了。 换成其他pool中对象和其他场景，的确需要考虑是否需要重置对象，以及是在put时还是get时进行重置。
3
顷2022-04-14bufio.Reader.Read 方法内部，每次从 net.Conn 尝试读取其内部缓存大小的数据，而不是用户传入的希望读取的数据大小 -----------这里有个疑问，server端for 循环里不是每次都是重新读取到的conn传过来的数据吗，也就是每次client端发送过来的payload都是要有一次必要的读取，为什么会减少读取的次数呢？作者回复: 是减少socket read系统调用的次数，也就是说增加buf read前，每次read，无论read 1个字节，还是read 100个字节，都要执行一次sys call。而增加buf read后的read会看buf中是否有足够的数据，如果有数据满足read需求，就不会执行syscall去读取底层的socket数据。当然之所以能做这么是因为bufio.Reader.Read每次从底层socket读取的数据并不是上层传入的大小，默认值为defaultBufSize ，即4096。
共 2 条评论3
菠萝吹雪—Code2022-09-14 来自北京精彩的优化过程！感谢老师这个专栏，很喜欢这种讲解知识点的方式！第一遍结束，第二遍开始记笔记分析每一行代码，第三遍再过下老师的两本书，应该算是完全入门go了作者回复: 书也买了啊，哈哈，嫡系了🤝
2
骚动2022-08-19 来自北京mac下的配置参考： 1. mac不能用host，需要用ports端口映射 version: "3.2" services: prometheus: container_name: prometheus image: prom/prometheus:latest ports: - "9090:9090" volumes: - ./conf/tcp-server-prometheus.yml:/etc/prometheus/prometheus.yml - /etc/localtime:/etc/localtime restart: on-failure grafana: container_name: grafana image: grafana/grafana:latest restart: on-failure ports: - "3000:3000" volumes: - /etc/localtime:/etc/localtime - ./data/grafana:/var/lib/grafana node_exporter: image: quay.io/prometheus/node-exporter:latest restart: always container_name: node_exporter command: - '--path.rootfs=/host' ports: - "9100:9100" volumes: - /Users/zouqiang/Documents/docker/monitor/data/node_exporter 2. grafana上配置prometheus数据源时，url: http://本机ip:端口 , 不要用http://localhost:9090这种方式，因为容器间的localhost不是同一个localhost, 用主机名直接指定即可展开作者回复: 👍
共 2 条评论2- Geek_25f93f2022-06-26老师，看网上有种说法。池化这种事情，Java很早很早之前也做过 现在都不怎么提了，go的编译器太弱了？
作者回复: "管它黑猫白猫,能抓住老鼠就是好猫"，至少目前sync.Pool能在一定场景下帮助我们提升性能。 go与java虽然都是gc语言，但由于类型系统的差异，gc所面对的环境也不同，有些事情不能以强弱来论。比如java gc做分代，而go gc没有分代，不是go gc不想做分代，而是经过实测分代对go gc的提升有限，因为go的许多生命周期很短的临时对象经过逃逸分析后是分配在栈上的，完全不需要在堆上分配。 当然和java比，go在gc方面的打磨时间还远远不够。这反过来说也是好事，目前go gc已经很不错了，未来只能更强大。作为Go应用开发者，我们将来可以做到“躺赢”:)。
2 
Mew1512022-10-13 来自北京老师，想问一下， tcp-server-demo2-with-pprof 的代码，我在我的 Mac 上分别启动 server 和 client ，过了一段时间后 server 报如下错误（打印是我加了些详细日志之后的）： metrics server start ok(*:8889) server start ok(on *:8888) [2022-10-13 13:41:54.562] io.ReadFull: read tcp 127.0.0.1:8888->127.0.0.1:49689: read: operation timed out totalLen is 28, n is 20 [2022-10-13 13:41:54.562] handleConn: frame decode error: read tcp 127.0.0.1:8888->127.0.0.1:49689: read: operation timed out [2022-10-13 13:41:55.545] io.ReadFull: read tcp 127.0.0.1:8888->127.0.0.1:49754: read: operation timed out totalLen is 32, n is 15 [2022-10-13 13:41:55.545] handleConn: frame decode error: read tcp 127.0.0.1:8888->127.0.0.1:49754: read: operation timed out [2022-10-13 13:41:55.590] io.ReadFull: read tcp 127.0.0.1:8888->127.0.0.1:49729: read: operation timed out totalLen is 31, n is 26 ... 请问这是什么原因呢？我看程序里也没有设置 SetReadDeadline 的地方，为什么会报读超时呢展开作者回复: 在linux上跑一个小时，也没有出现问题。以前还真没在mac上跑过，我抽时间调查一下。
共 3 条评论1- Geek_25f93f2022-06-27老师，这个frame.decode解包过程为什么不会出现粘包的现象啊？按理说收到这个frame部分也可能出现半包的情况啊，为什么我不管怎么试 在服务端加sleep时间 或者 加client的发送包体长度和协程数量，也没办法进入 if n != int(totalLen-4) 这个判断分支呀
作者回复: 主要是因为io.ReadFull这个函数，可以查看一下它的manual。
共 3 条评论1 
木木2022-03-22我这里Frame的Decode函数在读totalLen的时候会有小概率读到一个错误的数值，请问有人知道这是为什么吗？作者回复: 可以试着将你收到的所有数据按字节逐个dump出来。可以使用hex.Dump这个函数。 btw同问：有遇到过这种错误情况的么？
共 2 条评论1