接口响应时间
接口响应时间是衡量API性能最核心的指标，指从客户端发送请求到接收完整响应所消耗的时间，通常包括网络传输时间、服务器处理时间和队列等待时间，根据业务场景不同，响应时间的标准也有所差异：实时交易类API响应时间需控制在200ms以内，而数据查询类API可接受1-3秒，若响应时间超过阈值，可能导致用户体验下降，甚至引发超时错误，优化响应时间可通过减少数据库查询次数、使用缓存机制（如Redis）或采用异步处理（如消息队列）实现。
吞吐量
吞吐量指单位时间内API成功处理的请求数量，常用单位为QPS（Queries Per Second，每秒查询数）或TPS（Transactions Per Second，每秒事务数），该指标直接反映API的并发处理能力，一个支付接口的吞吐量为1000 TPS，意味着系统每秒可处理1000笔交易，吞吐量受服务器硬件、网络带宽、算法复杂度等因素影响，为提升吞吐量，可进行负载均衡（如Nginx分摊请求）、优化代码逻辑（如避免循环嵌套）或采用更高效的数据结构。
错误率
错误率指API请求中失败请求所占的比例，计算公式为：错误率 =（失败请求数 / 总请求数）× 100%，根据HTTP状态码分类，4xx错误（如404、400）通常表示客户端请求问题，5xx错误（如500、503）则代表服务端异常，若某接口总请求数为10万，其中500错误出现100次，则错误率为0.1%，高错误率会直接影响系统可靠性，需通过日志监控（如ELK平台）定位问题根源，如数据库连接失败、参数校验错误或服务资源不足。
并发用户数
并发用户数指在同一时间内同时使用API的用户或请求数量，分为“活跃并发用户”和“最大并发用户”，前者指正在发送请求的用户数，后者指系统可稳定支持的最大并发量，一个社交平台的评论接口最大并发用户数为5000，即同时有5000用户发起请求时，系统仍能保持稳定响应，并发用户数过高可能导致资源竞争（如CPU、内存占用飙升），引发性能瓶颈，可通过压力测试工具（如JMeter、Locust）模拟并发场景，确定系统的承载上限。
资源利用率
资源利用率指服务器在运行API时，CPU、内存、磁盘I/O、网络带宽等硬件资源的占用率，合理的资源利用率应在70%以下，避免因资源耗尽导致服务崩溃，若CPU利用率持续高于90%，可能意味着算法计算密集或存在死循环，需优化代码逻辑；若内存利用率过高，则需检查是否存在内存泄漏（如未释放的对象），通过监控工具（如Prometheus+Grafana）可实时跟踪资源使用情况，提前预警风险。
可用性
可用性指API在指定时间内能够正常提供服务的时间占比，计算公式为：可用性 =（总时间 - 故障时间） / 总时间 × 100%，通常用“几个9”衡量，如99.9%的年可用性意味着全年故障时间不超过8.76小时，高可用性是业务连续性的保障，需通过冗余设计（如多可用区部署）、故障转移（如自动切换备用服务器）和定期容灾演练实现，电商大促期间需确保核心支付接口可用性达到99.99%，避免因服务中断造成损失。
API性能指标分级建议
| 指标类型 | 优秀值 | 良好值 | 需优化值 |
|---|---|---|---|
| 响应时间 | <100ms | 100-300ms | >500ms |
| 吞吐量（QPS） | >10000 | 5000-10000 | <1000 |
| 错误率 | <0.1% | 1%-1% | >1% |
| 并发用户数 | 承载上限的80% | 承载上限的60% | 超过承载上限 |
| 资源利用率 | <50% | 50%-70% | >90% |
| 可用性 | 99% | 9% | <99% |
综合来看，API接口性能优化需结合业务需求，平衡响应时间、吞吐量与资源成本，通过实时监控各项指标，建立性能基线，可快速定位问题并持续迭代优化，最终为用户提供稳定、高效的服务体验。
