SMBJ performance compare to JCIFS library

[NiravR]

Hi @hierynomus , Can you please help me in performance of SMBJ v/s JCIFS. I am trying to compare SMBJ file upload/download operation with JCIFS library file upload/download operations. But I found that SMBJ takes same or higher time then JCIFS library. What I expect is that SMBJ should perform faster then JCIFS.

So please confirm if I am correct or something i missed in this.

[hierynomus]

Depending on how your server and client are setup (ie. buffer sizes matter!) it all depends. In our own measurements, SMB was a huge factor faster than JCIFS. Use sufficiently large files to measure throughput speed.

[NiravR]

@hierynomus Thanks for prompt reply. I have checked in one other old server (Enabled with SMB 2) and I found out that SMBJ performance is very high in that server. So you are right it may be require to tune Buffer size on Server. We are checking in that direction with our Admin guy.

Thanks again.

[hierynomus]

Good luck, closing this issue.

If you obtain any good measurements, feel free to send them my way. Would be good to add some performance measurements to the documentation.

[NiravR]

Ok @hierynomus. We tried in our environment and we found good results for SMBJ library compared to JCIFS. The figures are attached here fyi

Thanks a lot for your help. And appreciate your efforts.

[hierynomus]

Thanks!

[pepijnve]

The fact that the 1KB case is significantly slower than jcifs is a bit surprising. Is it possible to share the code for this benchmark? There might be some room for optimisation.

For small file datasets you want to try and keep the protocol overhead (number of roundtrips to the server) as low as possible. To do that you need to, among other things, ensure you only obtain a file handle once and perform all operations using that file handle. That means not using the convenience methods on DiskShare that take a String path parameter, but using the SMB2FileId ones instead. Or call DiskShare#open once and perform all operations on the same File instance.

[harisingh-highq]

The following lines of code used for file upload:- share = (DiskShare) session.connectShare("data"); String localfilePath = "D:\IMP\FileList\test_1KB.txt"; java.io.InputStream uis = new FileInputStream(localfilePath); File smbFile = share.openFile(filePath, EnumSet.of(AccessMask.GENERIC_WRITE, AccessMask.GENERIC_READ), null, null, SMB2CreateDisposition.FILE_OVERWRITE_IF, null);

smbFile.write(new InputStreamByteChunkProvider(uis)); smbFile.close();

As per your previous comment, i have used DiskShare.open for file write. Can you please look into this?

[pepijnve]

The code looks fine; not much you can do to improve that.

Looking at the numbers for the 1KB row, there's a lot of variability in the measured times. That probably means the environment is not an identical state (as far as that's possible with his type of tests) when running the tests. For instance, JCIFS has min time of 27ms and max of 771ms; SMBJ min of 88ms and max of 400ms. With results that are so far apart you're probably measuring differences in external factors (local disk, network, file server) rather than the performance of the library itself. As long as you don't focus too much on the exact numbers that's fine of course.

My conclusion is that smbj is in the same ballpark as jcifs for small files; quite a bit faster for large files. That difference probably has more to do with optimisations allowed by SMB 2.0 (multi credit requests) than anything else.

[hierynomus]

Indeed, the fact that you're allowed to transfer larger packets really speeds up big file transfers.

2017-11-22 15:31 GMT+01:00 Pepijn Van Eeckhoudt notifications@github.com:

The code looks fine; not much you can do to improve that.

Looking at the numbers for the 1KB row, there's a lot of variability in the measured times. That probably means the environment is not an identical state (as far as that's possible with his type of tests) when running the tests. For instance, JCIFS has min time of 27ms and max of 771ms; SMBJ min of 88ms and max of 400ms. With results that are so far apart you're probably measuring differences in external factors (local disk, network, file server) rather than the performance of the library itself. As long as you don't focus too much on the exact numbers that's fine of course.

My conclusion is that smbj is in the same ballpark as jcifs for small files; quite a bit faster for large files. That difference probably has more to do with optimisations allowed by SMB 2.0 (multi credit requests) than anything else.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/hierynomus/smbj/issues/253#issuecomment-346366484, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHLo_N14p0JrX2W3DlX6rBGkcmf_IlWks5s5DBKgaJpZM4QleMA .

[jansohn]

I've also compared the libraries (+ jcifs-ng) and concluded that jcifs (with large read/write patch) performs a bit better than smbj. I guess the difference lies within the protocols SMB1 and SMB2.

For SMB2 file transfers smbj performed better than jcifs-ng. I've posted the results here: https://github.com/AgNO3/jcifs-ng/issues/106