Testing an upload limit or a slow upload

“Uploads keep failing” or “it’s slow when we load lots of files” could mean a size limit, a cost for each file, a slow connection or a timeout. Real files make poor tests, as they’re never quite the size you need and may hold things that shouldn’t be sent around. Test files of exact sizes, an expected time to compare against, and a record of what actually happened let you tell those causes apart, and give a supplier something precise to work with.

1. Make test files of exact sizes

Open the Test File Generator. To find a size limit, make one file just under it and one just over, such as 9.9 and 10.1 MB. Check which units the limit uses: MB here is 1,000,000 bytes and MiB 1,048,576, and a limit stated as “10 MB” can mean either. Set Fill with to Random bytes, as zeros or repeated text compress to almost nothing on the way and would hide a size problem.

To see whether the number of files matters, make the same total twice: once as One file, and once as Several files (ZIP) with Each file set to, say, 1 MB, then unzip the second. If the hundred small files take far longer than the one large one, the time goes on handling each file, not on moving the data. To check what a ZIP really holds before you send it, open it in the ZIP Viewer & Maker: it lists each file with its size, and the same page can make a ZIP from files you choose or a folder, if the upload takes only one file.

2. Work out how long it should take

In the Unit Converter, fill in Transfer time with the file’s size and the connection’s upload speed. Broadband and network speeds are sold in megabits per second (Mbit/s), which is eight times smaller than the megabytes per second (MB/s) most upload screens show; the Data rate category converts between them. The answer is the best case: if an upload takes several times longer, the slowness is somewhere other than the line.

3. Capture what the browser did

Before uploading, open the browser’s developer tools on the Network tab (press F12, or Option-Command-I on a Mac; in Safari, turn on the Develop menu first), then upload the test files. Afterwards, save the capture as a HAR file, using the tab’s export button or by right-clicking a request (the wording differs between browsers, such as Save all as HAR or Export HAR).

Open it in the HAR Viewer & Redactor. Each request shows its status, size and time, and failed ones are in red: a 413 means the server refused the size, a 408 or 504 that something gave up waiting. A HAR holds cookies and sign-in tokens, so if you need to send it to anyone, use Save the redacted HAR and send that copy.

4. Match it to the server’s log

If you can get the server’s or application’s log, open it in the Log Viewer and set From and To to the minutes around your test. Untick everything but errors and warnings to see what went wrong, or type the file’s name in Contains to follow it through. Tick Show each entry’s time in my time zone if the server logs in UTC or another zone, so its times line up with when you ran the test.

If the limit turns out to be real and can’t be raised, and the receiving end can put the file back together, File Split & Join cuts a large file into parts of a size you choose (parts of this many MB) named name.001, name.002 and so on. Its Join side puts them back in order and refuses if a part is missing or the sizes don’t fit. It can’t tell if a part was changed on the way, so compare the joined file with the original in Hash / Checksum.

Put the results side by side (the sizes, the expected and actual times, the status codes and the log lines) and the cause is usually plain, or at least precise enough for whoever looks after the system.