Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate if a buffer size of 1024 bytes is adequate when downloading files #65

Closed
ChristianCiach opened this Issue Apr 5, 2019 · 7 comments

Comments

Projects
None yet
2 participants
@ChristianCiach
Copy link

commented Apr 5, 2019

ConfigImpl.doUpdate() uses a byte array of size 1024 as a buffer to read from the InputStream that downloads the jar files:

byte[] buffer = new byte[1024];

I don't know if this is the optimal size for the buffer. Sometimes we see very slow downloads, while Java Webstart remains fast. I didn't yet try to hack update4j and use alternative buffer sizes.

According to https://stackoverflow.com/a/15078116/1507544 and https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6444633 , 8k seems to be regarded as the optimal buffer size by some people.

@mordechaim

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

@mordechaim

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

@mordechaim

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

@ChristianCiach

This comment has been minimized.

Copy link
Author

commented Apr 6, 2019

I am sorry for the late reply.

Also note, increasing the buffer will cause the progress callbacks to be called less frequently resulting in less smooth progress bar updates on a slow network.

Actually, I consider this to be a plus! I think UpdateHandler.updateDownloadProgress(..) is probably called way too often for most people. I noticed this very early in development, so I've implemented it this way to lessen the strain on the Event Dispatch Thread:

	private int previousProgressPercent = -1;

	@Override
	public void updateDownloadProgress(float frac) throws Throwable {
		int newProgressPercent = (int) (frac * 100);
		if (newProgressPercent != previousProgressPercent) {
			previousProgressPercent = newProgressPercent;
			EventQueue.invokeLater(() -> oauthLoginDialog.setProgress(newProgressPercent));
		}

	}

The total download size of our app is around 100 MB. With a buffer size of 1K, the callback would be called approximately 100,000 times. I think most people don't need a progress bar that represents the progress down to the fraction of a permille :) In the worst case, people don't notice the high frequency of this method call, doing some expensive computation, thus creating a bottleneck.

As you can see, I took care to repaint the GUI only up to one hundred times. Because of this, the download speed doesn't improve even when I remove my updateDownloadProgress-callback. I don't implement updateDownloadFileProgress.

Debugging the occasionally slow download speed is tough, because it only happens on some clients. On other clients, download speed is comparable to Java Webstart (maybe a bit slower, but nothing worth mentioning). But on some clients, the download takes several minutes instead of several seconds, while Webstart is still as fast as it should be.

I guess this could have something to do with different network configurations, like MTU sizes and stuff. This is why I suspect that the buffer size could have something to do with this, because on Stackoverflow some people say that the buffer size is related to the MTU (and should be at least as big as the MTU, which is usually 1492 or 1500 bytes).

I do not have hard evidence to prove this claim. As I said, I didn't yet try it with a hacked update4j (and this is tough to do, because I can't even reproduce the issue on my developer workstation). Nonetheless, I think changing the buffer size from 1K to 8K is the right thing to do, even if it may not directly fix the issue at hand.

@ChristianCiach

This comment has been minimized.

Copy link
Author

commented Apr 6, 2019

Is it the actual download that is slow compared to webstart (the download percent progresses slowly)?

Just to be clear: Yes, this is exactly the case. The download percent progresses very slowly on some machines, compared to Webstart.

@mordechaim

This comment has been minimized.

Copy link
Contributor

commented Apr 7, 2019

Btw do you use signature validation? The process also runs between buffer refills that might be the culprit.

@ChristianCiach

This comment has been minimized.

Copy link
Author

commented Apr 7, 2019

Btw do you use signature validation?

Yes, of course I do :)

@mordechaim mordechaim closed this in 01ea284 Apr 8, 2019

mordechaim pushed a commit that referenced this issue Apr 8, 2019

mordechaim pushed a commit that referenced this issue Apr 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.