RE: File writing performance
The main problem with performance comes from your source code. You are
reading 1 byte at a time then writing 1 byte at a time. Use a buffered
input stream, and also use a buffered output stream. Then read and
write a good number of bytes. Maybe use a static section so you can
change the number of bytes for the buffers with a properties file.
Wade
-Original Message-
From: Carlos Pereira [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 3:10 PM
To: Tomcat Users List
Subject: File writing performance
I want to make a servlet which catches all accesses to *.swf files (with
a mapping) and only retrieves them if the permissions for the user allow
it. That can be done simply with:
// check user permissions and redirect to error page if needed // else:
response.setContentType("application/x-shockwave-flash");
DataInputStream dis = new DataInputStream(
getServletContext().getResourceAsStream(filename)
);
OutputStream out = response.getOutputStream();
int b = -1;
while((b = dis.read()) != -1) {
out.write(b);
}
out.close();
My question: is this approach more expensive than simply retrieving the
file? If so, is it significative?
Best regards,
Carlos Pereira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: File writing performance
I would guess that it's quite unperfomant the way you do it.
You should at leat read and write bigger chunks (1K to 8k
are common values.
There is another problem: Are you shure that flash is using
a simple download and won't use things from http 1.1 like
byte range requests (and won't do it in the next version).
To implement this, you would have to implement much more code.
(Have a look at the source of the DefaultServlet)
Or force the server to use HTTP 1.0)
> -Original Message-
> From: Carlos Pereira [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 21, 2003 9:10 PM
> To: Tomcat Users List
> Subject: File writing performance
>
> response.setContentType("application/x-shockwave-flash");
> DataInputStream dis = new DataInputStream(
> getServletContext().getResourceAsStream(filename)
> );
> OutputStream out = response.getOutputStream();
> int b = -1;
> while((b = dis.read()) != -1) {
> out.write(b);
> }
> out.close();
>
>
> My question: is this approach more expensive than simply
> retrieving the file? If so, is it significative?
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: File writing performance
> > I would guess that it's quite unperfomant the way you do it. > > You should at leat read and write bigger chunks (1K to 8k > are common values. Really efficient values are FS blocksize (linux defaults to 4096b). No? François. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: File writing performance
> The main problem with performance comes from your source code. You are > reading 1 byte at a time then writing 1 byte at a time. Use a buffered > input stream, and also use a buffered output stream (Wade Chandler) > Really efficient values are FS blocksize (linux defaults to 4096b). (Francois JEANMOUGIN) > (Have a look at the source of the DefaultServlet) (Ralph Einfeldt) Ok, I'll use a 4096b long buffer. The code i posted was just a test; it worked, now i'll go for performance tuning. My doubt was if it would be slower that the processing that the default servlet does. After watching it's source i guess it will even be quicker, because it doesn't need so many tests. > There is another problem: Are you shure that flash is using > a simple download and won't use things from http 1.1 like > byte range requests (and won't do it in the next version). (Ralph Einfeldt) I don't understand what you are talking about. SWF files work just like java applets; they are downloaded, the flash player is started and runs the SWF file (much like the java plugin). I really don't know anything about byte range requests. According to this behaviour, do you think there might be any problem? I've searched the SWF file format specification, macromedia's developer center and Flash's help files. They don't have any reference to that either. I tried an example and it worked fine, with no problems at all. But, i want to make sure i don't need to worry about this... Best regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: File writing performance
I don't know how it is with SWF files. But other technologies like PDF work with byte range requests to start the display of the first page before the full dokument is there. These feature is nothing you will find in the fileformat. (At least not in PDF) This is just a way to get the file with the given format from the server to the client. My remark was just a warning, that something like that can happen. > -Original Message- > From: Carlos Pereira [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 22, 2003 3:54 PM > To: Tomcat Users List > Subject: RE: File writing performance > > > I don't understand what you are talking about. SWF files > work just like java applets; they are downloaded, the flash > player is started and runs the SWF file (much like the java > plugin). I really don't know anything about byte range > requests. According to this behaviour, do you think there > might be any problem? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: File writing performance
> I don't know how it is with SWF files. But other technologies like > PDF work with byte range requests to start the display of the > first page before the full dokument is there. (Ralph Einfeldt) Oops! Flash does show frames as they come in, before the whole swf file is downloaded... > My remark was just a warning, that something like that can > happen. (Ralph Einfeldt) Yes, and i don't know anything about that, so i must be careful. What is the consequence, if flash uses byte range requests and i simply write the file to the output stream? Best regards, Carlos Pereira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
