摘要：
性能测试是批准任何软件产品出厂之前要执行的重要过程。您可能已经听过高级同事的一些恐怖故事，这些故事是关于系统出厂时没有任何性能测试的。因此，现在，这是测试的必要部分。有多种工具可用于实现非GUI中间件系统的性能测试，但是有时候我们没有自由选择现有的一组性能测试工具。
性能测试是批准任何软件产品出厂之前要执行的重要过程。您可能已经听过高级同事的一些恐怖故事，这些故事是关于系统出厂时未经任何性能测试的。因此，现在，这是测试的必要部分。有多种工具可用于实现非GUI中间件系统的性能测试，但有时我们没有自由选择现有的一组性能测试工具。
性能测试是批准任何软件产品出厂之前要执行的重要过程。您可能已经听过高级同事的一些恐怖故事，这些故事是关于系统出厂时未经任何性能测试的。因此，现在，这是测试的必要部分。有多种工具可用于实现非GUI中间件系统的性能测试，但有时我们没有自由选择现有的一组性能测试工具。
为什么不选择现有工具？
以下是一些原因使我们无法选择市场上已有的工具。
该工具中没有合适的请求触发选项。有些中间件系统具有自己的性能要求，而商用工具无法完全满足它们。例如，我使用的电信服务交付平台正在使用Sigtran协议。很难找到一种支持该协议的性能工具。典型的性能工具不支持其他一些协议，例如通用计算机协议和计算机与消息的交互。如果现有工具不支持我们重要的性能要求，我们可能会被迫选择自定义性能工具。
测试工具的性能可能不足。商业工具可能具有许多功能，但是并非所有功能在任何给定时间都是有用的。由于这些额外功能，性能工具可能无法达到预期的水平。我们可能也抱有更高的期望：以较高的速率触发请求，例如每秒2000个事务（TPS），并使用较低的系统资源（内存，CPU，I / O）。
当工具提供更多功能时，它们可能还会使用更多系统资源。这些商业工具通常建议从多台机器触发以实现每秒更高的请求数量，但这会增加项目成本。如果我们更关注较高的触发性能要求和较低的系统资源使用量，则可能必须构建自己的工具才能以较高的TPS有效触发。
该工具在商业上不可行。一些工具可能提供了足够的选择，但是价格可能无法帮助我们将成本控制在项目预算之内。有时候，花钱买工具可能不值得。免费的开源工具可能无法提供足够的功能。构建我们自己的性能工具也不是免费的。我们可能必须估算构建自己的工具的成本，然后将使用现有工具的成本进行比较以做出决定。
在我们公司中，我们使用了一些与电信相关的协议，但找不到合适的工具。我们最终自己构建了性能工具。一旦成功，我们便开始为大多数项目实施该工具。
建立自己的绩效工具的优势
由于上述一个或多个原因，我们可能被迫编写自己的工具来进行性能测试。这给了我们更多自由来决定如何设计性能工具以及包括哪些功能。以下是构建自己的定制工具的一些优点。
我们可以自由地增强性能测试工具的功能。如果选择现有工具，那么我们将受限于该工具的功能。例如，我们可能选择适合大多数情况的最合适的工具。但是，如果几个月后我们收到客户关于随机响应延迟的投诉，那么我们将不得不衡量这些随机延迟。如果我们选择的工具不支持此功能，那么我们可能必须寻找另一种方法来进行测量。但是，如果我们拥有自己的工具，则可以更轻松地扩展工具的范围以支持此类新要求。
我们可以重用现有的监视工具，而不是在我们的工具中建立监视支持。操作系统通常会提供足够的监视工具来监视系统的资源，例如内存，服务器负载和CPU。此外，Java有足够的工具，例如Flight Recorder，GC日志，Jstack和Jconsole，因此我们可以利用这些现有工具来补充我们自己的性能工具。我们可能必须构建简单的请求触发工具，并且为了进行监视，我们可以使用这些现有工具。
我们可以构建可重用的绩效工具来证明业务决策的合理性。作为一个组织，我们可能有几种类似的产品，如果我们构建可重用的工具，它将有助于在业务级别证明我们的决定的合理性。作为技术人员，构建工具很有趣。在注意并发问题的同时，将需要具备编写良好代码的专业知识。如果我们可以将该工具重复用于各种项目，则可以帮助我们降低组织的成本。
我们可以成为使用JDK和基于操作系统的监视工具的专家。如果我们使用JDK和基于操作系统的工具进行性能监视，则可以成为使用它们的专家。以后，这些经验在监视生产系统中的性能问题时会很有用。99％的时间将不允许您使用性能软件进行安装和监视，因为这可能会导致安全问题，并可能增加生产流量的开销。因此，最好具有这些基本系统和JDK工具的专业知识，这些知识可以始终帮助您解决生产性能问题。
构建自己的性能工具的缺点
认真分析编写自己的工具的需求非常重要。通常，建议将完善的工具重新用于典型的性能测试，但是也有例外。在决定编写自己的工具之前，强烈建议进行清晰的分析。这是构建自己的性能工具的一些缺点。
构建该工具将需要大量的专业知识和知识。您可能需要大量的专业知识才能编写出可以满足您期望的好的工具。以下几点至关重要：并发，有效的连接处理和有效的内存使用。如果您的团队缺乏对所需技术的深入了解，则不建议自己使用工具。
建立工具可能很昂贵。如果未进行正确的估算，则最终可能会花费更多，而不仅仅是购买现成的工具。建议在决定编写自己的工具之前进行正确的分析和估计。
性能工具本身的性能问题很危险。这是典型的“谁看守守望者”问题。如果您的工具不干净，则可能会错误地怀疑已经过性能测试的系统。因此，需要对您的工具进行适当的性能检查。
您准备自己的表演太准则升
以下是一些有关准备自己的性能工具的建议指南。
明确定义性能工具的范围。首先，我们需要选择性能工具的范围。范围可以取决于这些选项。
- 请求触发能力-该工具需要支持每秒不同数量的事务，因为某些系统可能以基于类似图形的模式或恒定模式的模式获取请求流量。如果需要依赖于先前触发的请求响应的请求，我们可能必须缓存每个请求的响应值。
- 运行该工具的可用资源-根据资源限制，我们可能必须调整此性能工具才能有效地工作。需要考虑内存和CPU使用率。
- 如何进行性能监视-我们是否将依靠该工具通过记录系统使用情况详细信息来进行性能监视？
选择简单有效的技术。选择一种更简单的技术以确保任何人都可以开发和更改它很重要。如果我们对此触发工具没有太多复杂的要求，我们甚至可以使用简单的脚本语言。
确保该工具使用最少的系统资源。该工具不应执行任何不必要的计算或不必要的日志记录。它应该做最少的活动以确保它使用更少的资源，并且可以在较低的系统资源使用率下以最高的速度执行。
因此，最重要的是，根据项目的性质，您可以编写自己的性能工具，但是我只建议这种方法用于没有合适的性能测试工具的高端中间件系统。
