Cyberduck Mountain Duck CLI

Opened 13 years ago

Closed 8 years ago

Last modified 8 years ago

#185 closed enhancement (fixed)

Slow SFTP transfers

Reported by: wout.mertens@… Owned by: dkocher
Priority: high Milestone: 3.8
Component: sftp Version: 3.5
Severity: major Keywords:
Cc: pratik.solanki@… Architecture: Intel
Platform: Mac OS X 10.6

Description

If I use the command line sftp client on the local network, I can get transfer speeds of several MB/s.

If I use CyberDuck, the fastest it gets is 600KB/s, which was after I tried increasing the buffer size to 65536.

Is this a known problem? Cyberduck is still nice, but useless for local networks...

Attachments (3)

patch_upload_poc.diff (5.7 KB) - added by caeies 8 years ago.
proof of concept for the parallelism upload (I've got maximum bandwith in this case)
Upload_with_status_queue.patch (9.4 KB) - added by dkocher 8 years ago.
Upload with status queue.
Ciphers.patch (10.8 KB) - added by dkocher 8 years ago.
Higher priority for weaker ciphers

Download all attachments as: .zip

Change History (76)

comment:1 Changed 13 years ago by dkocher

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate for #123.

comment:2 Changed 13 years ago by wmertens@…

  • Resolution duplicate deleted
  • Status changed from closed to reopened

This is _not_ a dupe of #123. That one says that CyberDuck doesn't support compression, resulting in slower transfers. While that may be true for WAN transfers, adding compression over LAN transfers will actually slow them down.

The issue is that CyberDuck is about 10x slower than the sftp client on a LAN, with compression disabled.

Isn't this a really easy one to verify?

comment:3 Changed 13 years ago by Michael Schubart

I noticed the same thing. Cyberduck: A few 100 KByte/s. Command line scp: a few MByte/s.

comment:4 Changed 13 years ago by mfichtner

The problem still seems to exist in the latest pre-release 2.5.5. Download speed through SFTP is still approx. 10% of the available bandwidth.

comment:5 Changed 13 years ago by analogue

  • Milestone set to 2.5.5
  • Version changed from 2.5.4 to 2.5.5

Same for me, using the 2.5.5, I get ~85KB/s using Cyberduck, and ~400KB/s using the command line sftp client.

comment:6 Changed 13 years ago by dkocher

  • Priority changed from normal to high
  • Status changed from reopened to new

This is a bug in the SSH I/O code and has nothing to do with the Java language used. Java has a very good network performance in general; e.g. see FTP transfers in Cyberduck. Please don't write any silly annonymous postings here, please.

comment:7 Changed 13 years ago by dkocher

  • Milestone changed from 2.5.5 to 2.6

comment:8 Changed 13 years ago by dkocher

  • Status changed from new to assigned
  • Summary changed from slow transfers to Slow SFTP transfers

comment:9 Changed 13 years ago by anonymous

  • Cc jason@… added

comment:10 Changed 13 years ago by anonymous

  • Cc ian@… added

comment:11 Changed 13 years ago by doml

Ditto.

Fugu transfers files at 11-12MBps whereas CyberDuck transfers up to about 3MBps if I'm transfering multiple items at once or ~1-1.2 MBps for a single transfer.

Also, CyberDuck crashes on large file transfers (4-20GB per file) which may or may not be a symptom of the same problem.

comment:12 Changed 13 years ago by wildag@…

I concur on this one. ~88 kBps with Cduck, and ~7.8MB (yes, that's bytes) with scp.

comment:13 Changed 12 years ago by erik.bryn@…

I'm experiencing the same problem, 240KB/s with Fugu... 20KB/s with Cyberduck...

Any idea when this is going to be fixed?

comment:14 Changed 12 years ago by anonymous

I confirm it, 200KB/s with Cyberduck, 1.8MB/s by scp on terminal.

comment:15 Changed 12 years ago by ken@…

I may have just entered a duplicate of this bug at http://trac.cyberduck.ch/ticket/656

My symptoms appears to be the same. My connection is not inside a LAN, though.

comment:18 Changed 12 years ago by dkocher

I will do a prototype replacing the current SSH implementation with Ganymed.

comment:19 Changed 12 years ago by psolanki

  • Cc pratik.solanki@… added

comment:20 Changed 12 years ago by dkocher

  • Milestone changed from 2.9 to 2.8

The latest nightly build (2844) featueres Ganymed SSH2. Performance issues still exist, but at least uploads reach here 1MB/s over the loopback interface. This issue will only be resolved by using parallel requests as OpenSSH does. See r2839 and r2840.

comment:21 Changed 12 years ago by dkocher

  • Resolution set to fixed
  • Status changed from assigned to closed

Refer to the latest nightly builds at http://update.cyberduck.ch/nightly/. Try Preferences > SFTP > File Transfers > Use SCP.

comment:22 Changed 10 years ago by anonymous

  • Version changed from 2.5.5 to 3.0.1

Hi,

I'm very thankful that this is fixed however I would STRONGLY suggest that the default setting is set to SCP for SFTP transfers instead of having to dig into these forums to try to determine that this in fact solves the problem.

ALSO if someone elects SFTP as the transfer protocol it would be nice to have a message stating that there are issues with large transfers and the order of magnitude may be 10x slower as an FYI due to underlying libraries (not Cyberduck).

--Nikolaos

comment:24 Changed 10 years ago by anonymous

goodness gosh this is slow. i have set it to SCP and even tiny files are taking ages to upload. the menu to select active over passive connect mode is greyed out. i think i am going to need a different FTP client unless i can fix this.

comment:25 Changed 10 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

Set to SCP and still it's ridiculous, 4-5MB/s vs 25-30MB/s. SFTP is dumbfounding, 200KB/s?!?

Why the fuck is this thing so slow? Thank god I'm good with a CLI; but I can't recommend this app to friends in good conscious.

comment:26 Changed 10 years ago by p4dre

switch to scp ind sftp settings

solved it for me

comment:27 Changed 10 years ago by anonymous

when I switched to scp, speed problem was gone. but I can't upload files with scp mode

comment:28 Changed 10 years ago by ian@…

  • Cc ian@… removed

comment:29 Changed 10 years ago by jason@…

  • Cc jason@… removed

comment:30 Changed 10 years ago by dkocher

  • Type changed from defect to enhancement

comment:31 Changed 10 years ago by george

Just to say, I've got the same problem with the latest version. For example, downloading from a Linode VPS via SFTP today I get about 50KB/s using Cyberduck, or 800KB/s with Fugu (or rsync, for that matter).

Cyberduck is no use to me until this is fixed, so I'd certainly call that a defect rather than an enhancement. Shame, because I like its style.

comment:32 Changed 10 years ago by Nick C

I'm still a little confused about whether Cyberduck supports compression over SFTP (as in rsync -z). Do you have to use either SFTP or SCP mode to get this to work?

Fugu has a checkbox for this for each connection. Even if it does, the user interface could better clarify this with a "compression" checkbox under "More Options" in the "Open Connection" window.

Of course there are times when this compression is desirable and times when it isn't, so a per-connection setting would be really handy.

comment:33 Changed 9 years ago by popolli

Cyberduck was always slow and it is still in the 3.2.1. Just had 35KB/s in comparison to 650KB/s with scp.

comment:34 Changed 9 years ago by jm

Four years and still nothing. This is marked as an enhancement, yet this is quite a major defect. Enough so to keep me away.

comment:35 Changed 9 years ago by henrik

I'm sorry? I really like cyberduck for FTP, but marking this major defect as an enhancement makes no sense. SFTP transfers are dog slow, and nearly unusable. Why? Why no love for SFTP? Why? Don't you see all the children crying in the street for reasonable-speed encrypted transfers?

comment:36 Changed 9 years ago by dkocher

#2278 closed as duplicate.

comment:37 Changed 9 years ago by yla

#4191 closed as duplicate.

comment:38 Changed 9 years ago by papa_strumpf@…

For those complaining how SCP is faster than SFTP: http://en.wikipedia.org/wiki/SSH_file_transfer_protocol#File_transfer_speed.2C_SCP_vs_SFTP

So, when replying to this "enhancement", please use the sftp command for comparison, not scp.

comment:39 Changed 9 years ago by masc@…

what's wrong about how filezilla does it. SFTP performance is excellent there.

comment:43 Changed 9 years ago by caeies

  • Architecture set to Intel
  • Platform set to Mac OS X 10.6
  • Version changed from 3.0.1 to 3.5

Hi,

Is there a way to solve these speed issues ? There's still a lot's of problem in the latest version (just downloaded the latest one today 3.5(6066) ). and sftp transfert are around 6 to 10 x slower than using the scp /sftp command line. If I can be of any help, please let me know.

Regards,

Caeies.

comment:44 in reply to: ↑ description Changed 8 years ago by psaint

  • Severity changed from normal to major

As of Version 3.5.1 (6117) it is still an issue. Regardless of protocol selected (SFTP/SCP) transfer speeds are 10 time slower for SCP and up to 20 times slower for SFTP when compared to command line tools.

Last edited 8 years ago by dkocher (previous) (diff)

comment:45 Changed 8 years ago by dkocher

#5299 closed as duplicate.

comment:46 Changed 8 years ago by dkocher

#5327 closed as duplicate.

comment:47 Changed 8 years ago by dkocher

  • Milestone changed from 2.8 to 4.0
  • Resolution set to fixed
  • Status changed from reopened to closed

In r7500. Parallel reading of SSH_FXP_DATA. SFTP transfer speed should be comparable to OpenSSH now.

comment:48 Changed 8 years ago by dkocher

An updated snapshot build will be available shortly.

comment:49 Changed 8 years ago by caeies

  • Resolution fixed deleted
  • Status changed from closed to reopened

Hi all,

I've just try the 4.0b5 (r7501) build today ... It doesn't seems that the "fix" is working here. Is there something to configure somewhere ?

sftp (command line) is around 5MB/s when cyberduck is around 80KB/s on the same file in SFTP mode and 300KB/s for scp mode.

Worst : If I try the 3.7 (r7380) then the SFTP mode give me ~150KB/s and scp one around 300KB/s ... looks like a regression to me, or ?

Any way to get any debug from cyberduck ? I saw in the sources some log stuff, but didn't get anything in the preference panel to see where the log goes ...

Thanks for taking care of this one. Some of my users are trying to push ~40GB at 150KB/s ... ouch.

regards,

Caeies.

comment:50 Changed 8 years ago by caeies

I svn co the code and "played" a little bit with the code and the buffers. I reach ~200KB/s by changing :

  • the max_parallelism from 10 to 8 (SFTPv3Client.java)
  • the buffer request from 2000 -> 4096 ("")
  • the default connection.chunksize * by 16 ... (Preference.java)

A little bit of reading about the SFTP Protocol let me think that bigger are the buffers, Quicker are the downloads ...

I will try to investigate a little bit more in what you call the parallelism read ...

Regards,

Caeies.

comment:51 Changed 8 years ago by yla

Thanks for your investigation. Just wanted to let you know that we are about to refactor the SFTPv3Client code. So far we got some very good result but we still have some issues with bandwith trotthling.

comment:52 Changed 8 years ago by caeies

Ok, good to know that :)

If it can help :

  • I take a look at the sftp stuff (the openssh client) and it seems that the window adjust size is around 131072 when yours, in my last, tries is around 16384.
  • I have tested message size of 4096 -> 32768 and a chunksize of 32768*64 and max_parallelism set to 100 I've reached then ~300KB/s.

If you need more testing, let me know.

Good luck with the refactorisation of the SFTPv3Client.

regards, Caeies.

comment:53 Changed 8 years ago by dkocher

  • Resolution set to fixed
  • Status changed from reopened to closed

In r7523. Please give it a try in the latest snapshot build available through software update. Let me know what throughput you get.

comment:54 Changed 8 years ago by caeies

Yeah, looks far much better :) (i've done an update in my sources)

I'm near the maximum download speed of my ADSL line ... Looks good to me.

I've just take a quick look in your diff, and notice A potential bug (but I'm not sure on that) :

 	1171	        for(OutstandingRequest r : pendingQueue.values()) { 
 	1172	            // Server offset should take pending requests into account. 
 	1173	            serverOffset += r.len; 
 	1174	        } 

