Very Computer

APACHE: FILE UPLOAD SLOWER THAN DOWNLOAD about 3,5 times on a fast
connection

The Download of a file from apache web server (1.3.17) is abotut 3,5
times faster than
the uploading  on a fast connection.
I work in the following environment:
 .LAN 10 mbit/S
 .Operating System: Solaris 2.7
 .Clients (using Explorer/Netscape) on the same LAN

I've the same behaviour on two computers having the same operative
system (solaris) and different HW.
The uploading has been performed with different and simple CGI written
in perl and c language:
  while( <input from apache>)
  {
    WRITE  
  }
The CGI isn't the problem because during the upload the total CGI
execution time is very little against the time spent by
apache serve:
if the download time is  '100' then apache call the CGI when the 95% of
the time has been spent
(perhaps it call CGI after receving all the uploaded file).

I've got the same result: download (about  90% of bandwidth) much faster
than upload
(transfer of file from client to web server).
I'm sure there no Firewall problems.

I tried to speed up the uploading changing some configuration parameters
in the source apache files
(socket buffer size,.... ecc..) but uploading time hasn't been improved.

Can someone help me?

No need to shout.

Your disks are probably the bottle neck.  Have you tested that writing a
file to your disks and reading a file from your disks take the same
amount of time?  I'd bet that writing will take you longer.  What is
your disk setup like?

--
-adam                 | "Be liberal in what you accept, and
Systems Administrator |  conservative in what you send"
Indiana University    |      -Jon Postel
Bloomington, Indiana  |

Is it possible that it might be the connection if the server is run out of a
resident.  Many
ISP's are fast downstream, but sending stuff upstream is quite a bit slower
especially
on a cable system.

Scott

Quote:> APACHE: FILE UPLOAD SLOWER THAN DOWNLOAD about 3,5 times on a fast
> connection

Let me guess: the download benefited from a cached version?

--
Nick Kew

Government[n]: an institution designed to take a bad situation,
and escalate it into a major disaster.

Well, in this case the original poster said the clients were on the same
10Mb LAN.  Otherwise, yes, there could be all kinds of issues like the
provider's pipe size and, caching proxy servers, etc.

--
-adam                 | "Be liberal in what you accept, and
Systems Administrator |  conservative in what you send"
Indiana University    |      -Jon Postel
Bloomington, Indiana  |

The upload can benefit from a cached version too, if you use
mod_resonate.  What mod_resonate does is plant a delithium inverse
phasing device on the client browser that scans for ion fluxes in the
time space continuum.  The browser is then able to transmit data to the
server by piggybacking it to reverse time signatures, thus before the
file is uploaded it is already there since we have taken advantage of the
key feature of mod_resonate which is to exploit security holes in the
time infrastructure
by scanning for anomolies in ion particle dispersion fields. You must
make sure that
the modulation is correctly tuned becuase if you don't go back far enough
then while
the file is uploading a minute ago and is not finished, it might start
uploading again in real time and  if 2 identical packets(one piggybacked
to a reverse time signature and one in normal time) should get within
close proximity of each other a matter/antimatter explosion might occur,
or even worse a "doorway" might open up between the matter/antimatter
world allowing your evil doppleganger to come through to this world and
perhaps run "rm -r *" on your OS.

I know, I should get off these newsgroups and do some productive work
before the morning is over, lol.

Scott

url, PLEASE!!!

All kidding aside, you asked for help with a problem that is
at best vaguely described and leaves ample room for possible causes
that have nothing to do with apache's performance.  (For example, the browser
must construct the multipart data (unique delimiters?) from scratch-
try seeing how long it takes before any POST data and emerges from a
HTTP/1.1 compliant browser while trying to upload two 100M files from
one form.)

Without specifics that others can reproduce, it is almost impossible
to guess at the true cause of your observations.

--
Joe Schaefer                 "I hate a country witout a derrick."
                                               --Mark Twain

Quote:> APACHE: FILE UPLOAD SLOWER THAN DOWNLOAD about 3,5 times on a fast
> connection

You're talking about uploading via a form? It's a much less efficient
encoding; downloads are binary and thus faster.

miguel

Are form-based uploads base64-encoded? If so, then you have a 33%
overhead right there...

--
"Think of it this way: threads are like salt, not like pasta. You like
salt, I like salt, we all like salt. But we eat more pasta."
 -- Larry McVoy

Is the upload script authenticated?  If so there may be a 100%
overhead because Apache (at least as of 1.3.14) doesn't send the 401
until the whole request has been recieved.  IMNSHO this is a bug - I
don't know if it has been fixed yet.

--
     \\   ( )
  .  _\\__[oo

 .  l___\\
  # ll  l\\
 ###LL  LL\\