我的公司在性能要求相当高的路径上使用 redis。nginx 服务器对每个请求调用一次。调用本身有几个参数，目前大约 80 字节。此调用通过网络发送到 redis，redis 将参数传递给它已加载的 lua 脚本，然后做出决定并返回。
我的老板认为，在这些参数中添加额外的 32 字节字符串与在 lua 脚本中硬编码字符串（出于其他原因，这很糟糕）相比，是令人无法接受的糟糕做法，因为“如果我们在一秒钟内收到 50k 个请求，那么这一秒钟就会产生 1.6GB 的额外网络流量。”我的直觉是，这不是一个问题。流量是从 EC2 实例到 ElastiCache 实例的，我认为由于数据包的工作方式以及请求已经很小，这 32 个额外的字节不太可能在两端的网络堆栈中产生显著的处理成本。我完全错了吗？
答案1
表现
整个应用程序的性能不会受到任何影响。您可以花费大量时间进行微基准测试。但是，由于您在一个地方增加了请求，因此可能会对整个应用程序产生连锁反应。只要您不增加 IP 数据包的数量，如果网络延迟很高，性能损失就会很小。底线是基准测试。在代码中保留一个选项，以便能够选择在运行时使用哪种实现（例如切换选项）。
代码质量
通常，拥有良好的代码质量和扩展应用程序的空间比限制自己更重要。您可以稍后设计一个过滤器，以最小化、压缩、缓存等您流向 redis 的流量，这将帮助您获得比小幅优化更快的速度。