(How) Can odk Collect be significantly slower sending form compared to similar upload via browser?

Hi,

I've stumbled against something that I can't explain.

I'm using ODK collect to send data to a custom server script written in
php. My forms include an image, a video file and an audio file (all
optional), and few data, so the total amount of bytes to be sent is
basically determined by the media, the xml data being negligible in
comparison.

Now I've tried (well actually not me personally, but the person I'm
working with) uploading exactly the same files to a similar php script
on the same server via a simple html form (multipart/form-data).

In both cases, the server script immediately gives a short response and
closes connection after the request is received, before processing the
data, so the upload observed by the user is actually just the upload
time (the time it takes for the server to respond is negligible).

Needless to say, both are being tried from the same device through the
same internet connection.

What is being observed is that uploading via the web form from the
browser is a lot faster than uploading with ODK.

Is there conceivable explanation for that, or should I assume that it
is a random coincidence that the connection was slower when using odk?

In both cases it is a multipart/form-data encoding, with the binary data
being encoded base-64, isn't it?
Also, even if the browser was using gzip and odk wasn't (by the way may
this be the case?) it shouldn't make a noticeable difference, since all
the media are already highly compressed and hence high-entropy...

Any ideas?

Thanks
m.

it's possible the browser uses multiple threads to upload.

··· On Wed, Nov 16, 2011 at 13:58, Matteo Sisti Sette wrote: > Hi, > > I've stumbled against something that I can't explain. > > I'm using ODK collect to send data to a custom server script written in php. > My forms include an image, a video file and an audio file (all optional), > and few data, so the total amount of bytes to be sent is basically > determined by the media, the xml data being negligible in comparison. > > Now I've tried (well actually not me personally, but the person I'm working > with) uploading exactly the same files to a similar php script on the same > server via a simple html form (multipart/form-data). > > In both cases, the server script immediately gives a short response and > closes connection after the request is received, before processing the data, > so the upload observed by the user is actually just the upload time (the > time it takes for the server to respond is negligible). > > > Needless to say, both are being tried from the same device through the same > internet connection. > > What is being observed is that uploading via the web form from the browser > is a lot faster than uploading with ODK. > > Is there conceivable explanation for that, or should I assume that it is a > random coincidence that the connection was slower when using odk? > > > In both cases it is a multipart/form-data encoding, with the binary data > being encoded base-64, isn't it? > Also, even if the browser was using gzip and odk wasn't (by the way may this > be the case?) it shouldn't make a noticeable difference, since all the media > are already highly compressed and hence high-entropy... > > > Any ideas? > > Thanks > m. >

Do you mean a single http request can be split into multiple parallel
uploads? How is that possible?
But even so, how can N threads uploading at 1/Nth of the total
bandwitdth be faster than 1 thread uploading at full bandwidth?

··· 2011/11/17 Yaw Anokwa : > it's possible the browser uses multiple threads to upload.