Hello Sebastian, it seems you are not answering to my answers ... lets try more threads :)
On Mon, 8 Feb 2021 at 07:18, [email protected] <[email protected]> wrote: > 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. > First I was unable to reproduce any issues with login Vanilla version login in 0.6seconds I would vote against any changes in this area Let it be 2000 years for new users You can create your custom crypt implementation You can even set it to use MD5 which is super fast :))) > *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. > WebSocket processing locks the pages Thus you can think of it as "synchronous" block of code > 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> > -- Best regards, Maxim
