出现性能问题不可怕，可怕的是没有目标，用户只是说“我希望它非常快”，或者说“和以前一样快”，在这种情况下，我们就需要把制定性能衡量标准放在首位了，原因有两个：
（1）性能衡量标准是技术与业务之间的契约
“非常快”是一个直观性的描述，它不具有衡量的可能性，对技术人员来说，一个请求在2秒钟之内响应就可以认为是“非常快”了，但对业务人员来说，“非常快”指的是在0.5秒内看到结果——看，出现偏差了。如果我们不解决这种偏差，就有可能出现当技术人员认为优化结束的时候，而业务人员还认为系统很慢，仍然需要提高继续性能，于是拒不签收验收文档，这就产生商务麻烦了。
（2）性能衡量标志是技术优化的目标
性能优化是无底线的，性能优化得越厉害带来的副作用也就明显，例如代码的可读性差，可扩展性降低等，比如一个乘法计算，我们一般是这样写代码的：
int i=100*16；
如果我们为了提升系统性能，使用左移的方式来计算，代码如下：
int i=100＜＜4；
性能确实提高了，但是也带来了副作用，比如代码的可读性降低了很多，要想让其他人员看明白这个左移是何意，就需要加上注释说“把100扩大16倍”，这在项目开发中是非常不合适的。因此为了让我们的代码保持优雅，减少“坏味道”的产生，就需要定义一个优化目标：优化到什么地步才算结束。
明白了性能标准的重要性，就需要在优化前就制定好它，一个好的性能衡量标准应该包括以下KPI（Key Performance Indicators）：
核心业务的响应时间。一个新闻网站的核心业务就是新闻浏览，它的衡量标准就是打开一个新闻的时间；一个邮件系统的核心业务就是邮件发送和接收速度；一个管理型系统的核心就是流程提交，这也就是它的衡量标准。
重要业务的响应时间。重要业务是指在系统中占据前沿地位的业务，但是不会涉及业务数据的功能，例如一个业务系统需要登录后才能操作核心业务，这个登录交易就是它的重要交易，比如邮件系统的登录。
当然，性能衡量标准必须在一定的环境下，比如网络、操作系统、硬件设备等确定的情况下才会有意义，并且还需要限定并发数、资源数（如10万数据和1000万的数据响应时间肯定不同）等，当然很多时候我们并没有必要白纸黑字地签署一份协约，我们编写性能衡量标准更多地是为了确定一个目标，并尽快达到业务要求而已。