So to spell things out, are you saying that:
1. yes, http upload requires a lot of memory and will take up whatever cpu process is available
2. however, as the client and the server will yield to other processes requesting cpu it shouldn't have a seriously negative affect on other accesses to the web site.
?


In other words - while http is far from being the best file transfer method, it will work without greatly hogging the cpu. Obviously, the smaller the files uploaded the better, as these will have the least amount of impact on the server.

Unless someone writes an external module to handle this, it is the only way that I can see to provide technology-challenged people file uploads on the web - so I hope that i have summed things up correctly.

And I assume that there is no advantage in using a specific platform for this task? (apart from the faster the better).

Garth


You should be careful uploading large files through any web application
server, especially when they are client server.  If you look at the route
that the file takes in memory it is copied quite a few times so the larger
the file the more work that needs to be done.  A typical scenario would go
like this.

(This has been generalised)

File submit via form
File read into browsers memory
File sent to web server over network
File read from network buffer and passed to web server memory as postarg
File passed to app server client and wrapped for sending to app server
File sent to app server from client
File unwrapped by app server memory so it can be accessed as @POSTARG
File saved to disk

So as a minimum the file has been shuttled around in memory around 7 times.
Add to this the encoding that may happen if debug/logging is turned on so
that the variable that contains the data is displayed in the debug trace/log
and it may be greater.

Remember that the client runs in the web server's memory space so this can
make the CPU and memory of the web server process appear to race as it is
encapsulating the postarg to be sent to the server..

Now that the client and server are preemtive, they will attempt to take as
much CPU as they have available to them.  Both the client and server should
yield to other processes requesting cpu so the machine should not become
unresponsive.

As a rule of thumb, you should try and get the file to the server using the
shortest path possible and should save it to disk asap.  Using http is not
the most efficient way of doing this.

Phil


On 24/3/03 12:17 PM, "Garth Penglase" <[EMAIL PROTECTED]> wrote:


 It may be a Windows issue not an IIS 5 issue.
 Any thoughts Phil/Sophie?
 Garth

Robert

 I tried this on a XP box with apache. IT has 640 megs of ram and a
 2.0ghz p4 and my cpu usage went up to 100% so its not an issue with IIS.

Mike D

 -----Original Message-----
 From: Robert Garcia [mailto:[EMAIL PROTECTED]
 Sent: Sunday, March 23, 2003 12:29 PM
 To: [EMAIL PROTECTED]
 Subject: Re: Witango-Talk: HTTP Upload

 I haven't done enough testing yet, but I don't think this is a Witango
 issue, but a IIS 5 issue.

 It would really help if someone had a IIS 5 server using http upload
 that can test this, so I dont have to set that up.

Robert.

On Saturday, March 22, 2003, at 11:16 PM, Garth Penglase wrote:

I'd be very interested as to whether this is purely a Windows/Witango

issue or if it relates to OSX and other platforms. I agree that it is

totally unacceptable that there is anything more than a few percentage

cpu usage, and this will significantly affect performance on my
 >>>  servers when I upgrade to Wi5 in the next week or so, as I have a
 >>>  number of apps that will require this service.
 >>>
 >>>  Maybe With has a comment on this one....??
Garth

Thats not the issue. The issue is having a solution for a client that

is not savvy enough to use an ftp client. I already use webdav in
>>>> such a way that they could connect with a webfolder from windows, or

   directly from OS X. But these are people that can only be expected
  to  work with a single interface, and click a few buttons. Using HTTP

   Upload is very simple and suits that. But HTTP Upload has other
  problems, and this CPU Usage issue now knocks it completely off my
  list.

Robert.

On Saturday, March 22, 2003, at 05:10 AM, Michael Dittbrenner wrote:

Robert

Why not just put up a ftp server instead of using http. Ftp protocol

  is
  a lot faster than http for uploading and puts less strain on the
  server.
  Windows 2000 comes with a ftpd built in and if your client doesn't
  have
  a ftp client they can download a trial from like www.globalscape.com

   for
  cuteftp.

Michael Dittbrenner


-----Original Message----- From: Robert Garcia [mailto:[EMAIL PROTECTED] Sent: Saturday, March 22, 2003 6:59 AM To: [EMAIL PROTECTED] Subject: Witango-Talk: HTTP Upload

  I normally don't use http upload for many reasons, but I had to do a
  quick and dirty solution for a client. They must be able to upload
  MP3
  files to our servers. The files range from 10-20 megs. Before I put
  this into production, I wanted to test the load it would put on my
  servers. My app uses witango to accept the file argument, and write

 it
 to a file where I want it. I am running Witango 054 and IIS 5 on
 windows 2000. During the upload, the server pegs 100% CPU usage,
 dllhost.exe and inetinfo.exe being the culprits. Witango only spikes
  when the upload is done to write the file.

  Since I have only used http upload with very small files in the
  past, I
  have never noticed this. This is totally unacceptable. If I upload
  the
  same file to the same IIS Server using IIS WebDav, it doesn't break
a
sweat, 1-2% CPU Usage. I can't recall every testing this with other

  web
  servers, does anyone else have any info with apache or Webstar?

  It looks like I will have to write a custom desktop app for this
  client's admin, which I did not want to do. If anyone knows of any
  IIS
  5 tweaks that may help, I would appreciate it. My systems are
  completely patched once a week.

--

  Robert Garcia
  President - BigHead Technology
  CTO - eventpix.com
  2781 N Carlmont Pl
  Simi Valley, Ca 93065
  ph: 805.522.8577 - cell: 805.501.1390
  [EMAIL PROTECTED] - [EMAIL PROTECTED]
  http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/


_____________________________________________________________________
  __ _
  TO UNSUBSCRIBE: send a plain text/US ASCII email to
  [EMAIL PROTECTED]
                  with unsubscribe witango-talk in the message body



_____________________________________________________________________
  __ _
  TO UNSUBSCRIBE: send a plain text/US ASCII email to
  [EMAIL PROTECTED]
                  with unsubscribe witango-talk in the message body


--


  Robert Garcia
  President - BigHead Technology
  CTO - eventpix.com
  2781 N Carlmont Pl
  Simi Valley, Ca 93065
  ph: 805.522.8577 - cell: 805.501.1390
  [EMAIL PROTECTED] - [EMAIL PROTECTED]
  http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/


______________________________________________________________________
  __
  TO UNSUBSCRIBE: send a plain text/US ASCII email to
  [EMAIL PROTECTED]
                 with unsubscribe witango-talk in the message body


--

_______________________________________________________________________
  _
  TO UNSUBSCRIBE: send a plain text/US ASCII email to
  [EMAIL PROTECTED]
>>> with unsubscribe witango-talk in the message body



--


 Robert Garcia
 President - BigHead Technology
 CTO - eventpix.com
 2781 N Carlmont Pl
 Simi Valley, Ca 93065
 ph: 805.522.8577 - cell: 805.501.1390
 [EMAIL PROTECTED] - [EMAIL PROTECTED]
 http://bighead.net/ - http://eventpix.com/ - http://theradmac.com/

 ________________________________________________________________________
 TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
                 with unsubscribe witango-talk in the message body


________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body


________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body


--
________________________________________________________________________
TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED]
               with unsubscribe witango-talk in the message body

Reply via email to