V2EX › herozem 的所有回复 › 第 3 页 / 共 17 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 2 3 4 5 6 7 8 9 10 ... 17

❮

❯

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@qq292382270 我想我们聊的有点误会😂误会老大了……我是指我比较倾向于货到付款，不过你正好相反然后就没有交易失败了。他们都是支付宝付款的

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@asiufasd 前者难，讲的多。后者简单，讲的少

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@qq292382270 哎呀我去。。不好意思，哈哈哈哈哈尴尬了

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@qq292382270 额。。帖子上面就说了华章 30 一本，非华章 20 一本。30*8 + 20 * 10 = 540... 已经是亏血本卖了。。。就不要再砍价了吧

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@joouis 到付肯定是邮费到付的意思啊。。哥

2018 年 1 月 27 日

回复了 herozem 创建的主题 › 问与答 › 卖二手书

@sfqtsh 木有。我没有那么闲去骗人的，放心吧

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@gstqc 如果可以的话，最好能把 guard 的测试一起贴上去。这样方便对比，哈哈~

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@zhicheng 嗯，这也是一种观点。过早优化是万恶之源没错，但是性能也是一个重要的功能。软件开发的过程并非要剑走偏锋，例如追着性能不放，而是在权衡之下取一个比较好的点。目前这边也没有完全追逐性能

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@feverzsj 绝大部分性能确实来自 fasthttp，但是也离不开其他组件的支持。

@zhicheng 并不想取代 Nginx。在此只是压测时做对比和参照。Nginx 作为我最喜欢的软件之一，怎么能取代呢

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@bestkayle 我们不一样 :)

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@sagaxu :joy: 那可能是命数。。。要替代 Nginx，有太多太多的功能要开发和完善。其实这个项目起初也是为内网的一个需求设计的，不过目前还不够成熟所以还没有上生产。所以设计之初就是躲在 Nginx 后面工作的 (地下工作者

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@assad 没准备取代，设计的时候就没想过要取代。理想的方式是躲在 Nginx 之后作为一个中间件。因为 Nginx 非常的成熟非常的专业，第二 fasthttp 没有完全遵循 HTTP RFC，第三 guard 并不准备增加 Nginx 那么多可更改的配置和“脚本支持”。

理想的方式是 Nginx 处理完规则，然后打到 guard，然后后面是应用

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@gouchaoer
@est
@sagaxu
@assad 开发的时候都是用 wrk 粗略压测，CPU 是物理双核虚拟四核。GOMAXPROCS 默认是虚拟核心数（我 1.9 ），Nginx worker 是 4。我今天好好的做一次专业一些的压测，请大家耐心等候。

2018 年 1 月 26 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@cholerae 应该还是可以的，有写一个 benchmark，发现 time.Now 损耗大概在 40ns 左右，用 coarse 实现应该是可以控制到这位朋友要的精度的。毕竟 CPU 非常的快

2018 年 1 月 25 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@zhujinliang https://github.com/valyala/fasthttp/blob/master/coarseTime.go 参考这个

2018 年 1 月 25 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@zhs227 是的，原本我计划自己实现 proxy 也是这种思路。因为作为 proxy server，并不需要读 body。另外 net/http 实现里申请了太多的内存，相当的影响性能。另外 guard 暂时也不会支持 http2。http/1.x 比 2 的工具等
都成熟很多。更专业的 benchmark 我会在把功能做成熟做稳定之后再来，目前还只是一个粗略的跑分

2018 年 1 月 25 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@bramblex 尽可能的重复利用已经申请的对象，尽可能的避免锁。pprof，哪里耗时打哪里

@xwhxbg 目前还在开发，变更比较大，等稳定了，注释多了就好读了 :)

@ryd994 目前还只有简单的测试，等稳定了之后会把 benchmark 做的更详细更专业的 :) 目前是：Nginx 4 worker 返回默认的 index.html。Nginx 4 worker 监听 9999 做代理，guard 监听 23456 做代理。max fd 都是设置 2048000。

因为都只能在自己的笔记本上跑跑，互相影响是肯定的，之后如果有机会的话，可以用强大的机器+虚拟机的模式来跑分

2018 年 1 月 25 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@xwhxbg 讲真，重写之后原来的配置方式被删掉了 :joy: 之后的话这些功能应该都可以慢慢加上的。不过当务之急是完善核心功能+继续压榨 Go 的性能。

之前是有一个接口返回 app 和对应的统计数据的，不过如上所说，暂时被删掉了 :joy:

欢迎贡献代码

2018 年 1 月 25 日

回复了 herozem 创建的主题 › 分享创造 › 经过再次重写之后，性能已经是 Nginx 的 1.76 倍

@LuckCode star 也是贡献~~鼓励开发者哈哈

@xwhxbg 暂时还没有和 trafik 对比，trafik 说 [自己是 Nginx 的 85%]( https://docs.traefik.io/benchmarks/) 左右，起初我也是以这个为目标的。[]byte 是 mutable 的, string 是 immutable 的，如果底层共享的话，会发大乱子的。

参考： https://syslog.ravelin.com/byte-vs-string-in-go-d645b67ca7ff

2018 年 1 月 22 日

回复了 herozem 创建的主题 › Go 编程语言 › [Go]重写了熔断器，然后开源了，大家一起来完善吧 :)

@boywhp 是的，确实需要很多时间。目前的想法是优化到 Nginx 的 80%左右。此后的话，看项目情况，要是有人用的话，肯定会继续搞下去的

1 2 3 4 5 6 7 8 9 10 ... 17

❮

❯