jBcrypt:BCrypt.checkpw 突然需要约 30 倍的时间

问题描述 投票:0回答:1

在我们的网络应用程序中,我们使用 jBcrypt 对密码进行哈希处理。我们在对密码进行哈希处理时使用 13 个log_rounds

正常情况下,BCrypt.checkpw()大约需要 1 秒。但有时(几天后),它突然开始变慢,从那时起大约需要 30 秒,并且无法恢复到正常速度。重新启动 Tomcat 是唯一有帮助的事情。

我不会怀疑这种情况是否时常发生,例如 CPU 负载较高或 GC 正在运行。但事实并非如此,它只是突然开始变慢。只有登录过程受到影响,应用程序的其余部分仍然很快。 我们也没有任何可确定的内存泄漏或其他性能问题。只是 BCrypt.checkpw() 很慢。 线程转储显示时间被 BCrypt.checkpw 和后续方法调用消耗,尤其是 BCrypt.encipher:

Thread 8597: (state = IN_JAVA)
 - org.mindrot.jbcrypt.BCrypt.encipher(int[], int) @bci=0, line=490 (Interpreted frame)
 - org.mindrot.jbcrypt.BCrypt.key(byte[]) @bci=122, line=562 (Interpreted frame)
 - org.mindrot.jbcrypt.BCrypt.crypt_raw(byte[], byte[], int) @bci=89, line=629 (Compiled frame)
 - org.mindrot.jbcrypt.BCrypt.hashpw(java.lang.String, java.lang.String) @bci=226, line=692 (Interpreted frame)
 - org.mindrot.jbcrypt.BCrypt.checkpw(java.lang.String, java.lang.String) @bci=3, line=763 (Interpreted frame)

我只在 SO 上发现了一个类似的问题,但在我们的案例中,多个类加载器不会成为问题: 使用 jbcrypt 时性能不稳定且性能下降

有人知道这里发生了什么吗?

bcrypt jbcrypt
1个回答
0
投票

我也遇到了同样的问题,就我而言,罪魁祸首是 JIT 编译器。

BCrypt.encipher() 如果不编译的话会非常慢。当我使用 -XX:+PrintCompilation 打开 JIT 编译日志记录后,发现代码缓存太小了。当我使用 -XX:ReservedCodeCacheSize 增加其大小后,问题就消失了。

© www.soinside.com 2019 - 2024. All rights reserved.