Doing so, you assume that each packet come one after one, when parallelism doesn't allow you to do so. IIRC the offset information is in the received packet (but I'm not an expert, just looking at what sftp does).

What do you think ?

Regards, and thanks for this fix, users will really be happy !

Caeies.

comment:55 follow-up: Changed 8 years ago by caeies

Hum just another guess.

Do we have the same problem when uploading files ?

That's harder to test due to bdwth limitation, but should be ok on a LAN ?

Doing the tests I've got on my LAN ~5MB/s in download but only 1MB/s in upload ... So perhaps a problem there ?

Regards.

Caeies.

comment:56 follow-ups: Changed 8 years ago by caeies

Back again,

For your information the bandwidth (according to download via sftp) is around 11MB/s on my LAN. So there's still a x2 factor missing somewhere.

Regards,

Caeies

comment:57 in reply to: ↑ 56 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

Back again,

For your information the bandwidth (according to download via sftp) is around 11MB/s on my LAN. So there's still a x2 factor missing somewhere.

Is that what you get with OpenSSH? One should compare the size of the local window getting adjusted during this transfer in comparison. Run sftp -vvv.

comment:58 in reply to: ↑ 55 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

Hum just another guess.

Do we have the same problem when uploading files?

OpenSSH does not use parallel requests there from what I know but one could try if sending multiple write requests in a batch and reading status later would make a difference there, too.

