有一些问题集中在如何确定并发数，我在原文中有这么一段话
衡量性能测试的指标，很多人会说是并发。并发指同一时间节点发生的事情，但这个同一时间并不是一个标准的度量，也不是我们性能测试直接测量出来的指标。在性能测试中往往是通过在工具中增加虚拟用户数得到的接口每秒的调用量去衡量。
我想大家没仔细看这一段话，那我们就来进一步解析为什么不直接说并发，当你问我这个问题是，我也想问下你是如何衡量并发的？很多人回答不上来，也有人拿出一套公式给我，公式中充满了晦涩的概念以及经验值，在我的经验当中，也没有哪个公司套用这个公式。
我继续追问，你觉得并发的单位应该是什么？很多同学又支支吾吾，自己提的问题自己也越来越迷糊了，回到并发这个词，要去衡量服务器同时处理的事情，已经不能用时间作为载体，因为再小的时间单位也可以继续细分，甚至我们需要追溯到cpu处理器的核数，但事实上这是不现实也没有太大意义，这个并不能很好的评估业务承载量，因此我们引入了相对并发的概念，通过每秒调用的次数来衡量并发，也就是我们通常所说的tps，tps是最被广泛接受的衡量性能好差的指标。所以你在问别人如何去评估并发时，一定要想清楚并发是什么？
我遇到过一个场景，测试、开发运维在一起聊的热火朝天讨论这次活动的并发量，但是最终没有形成任何结论，后来我又仔细推敲了下，开发所说的并发是网站的活跃人数，运维认为的并发是网关连接数，测试认为的并发是测试工具中的线程数，每个人想的都不一样，试问这样的情况讨论三天三夜又能如何？就算讨论出结果又如何去实操落地呢？
我的专栏中如果问我性能核心指标如何制定，我只认tps，你不要说并发，因为我不知道你有没有理解清楚并发是什么，你是怎么去衡量的，这点没形成共识，其他的无从谈起。
接下来继续晒问题，有人拿出一些数据问我应该如何指定tps，比如有人跟我说他么一天的访问数是10W，该怎么指定性能指标？这样的颗粒度还是很粗的，有同学说去套用用28原则,我的建议是先去和监控相关的同事聊有没有颗粒度更细的监控，关于颗粒度的细化在专栏中也有所提及，其实在性能领域没有太多的推倒公式，绝大多数都是依靠实际数据做决策。
所以关于指标制定记住两个重要准则
- 首先在团队内部对性能指标的认知达成共识
- 历史数据是最直接的依托，提供了具体的访问数值和增长趋势作参考
真实准确的结果都是靠测出来，如果都能推出来，阿里巴巴还需要提出线上性能测试干什么呢？性能环境测出一个结果去用公式算一下不就行了？事实上，没有这些捷径。
还有同学提问，我么是没有监控数据怎么办？
但我认为你所说的仅仅代表你自己的认知，不代表公司的实际情况，绝大部分公司都会有网关日志记录访问数据，通过这部分日志就能提取到实际访问的tps，如果运维没有做加工，可能就是告诉你简单两个字：没有，这种情况是最典型的，实际上有但你获取不到加工不了。
第二种情况是新项目数据都没进来，确实没有，我的做法是先对新接口做一轮基准测试，根据指标排序，重点关注并先优化性能较差的接口；了解周边数据，比如这次新项目有没有活动推送，推送量是多少，历史转化率是多少，多少用户注册等，通过时间去层层推进，不断丰富数据场景，这是一个过程，如果什么数据都没有，就应当进行数据基础建设，而不是想通过经验值公式或者咨询大咖怎么办，除了做基础建设为之后铺路其他没有什么好办法，不完整的过程不可能得到一个完整的结果。通过这篇我希望大家可以对性能指标认知和制定上更上一个层次，还有知道如何走向正确的方向。
