为了性能，你需要关注两个方面：延迟（应用程序的响应速度）和吞吐量（每个时间段内的操作数）。对于延迟，你需要有一个可接受的基准。对于吞吐量，你需要有一个最小可接受的吞吐量。
这些是你的起点。要告诉客户每个时间段可以完成多少个 xyz 操作，你需要了解硬件和软件配置。了解生产硬件对于获得准确的数据非常重要。如果你不知道硬件配置，则需要想办法将测试硬件的数据映射到最终的生产硬件上。
没有硬件知识，你只能观察随时间变化的性能趋势而不是绝对值。
同样重要的是了解软件配置。你是否有集群服务器配置，是否负载均衡，服务器上是否还有其他运行的东西？你能否扩展你的软件或者必须扩展硬件以满足需求？
要知道你可以支持多少客户端，你需要了解什么是标准操作集。一个快速测试方法是移除客户端并编写一个存根客户端，然后尽可能多地启动它们。让每个客户端连接到服务器。你最终会达到服务器连接资源限制。如果没有连接池或更好的硬件，你无法超过这个限制。通常你会在这之前遇到架构问题，但无论哪种情况，你都有一个上限。
将这些信息并设计一个脚本让你的客户端执行。你需要映射你的脚本执行操作所需的时间与预期用户执行相应操作所需的时间。如上所述逐渐增加你的数字，直到增加客户端导致性能下降更多的点。
有很多方法进行压力测试，但关键是了解预期负载。询问客户他们的期望值是什么。每个时间段的期望需求量是多少？从那里你可以计算出上限负载。
你可以进行长时间的并发测试，让多个客户端连续运行数小时或数天。你可以尝试尽可能快地连接尽可能多的客户端，以查看你的服务器如何处理高需求（也是一种DOS攻击）。
并发搜索应该通过代表客户端的标准行为搜索来完成，或者编写一个等待多个线程的信号量的脚本，然后可以同时释放它们。这很有趣，并且会惩罚你的数据库。当执行搜索时，你需要考虑任何可能存在的缓存层。你需要测试有缓存和没有缓存的情况（在每个人都进行唯一搜索请求的情况下）。
数据库存储是基于物理空间的；你可以根据字段长度和预期数据填充来确定行大小。通过统计推断或创建一个数据生成脚本（对于负载测试场景非常有用，应该是你组织的资产），然后将生成的数据映射到业务对象上。你的客户关心他们可以存储多少“业务对象”，而你关心可以存储多少原始数据。
其他需要考虑的事项：预计可用性是多少？启动服务器需要多长时间？如果服务器一旦宕机，恢复在线需要两天，那么99.9%的可用性也不够好。相反，如果重新启动只需5秒钟，并且有一个备用服务器，那么较低的可用性也更加可接受。
