ihudedi commented on issue #884:
URL: https://github.com/apache/mina-sshd/issues/884#issuecomment-4003535106
Hi @tomaswolf
Thank you for the quick response and context!
You're absolutely right that the LocalWindow logic hasn't changed - I
appreciate the correction. However, my profiling with YourKit definitively
shows that LocalWindow.release() is a hot method consuming significant CPU time
in 2.15.0, which leads me to believe something else changed that causes
release() to be called more frequently or in different patterns than in 2.13.2.
Profiling Evidence:
LocalWindow.release() appears in YourKit's top hot methods during SFTP
uploads
Called ~257 times per 5 seconds on the server side receiving uploads
Each call averages 444 microseconds
The method's cumulative time accounts for a noticeable portion of the upload
operation
My Question:
What changed between 2.13.2 and 2.15.0 that might cause release() to be
called more frequently or with different patterns?
Some possibilities I'm investigating:
1.Changes in how SFTP data is chunked or buffered?
2.Changes in ChannelAsyncOutputStream or packet writing logic?
3.Changes in how consume()/release() are balanced during channel I/O?
Performance Impact:
Implementing the optimizations I suggested (removing AtomicLong redundancy,
increasing threshold, simplifying shouldAdjust) reduced the overhead by 28x and
restored SFTP upload performance to 2.13.2 levels in my environment.
Specific Questions:
1.Has anything changed in the SFTP client/server data flow between 2.13.2
and 2.15.0 that might affect window management patterns?
2.Were there changes to how frequently release() is called per byte
transferred?
I'm happy to provide more data if that would help investigate what's
actually causing the regression.
Thanks,
Itay
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
