The last time we downloaded it (quite a while back), 
Jason used oInStream.readLine(aBuffer, aOffset, aLen);

Where oInStream is a ServletInputStream, 
and aLen = 1024 * 100.
Whith that it is dependen on the implementation of the 
underlying servlet engine.

You can download the lib at
http://www.servlets.com/resources/com.oreilly.servlet/


Especially note the remarks for the update from Oct 29th. 2000:

> This version also adds special buffering to to dramatically
> improve performance on servers that don't do
> their own buffering, including Tomcat 3.2 and earlier

So maybe upgrade to a newer version might improve the situation.

> -----Ursprüngliche Nachricht-----
> Von: Randy Layman [mailto:[EMAIL PROTECTED]]
> Gesendet: Freitag, 5. Januar 2001 14:21
> An: '[EMAIL PROTECTED]'
> Betreff: RE: Slow upload speeds
> 
> 
> 
>       Even though its on the same machine, the data still 
> flows through
> the Operating System and into the TCP/IP stack to pop out the 
> other side on
> the same machine, it just didn't cross any networking wires.  
> That's the
> whole point of localhost/127.0.0.1, simulate traffic from the network
> without using the wires.
> 
>       The problem is still (probably, I haven't seen Jason's code),
> fundamentally the number of underlying system calls.  This 
> would be true if
> you wrote the program in Java or C or Visual Basic or Perl, 
> Unix or NT.  The
> User process has to ask the Operating System for the bytes.  
> If it asks for
> each byte one at a time then it takes a lot more time than if 
> it asked for
> (relatively) big blocks.
> 
>       If you could give me a pointer to the source I could 
> probably find a
> little time today to look over this and see how his code 
> works and if this
> is really the problem.  (Its possible that he knew about this 
> problem and
> accounted for it, but its a very commonly overlooked issue).
> 
>       Randy
> 
> -----Original Message-----
> From: Jose Euclides da Silva Junior - DIGR.O
> [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 05, 2001 9:33 AM
> To: [EMAIL PROTECTED]
> Subject: RES: Slow upload speeds
> 
> 
> 
> *** PGP-Unterzeichnungsstatus: unbekannt
> *** Unterzeichner: Unbekannt, Schlüssel-ID = 0x77054C6D
> *** Unterzeichnet: 05.01.01 18:22:06
> *** Verifiziert: 05.01.01 15:02:25
> *** BEGINN DER MIT PGP VERIFIZIERTEN NACHRICHT ***
> 
> Many people have been talked about bad performance when using Jason
> code.But, you should tell me some information like available 
> memory and
> availabe disk space  When you try to use client and server on the same
> machine and the problem still happens, we are able to say 
> that bottleneck
> isnt the reason of the slow speed.
> Regards,
> 
> José Euclides Júnior
> __________________________________
> E-mail: [EMAIL PROTECTED]
>             [EMAIL PROTECTED] 
>             [EMAIL PROTECTED]
> http://euclides.8m.com
> 
> 
> -----Mensagem original-----
> De:           Randy Layman [SMTP:[EMAIL PROTECTED]]
> Enviada em:           Sexta-feira, 5 de Janeiro de 2001 10:32
> Para:         '[EMAIL PROTECTED]'
> Assunto:              RE: Slow upload speeds
> 
> 
>       I've never dealt with this in Tomcat, but from other 
> network apps:
>       How are you using the ServletInputStream - are you calling int
> read(), which reads the stream a byte at a time, or are you 
> calling int
> read(byte[])?  My experience is that you want to use the 
> second option,
> preferably with the byte[] size equal to 1500 (Reason for 
> 1500 - its the MTU
> (Maximum Transmission Unit) of Ethernet, probably the network 
> the server is
> attached to).
>       Reason this speeds things up:  When calling int read(), 
> to get 1500
> bytes of input, Java has to make 1500 system calls.  If you use int
> read(byte[]) then it can get 1500 bytes in one system call.  
> The reason you
> want this byte[] to be the same length as the MTU - you can 
> read each packet
> as it arrives and be processing it as the next packet finds 
> its way across
> the network instead of waiting on the next one.
> 
>       One caveat: I have not looked at the source code for 
> this class, but
> from the JavaDoc it appears that all the methods we are 
> talking about are
> inherited from InputStream, so these techniques should work.
> 
>       Randy
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 04, 2001 6:13 PM
> To: [EMAIL PROTECTED]
> Subject: Slow upload speeds
> 
> 
> Hi everyone.
> 
> I am using Tomcat-3.2.1 on W2K, Solaris with or without 
> apache. Since I 
> need to provide users with functionality to upload fairly big 
> files (> 10 
> MB), speed is essential.
> 
> My uploader is based on Jason Hunter code. Maximum upload 
> speed I could 
> achieve is between 40 and 60 Kbytes/s (even when client and 
> server are on 
> the same machine). Bottleneck (quiet predictable) seems to be in 
> ServletInputStream misc. "read()" methods. Speed does not seem to be 
> dependant on a platform or web server.
> 
> Anyone was able to achieve better speeds (at least around 100 
> kBytes/s)? 
> Any ideas ?
> 
> Thanks
> 
> Andrus
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> *** ENDE DER MIT PGP VERIFIZIERTEN NACHRICHT ***
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to