comment:59 Changed 8 years ago by dkocher

Addendum in r7525.

comment:60 in reply to: ↑ 57 Changed 8 years ago by caeies

Replying to dkocher:

Replying to caeies:

Back again,

For your information the bandwidth (according to download via sftp) is around 11MB/s on my LAN. So there's still a x2 factor missing somewhere.

Is that what you get with OpenSSH? One should compare the size of the local window getting adjusted during this transfer in comparison. Run sftp -vvv.

Yeah, That's what I get with openSSH. sftp -vvv give me a window of 131072 (comment:52) when yours is around ~92000 IIRC (I don't have any mac computer at home). That's only for download (I didn't try the upload with -vvv). And it was 16384 when I was playing around with the different chunksize / message length ... So it's clearly better, but "could he higher" :). And yes there's 64 or 65 requests at the same time (If you log at the logs R = 65 in my case).

comment:61 in reply to: ↑ 58 Changed 8 years ago by caeies

Replying to dkocher:

Replying to caeies:

Hum just another guess.

Do we have the same problem when uploading files?

OpenSSH does not use parallel requests there from what I know but one could try if sending multiple write requests in a batch and reading status later would make a difference there, too.

Are you sure ? I just made a quick try and the window size is the same as for download one, and the window is increased at the beginning of the upload. And answers come from the server only after 73 requests have already been sent ... Size of the write is 32768 per SSH2_FXP_WRITE message If this can help.

