As you suggested the crypt is what takes so long in login. See full results here: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+08-02-2021+with+256crypt
*About the Scrypt change and login performance issue gone* I changed the complexity of the Scrypt implementation a lot, and basically there is no login issue anymore. I reduced the N factor from: 1024 * 16 to 256. See commit in my branch: https://github.com/apache/openmeetings/pull/126/commits/8a6e3aa0ce08d900d69fcdb59bd7b7bd11316283 => Doing this basically makes the login performance issue completely gone. See: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+08-02-2021+with+256crypt#OpenMeetings140userstest08022021with256crypt-Loginwebservicecallisfineallwebservicecallsarefine => all WebService calls perform in less than 0.35seconds! There is an article on stackoverflow explaining Scrypt values here: https://stackoverflow.com/a/30308723/1448704 Questions: How did we come up with 1024 * 16 for the N factor in the Scrypt API ? I understand that less cryptographic complexity means that: - *IF* somebody gets hold of the encrypted hash, depending on the relative complexity of the hash, it reduces the theoretical time it would take to decrypt the password Theoretically! But is it really necessary to have 1024 * 16 for the N factor ? How much did I reduce complexity *really* by reducing this value to 256 ? Is it really insecure now or have I just reduced the theoretical decryption time from 2000 years to 100 years ? :) Generally: I think the main thing for us is to (1) Use Scrypt and cryptographic save methods (2) make sure the hash is securely stored and can't be retrieved via the public API. => Given that I think the CPU complexity in SCrypt can be safely reduced to a lower value. *Generally performance issues results* Unfortunately it's not solved yet. Now the next method that starts to take a big hit is the StreamProcessor:onMessage: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+08-02-2021+with+256crypt#OpenMeetings140userstest08022021with256crypt-StreamProcessorsinglemessageeventtakesalmost2seconds => It takes almost 2seconds for a single web socket message to process. And the CPU still spikes to 95%. What we basically did is to move the bottleneck to the next method. Login is not a problem anymore, but because this is much faster now other methods take the hit. That's unfortunately the common thing in performance optimisation :( We just move the bottleneck to the next layer! Now we have to analyse that one! I will have a look for some more detailed trace on what messages are the ones that create the big processing time on the StreamProcessor::onMessage method. Thanks, Seb Sebastian Wagner Director Arrakeen Solutions, OM-Hosting.com http://arrakeen-solutions.co.nz/ https://om-hosting.com - Cloud & Server Hosting for HTML5 Video-Conferencing OpenMeetings <https://www.youracclaim.com/badges/da4e8828-743d-4968-af6f-49033f10d60a/public_url> <https://www.youracclaim.com/badges/b7e709c6-aa87-4b02-9faf-099038475e36/public_url>
