lets try more threads :) => There are 400 threads configured. But Tomcat only uses max 20-30. Because that's how the application is written.
First I was unable to reproduce any issues with login Vanilla version login in 0.6seconds => I know that with 1 user the login method call takes 500ms. The thing is: With 120 users it takes 8-10seconds. That just doesn't scale well. I would vote against any changes in this area Let it be 2000 years for new user => That just doesn't scale well. How did you come up with 1024 * 16 ? You just chose the maximum number? What's the compromise in those numbers vs making the application actually usable in real life ? It has to be balanced. You can create your custom crypt implementation You can even set it to use MD5 which is super fast :))) => I don't want to use MD5. There is nothing wrong with SCrypt. We just over-tuned those settings. Creating my own crypt implementation (just to reduce 1 parameter) would still mean I fork OpenMeetings and built my own version of it. WebSocket processing locks the pages Thus you can think of it as "synchronous" block of code => Well I think the discussion for me moved on: 1) The number of WebSocket calls are too many 2) addListener method/event takes up to 4seconds => In order to scale up user numbers there has to be some work done in order to speed that up. Thanks Sebastian 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 Wed, 10 Feb 2021 at 23:43, Maxim Solodovnik <[email protected]> wrote: > 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 >
