1

This may be a duplicate question but I was unable to find an answer after a search.

I have a communications application that sends data to a central SSH server (TCP). The application is supposed to read data from a file and send(I use an in-house Java implementation of SSH). The transmission is inefficient (I compared same size data transfer over FTP and it was an order of magnitude faster. I know there are overheads with SSH but my previous experience dealing with the protocols tells me our SSH implementation is very slow).

I profiled the application, but I could only get the various % of CPU time spent by methods. I eliminated the obvious time hogs (e.g. negotiate SSH without MAC calculation, etc.) but I can still not improve enough.

How can I detect dead/idle gaps along the datapath (from reading the file through my SSH encapsulation down to TCP transmission)? i.e. how can I find the places where time is spent outside of my data-delivery path, and which impacts the rate of data delivery. Does anybody out there have a suggestion (which profiling tools/approaches/techniques) can be used to find the ?

adaj21
  • 543
  • 3
  • 11
  • 25
  • There is a simple and direct way to detect whatever is responsible for the time being spent, whether it is waiting for things inside or outside the program. [*This is one explanation of it.*](http://stackoverflow.com/a/2425217/23771) Anything that only gives you numbers has a high probability of failing to identify the problem. – Mike Dunlavey Feb 04 '16 at 21:09

1 Answers1

0

For a jvm profiler in sampling mode: you must sample as fast as you can (1 ms) and run as long as you can to improve the capture of rare stackframes samples. Also, you should do all those tests locally to minimize the blocking nw i/o from the sampling data (get the program to do mostly CPU work).

For a jvm profiler in instrumentation mode: make sure you don't hide methods! Instrumentaiton is slower than sampling, so many profilers have default ignore lists. Normally you will get a terrible performance while profiling in instrumentation mode but hang on: a good tool will reveal the invocation counts on each profiled method. It is not useful to look at times in instrumentation mode, but you might detect absurdities in your code based on invocation counts.

In either mode, pay attention to the contention, memory usage, GC pauses... anything that can choke the code independantly from your beautiful code...

And of course, buffer your streams...

user2023577
  • 1,752
  • 1
  • 12
  • 23