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