comment:62 follow-up: Changed 8 years ago by caeies

Ok reading you code, I think that the main problem is that you are waiting for the ACK before continuing to send data, while openSSH just send stuff as fast as it can until he fills the queue, then check for ACK when the sent queue is filled ...

Hope this helps,

regards,

Caeies (good night).

Changed 8 years ago by caeies

proof of concept for the parallelism upload (I've got maximum bandwith in this case)

comment:63 follow-up: Changed 8 years ago by caeies

I added a small patch as a POC for upload limitation. This patch will illustrate that doing parallel request for writing is faster than the current code.

However, due to my little understanding of your code, This POC is a little bit buggy since it will not clear the waiting queue for the last 64 requests ... And I've got no idea on how to do this with the current framework you're using.

Hope this helps.

Caeies

comment:64 in reply to: ↑ 56 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

Back again,

For your information the bandwidth (according to download via sftp) is around 11MB/s on my LAN. So there's still a x2 factor missing somewhere.

You could try what impact the cipher has on the transfer speed. We are usually negogiating aes256-ctr wheras OpenSSH prefersaes128-ctr. You could put the weaker cipher on top in BlockCipherFactory.java for testing.

comment:65 in reply to: ↑ 63 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

I added a small patch as a POC for upload limitation. This patch will illustrate that doing parallel request for writing is faster than the current code.

However, due to my little understanding of your code, This POC is a little bit buggy since it will not clear the waiting queue for the last 64 requests ... And I've got no idea on how to do this with the current framework you're using.

Thanks for the patch. I have something half-baked here as well and will try to see if I can combine best of both worlds.

comment:66 in reply to: ↑ 62 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

Ok reading you code, I think that the main problem is that you are waiting for the ACK before continuing to send data, while openSSH just send stuff as fast as it can until he fills the queue, then check for ACK when the sent queue is filled ...

I don't see how the patch attached changes this behaviour. It will still toggle between writing and reading the status.

Changed 8 years ago by dkocher

Upload with status queue.

comment:67 in reply to: ↑ 65 Changed 8 years ago by dkocher

Replying to dkocher:

Replying to caeies:

I added a small patch as a POC for upload limitation. This patch will illustrate that doing parallel request for writing is faster than the current code.

However, due to my little understanding of your code, This POC is a little bit buggy since it will not clear the waiting queue for the last 64 requests ... And I've got no idea on how to do this with the current framework you're using.

Thanks for the patch. I have something half-baked here as well and will try to see if I can combine best of both worlds.

Let me know the results with the patch attached and how it compares to the previous upload implementation.

comment:68 in reply to: ↑ 66 ; follow-ups: Changed 8 years ago by caeies

Replying to dkocher:

Replying to caeies:

Ok reading you code, I think that the main problem is that you are waiting for the ACK before continuing to send data, while openSSH just send stuff as fast as it can until he fills the queue, then check for ACK when the sent queue is filled ...

I don't see how the patch attached changes this behaviour. It will still toggle between writing and reading the status.

Yes, but after parallelism requests only. So it doesn't wait for the network latency just after sending the first request and so on ... it will read back the answer only after the 64th requests, so when the server starts to reply to the requests and that the requests are back to the client.

Anyway, the main problem of this patch is the lasts 64th requests that aren't checked at the end of the download.

Hope I'm clear Caeies.

comment:69 in reply to: ↑ 68 Changed 8 years ago by dkocher

Replying to caeies:

Replying to dkocher:

Replying to caeies:

Ok reading you code, I think that the main problem is that you are waiting for the ACK before continuing to send data, while openSSH just send stuff as fast as it can until he fills the queue, then check for ACK when the sent queue is filled ...

I don't see how the patch attached changes this behaviour. It will still toggle between writing and reading the status.

Yes, but after parallelism requests only. So it doesn't wait for the network latency just after sending the first request and so on ... it will read back the answer only after the 64th requests, so when the server starts to reply to the requests and that the requests are back to the client.

Anyway, the main problem of this patch is the lasts 64th requests that aren't checked at the end of the download.

Hope I'm clear Caeies.

I understand and the patch my own patch attached should fix this issue with the same characteristics of sending out multiple write requests before reading any status. Let me know about the results compared to no parallelism. Thanks again for your help here, much appreciated!

comment:70 follow-up: Changed 8 years ago by caeies

Replying to dkocher:

Replying to dkocher:

Replying to caeies:

I added a small patch as a POC for upload limitation. This patch will illustrate that doing parallel request for writing is faster than the current code.

However, due to my little understanding of your code, This POC is a little bit buggy since it will not clear the waiting queue for the last 64 requests ... And I've got no idea on how to do this with the current framework you're using.

Thanks for the patch. I have something half-baked here as well and will try to see if I can combine best of both worlds.

Let me know the results with the patch attached and how it compares to the previous upload implementation.

Sorry, I don't have the time right now to make the tests, but I will try to look at them this WE. I go quickly through your patch, and I'm not sure of all the changes you made. I will try to look carefully this WE too.

Do you have any other changes in the pipe for SFTP client ? So I don't take too much time to change something already changed :).

Thanks for your help.

Caeies.

(PS : whoops, you were quicker than me to reply :).

Changed 8 years ago by dkocher

Higher priority for weaker ciphers

comment:71 in reply to: ↑ 70 ; follow-up: Changed 8 years ago by dkocher

Replying to caeies:

Do you have any other changes in the pipe for SFTP client ? So I don't take too much time to change something already changed :).

I attached a modified list of the preferred ciphers as a patch. You can experiment with these as well to test if that impacts throughput. I don't have anything else here.

comment:72 in reply to: ↑ 64 Changed 8 years ago by caeies

Replying to dkocher:

Replying to caeies:

Back again,

For your information the bandwidth (according to download via sftp) is around 11MB/s on my LAN. So there's still a x2 factor missing somewhere.

You could try what impact the cipher has on the transfer speed. We are usually negogiating aes256-ctr wheras OpenSSH prefersaes128-ctr. You could put the weaker cipher on top in BlockCipherFactory.java for testing.

So more info on this :

I try sftp with the -o Ciphers=aes256-ctr option. The download speed is around the same than previously. But the window size looks like the same as the one used by cyberduck (which looks great :). So the download speed issue is still there. I will try to switch to weaker cipher as suggested in cyberduck, but not sure it's the issue.

regards,

Caeies

comment:73 in reply to: ↑ 71 ; follow-up: Changed 8 years ago by caeies

Replying to dkocher:

Replying to caeies:

Do you have any other changes in the pipe for SFTP client ? So I don't take too much time to change something already changed :).

I attached a modified list of the preferred ciphers as a patch. You can experiment with these as well to test if that impacts throughput. I don't have anything else here.

Yes there's an impact. I'm around 7MB/s now instead of around 5,2MB/s ... Still far away the ~11MB/s of the upload speed or sftp download speed. So I guess that there's still a problem in the download code. I will try to take some time to test it.

Regards,

Caeies.

PS: btw the svn wasn't able to compile this morning due to @Override in 3 *Sessions files.

comment:74 follow-up: Changed 8 years ago by caeies

Hum, still the download speed issue. I tried a higher parallelism factor but that doesn't help. My last guess is that perhaps we are hitting performances issues in the code of the download. The window size is always "low" no more than ~98343 when the window size of sftp is higher + 134K).

Unfortunately I don't have the time to profile cyberduck and to look at where is the bottleneck. Probably in the write parts of the download requests (But that could be my computer too :). I guess that cyberduck is near its maximum performance regarding the network layout (As the upload speed seems to indicate).

I will be glad to test new code.

Regards,

Caeies.

comment:75 in reply to: ↑ 73 Changed 8 years ago by dkocher

Replying to caeies:

Replying to dkocher:

Replying to caeies:

Do you have any other changes in the pipe for SFTP client ? So I don't take too much time to change something already changed :).

I attached a modified list of the preferred ciphers as a patch. You can experiment with these as well to test if that impacts throughput. I don't have anything else here.

Yes there's an impact. I'm around 7MB/s now instead of around 5,2MB/s ... Still far away the ~11MB/s of the upload speed or sftp download speed. So I guess that there's still a problem in the download code. I will try to take some time to test it.

Changed priority of ciphers In r7597.

comment:76 in reply to: ↑ 68 Changed 8 years ago by dkocher

Replying to caeies:

Replying to dkocher:

Replying to caeies:

Ok reading you code, I think that the main problem is that you are waiting for the ACK before continuing to send data, while openSSH just send stuff as fast as it can until he fills the queue, then check for ACK when the sent queue is filled ...

I don't see how the patch attached changes this behaviour. It will still toggle between writing and reading the status.

Yes, but after parallelism requests only. So it doesn't wait for the network latency just after sending the first request and so on ... it will read back the answer only after the 64th requests, so when the server starts to reply to the requests and that the requests are back to the client.

Commited upload parallelism with ACK queuing in r7598.

comment:77 in reply to: ↑ 74 Changed 8 years ago by dkocher

Replying to caeies:

Hum, still the download speed issue. I tried a higher parallelism factor but that doesn't help. My last guess is that perhaps we are hitting performances issues in the code of the download. The window size is always "low" no more than ~98343 when the window size of sftp is higher + 134K).

Unfortunately I don't have the time to profile cyberduck and to look at where is the bottleneck. Probably in the write parts of the download requests (But that could be my computer too :). I guess that cyberduck is near its maximum performance regarding the network layout (As the upload speed seems to indicate).

I will be glad to test new code.

I'll leave this closed this until we find clear evidence of other areas for improvement.

comment:78 follow-up: Changed 8 years ago by caeies

Any ideas on how to profile the java code under Mac OSX ? I tried with Shark, but it doesn't seems to be easy to profile a java application :(

comment:79 in reply to: ↑ 78 Changed 8 years ago by dkocher

Replying to caeies:

Any ideas on how to profile the java code under Mac OSX ? I tried with Shark, but it doesn't seems to be easy to profile a java application :(

Your best bet is a Java Profiler which should be able to connect to the running application. jvisualvm comes with OS X but you possibly have to opt for JProfiler or YourKit Java Profiler to get anything more meaningful.

Note: See TracTickets for help on using tickets.
swiss made software