还未发布过话题
  • proto 文件转成 jar 包,然后通过类名使用反射生成 stub 实例,然后解析 method,参数用 json 字符串输入。说起来很简单,但是如果你不会,就会不知所云。建议:第一步,写一个正常的 grpc 调用过程(不包含反射);第二步,学习反射(用来解耦 grpc stub 依赖);第三步,把第一步的调用过程用反射来实现,完事。

  • java 的话,反射可以满足你的想法

  • 全链路压测的主要工作在于基础设施和系统架构的适配,可以说根本不在压测工具这边,你系统改造好了,拿个 jmeter 模拟端头发请求都可以,流量自然而然的传递到下游。换句话说,从压测工具出发谈全链路压测的都是噱头。

  • 很多开源项目是很好的学习榜样,可以获得很多设计平台或者说框架的思路,但是完全基于开源项目,只是做个缝合怪平台的话,要么你的业务项目比较简单,没有特别个性化的需求;要么发展到最后,各种需求让你无从下手,让你的平台成为又一个烂尾的缝合怪。

  • 性能测试框架对比初探 at 2021年06月28日

    王婆,你这瓜保熟吗?

  • 看角度,如果是从写&执行的角度来说,直接上代码无疑是最自由的。如果是从管理和度量的角度,平台还是有优势,当然,前提是平台是个 “平台”,而不是 ppt,领导会去看你的代码?不,它只想看大盘。平台的定位不应该是一个代替 code 的自动化工具,而是整个团队研发流程的一个物理约束,具体支撑。退一步来讲,光说自动化,不管是 code 还是平台,都看人,牛逼的 code 也能整整齐齐;不牛逼的,平台也就乱七八糟。

  • 适当的推广我认为是可以并且鼓励的,毕竟再好的平台,别人需要学习成本和改变习惯,一般都不太愿意去接受。如果设计得好,学习成本低,也更有可能被接纳。所以另一个原罪就是写工具的人是菜逼,要写好一个工具,你需要做好产品,开发,测试三个角色,然而很多人呢,表结构都设计得一言难尽,更别提什么交互。而且放眼望去,十有八九都是做 http 的自动化,当然 http 应用广泛是其一,涉及到点 rpc 什么的基本就傻眼,能力只到那个层次又要强行装逼,最后就是写出来一堆垃圾。然后 ppt 上写出来的效果拳打 ali 脚踢 tx,无他,唯 B 尔。当然就算到这种程度,作为一个自扫门前雪的人,我是不会去吐槽的,毕竟人家锻炼下也没问题,但是过了底线:1 强推,2 让人接坑,那就 sb 无疑。

  • 个人意见:写工具/平台的人应该有 2 个底线:1,不强迫(包括政治手段)别人使用;2,不强迫别人接坑。花若盛开,蝴蝶自来。

  • 仅楼主可见
  • 聊一聊游戏的压测 at 2020年04月27日

    确实是这样的,api 式的压测,是基于应用层来进行的,http 也好 rpc 也好,应用层的事情你不用关心了,只用关注会话(场景)层,甚至有的时候就压单个接口,那更简单了,同时成熟的工具一抓一大把。这些都让压起来比较容易。但是在性能分析,优化这些方面呢,两者还是颇多相同的,这也是压测最有价值的地方。游戏压测实际上是一个不怎么讨好的工作,花很多的力气在让压测跑起来上,而实际上这部分并不能带来产出,毕竟压测的目标不是写个压测工程,而是优化和修复可能的问题。但是对个人来说,确实是比较锻炼人,一直在传输层上行走,所在的层次(OSI 模型)越低,能看到的就越多。