The way it uses threads looks a bit better now: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test+08-02-2021+with+256crypt#OpenMeetings140userstest08022021with256crypt-Tomcatthreadsarebetterused if you compare that to previous: https://cwiki.apache.org/confluence/display/OPENMEETINGS/OpenMeetings+140+users+test#OpenMeetings140userstest-Tomcatactivethreads
=> That spike in threads corresponds with the load on StreamProcessor::onMessage. => It actually starts to use more threads! Which is good. Not enough to get the CPU load down. But better I think 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> On Mon, 8 Feb 2021 at 13: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. > > *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> >
