Re: gzip-encoding in TC 4.1.x/5.x
One of the problems is that the compressed streams from the JDK are not recyclable, cause a lot of possibly synced method calls, and so on. Plus, it's kinda ugly to fit the OS and IS models into the Coyote HTTP/1.1 filter model. Does anyone know about compression code which would use byte arrays on input/output ? I could try to make something like this, just tell me what you need. I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder). Couldn't the compression goes in filter, like Amy does sometimes ago ? You can use it there if you want. However, transfer encoding is a protocol feature. So it seems logical to handle this at the protocol layer (for example, chunked is a transfer encoding, and also hanlded at the protocol handler level). Plus you get a nice server wide configuration on the native webserver, rather than individual settings depending on where the resource is served from. It just seems much cleaner. I agree I don't quite see the Apache - Tomcat link being bandwidth constrained except in very specific situations. In loopback, it uses special optimized processing, and if there are separate boxes for Apache and Tomcat, then they should IMO use a dedicated network link. Dedicated link, you know what it means say the average IT manager : DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION = $/EUR++ If ever you came back to Lyon, I'll make you meet one of my IT manager ;-) I don't see what you can do to improve Amy's filter performance, as it has to: - be thread safe - use inefficient methods from the servlet API (which create garbage, etc) What could we do so ? - Create a GZIP implementation using byte array - Use it in HTTP 1.1 stack - Use it in JK2 As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Did this ZLIB Java implementation could be what you're looking Remy ? http://www.jcraft.com/jzlib/index.html -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: One of the problems is that the compressed streams from the JDK are not recyclable, cause a lot of possibly synced method calls, and so on. Plus, it's kinda ugly to fit the OS and IS models into the Coyote HTTP/1.1 filter model. Does anyone know about compression code which would use byte arrays on input/output ? I could try to make something like this, just tell me what you need. I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder). Couldn't the compression goes in filter, like Amy does sometimes ago ? You can use it there if you want. However, transfer encoding is a protocol feature. So it seems logical to handle this at the protocol layer (for example, chunked is a transfer encoding, and also hanlded at the protocol handler level). Plus you get a nice server wide configuration on the native webserver, rather than individual settings depending on where the resource is served from. It just seems much cleaner. I agree I don't quite see the Apache - Tomcat link being bandwidth constrained except in very specific situations. In loopback, it uses special optimized processing, and if there are separate boxes for Apache and Tomcat, then they should IMO use a dedicated network link. Dedicated link, you know what it means say the average IT manager : DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION = $/EUR++ If ever you came back to Lyon, I'll make you meet one of my IT manager ;-) He's dumb ;-) Look, you're putting together a cluster. Nothing good will come out of saving $50. Also, if you have only one Tomcat srever, you could use a crossover cable. I don't see what you can do to improve Amy's filter performance, as it has to: - be thread safe - use inefficient methods from the servlet API (which create garbage, etc) What could we do so ? - Create a GZIP implementation using byte array - Use it in HTTP 1.1 stack - Use it in JK2 As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces. Well, the idea is to be efficient, so: - Have a ByteChunk compress(ByteChunk) method (assuming that giving it an empty chunk means it's the end of the input stream) - Have a recycle method - No object allocation (and esp buffers), except on init - No need to worry about thread safety, so no syncs But it's ok, we can have the first version use the JDK code. Did this ZLIB Java implementation could be what you're looking Remy ? http://www.jcraft.com/jzlib/index.html Not really, it doesn't seem recyclable. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Dedicated link, you know what it means say the average IT manager : DECICATED LINK = A NEW SWITCH + NEW CABLES + NEW SUPERVISION = $/EUR++ If ever you came back to Lyon, I'll make you meet one of my IT manager ;-) He's dumb ;-) Look, you're putting together a cluster. Nothing good will come out of saving $50. Also, if you have only one Tomcat srever, you could use a crossover cable. On production site, a 100 Mb switch + cabling and monitoring cost much more than 50 EUR :) As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces. Well, the idea is to be efficient, so: - Have a ByteChunk compress(ByteChunk) method (assuming that giving it an empty chunk means it's the end of the input stream) Ok, but the compress method will create the returned ByteChunk and you may want instead : int compress(ByteChunk src, ByteChunk dst) Which will make the caller task to create src/dst ByteChunk. - Have a recycle method With compress(src, dst), caller make the recycling. - No object allocation (and esp buffers), except on init Each using instance will create it's own dst chunk. - No need to worry about thread safety, so no syncs Caller decide what to pass. But it's ok, we can have the first version use the JDK code. I'll see how we could make use ByteChunk with JDK code for now. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces. Well, the idea is to be efficient, so: - Have a ByteChunk compress(ByteChunk) method (assuming that giving it an empty chunk means it's the end of the input stream) Ok, but the compress method will create the returned ByteChunk and you may want instead : int compress(ByteChunk src, ByteChunk dst) Which will make the caller task to create src/dst ByteChunk. Actually, they are both equivalent. I'll see how we could make use ByteChunk with JDK code for now. I've already started experimenting. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Actually, they are both equivalent. I'll see how we could make use ByteChunk with JDK code for now. I've already started experimenting. Thanks to send me a note when code will be available. I'll could add some code to mimic mod_deflate ie : - compress only certain type of mimes (ie only text/html) - desactivate it for some browsers -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: Actually, they are both equivalent. I'll see how we could make use ByteChunk with JDK code for now. I've already started experimenting. Thanks to send me a note when code will be available. I'll could add some code to mimic mod_deflate ie : - compress only certain type of mimes (ie only text/html) - desactivate it for some browsers I think I said a few mistakes in the previous emails. To summarize: - transfer-encoding allows a protocol level compression; that's what I was planning to add to Coyote (see general transfer encoding, section 4.5) - content-encoding does the same, but is considered application layer (see entity header fields, section 7.1) (I'm quite sure I knew that really well a few months ago, but forgot about the subtle difference, since actually, both do the exact same thing to the entity body) The problem is that, although clients support content-encoding, they don't care about transfer-encoding. So actually, to be really clean, you would need two places with compression code: - in Coyote HTTP/1.1, to handle transfer-encoding - in the adapter (or somewhere similar) to handle content-encoding Of course, since the two do the same, I don't see any reason to be overly fancy, and I'll add the compression code (well, the first draft) in Coyote HTTP/1.1 for now, as the filtering model makes the implementation somewhat cleaner. As a side note, it would be good if the Servlet specification marked the headers from section 4.5 as use at your own risk headers (and esp trailer, transfer-encoding, connection). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: I spent some times playing with http compression, using Apache 2.0 mod_deflate together with mod_jk, and it works great (at least with jk 1.2.2). I wonder now if someone, may be Remy, has plan to add it in Catalina 1.x/2.x (or Coyote) to make it available for both HTTP 1.1 and JK2 ? I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime. For JK 2, I think it's fair to say that you should rely on the native webserver capabilities (that's the whole point, I think). Great that you added the support (I thought it had been there from the start, actually). Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Remy Maucherat wrote: Henri Gomez wrote: I spent some times playing with http compression, using Apache 2.0 mod_deflate together with mod_jk, and it works great (at least with jk 1.2.2). I wonder now if someone, may be Remy, has plan to add it in Catalina 1.x/2.x (or Coyote) to make it available for both HTTP 1.1 and JK2 ? I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime. GZIPOutputstream is quit fast today. For JK 2, I think it's fair to say that you should rely on the native webserver capabilities (that's the whole point, I think). Great that you added the support (I thought it had been there from the start, actually). Hum, the idea to put compression on the Java side (HTTP 1.1/JK2) is to reduce the response time and network bandwidth when webserver and tomcat are linked TCP/IP (ie ajp13 + network). I make some bench on large output streams and even if mod_deflate help by sending to browser smaller responses, it still has to handle the big response caming from tomcat. That's why it could be a real gain to have gzip compression also on the tomcat side, I think you'll see real gain with recent browser as soon as response is more than 10k. I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. There is some things to care off, ie activation of compression on certains mimes contents (ie: text/html, text/plain) and when size is greater than xxx bytes. If someone has ideas and may be a skeleton for coyote, I may help him on this area. Regards -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
For JK 2, I think it's fair to say that you should rely on the native webserver capabilities (that's the whole point, I think). Great that you added the support (I thought it had been there from the start, actually). I didn't added support really, just corrected the way we set the content-type in Apache 2.0 using the correct API ;) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: Remy Maucherat wrote: Henri Gomez wrote: I spent some times playing with http compression, using Apache 2.0 mod_deflate together with mod_jk, and it works great (at least with jk 1.2.2). I wonder now if someone, may be Remy, has plan to add it in Catalina 1.x/2.x (or Coyote) to make it available for both HTTP 1.1 and JK2 ? I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime. GZIPOutputstream is quit fast today. I think I'll disagree whenever I'll try it. Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle methods so that no object even gets allocated. For JK 2, I think it's fair to say that you should rely on the native webserver capabilities (that's the whole point, I think). Great that you added the support (I thought it had been there from the start, actually). Hum, the idea to put compression on the Java side (HTTP 1.1/JK2) is to reduce the response time and network bandwidth when webserver and tomcat are linked TCP/IP (ie ajp13 + network). I make some bench on large output streams and even if mod_deflate help by sending to browser smaller responses, it still has to handle the big response caming from tomcat. That's why it could be a real gain to have gzip compression also on the tomcat side, I think you'll see real gain with recent browser as soon as response is more than 10k. I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder). The compression code should go in a filter for HTTP/1.1. For the native webserver connector, like JK2, I insist that this is to be done in the native code. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime. GZIPOutputstream is quit fast today. I think I'll disagree whenever I'll try it. C'est le jeu ;) Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle methods so that no object even gets allocated. Right, but I'm currently playing with stuff which read/write large files, and reading/writing with GZIPstream make the program 4* faster ! I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder). Couldn't the compression goes in filter, like Amy does sometimes ago ? The compression code should go in a filter for HTTP/1.1. For the native webserver connector, like JK2, I insist that this is to be done in the native code. Just take an example : If a servlet has to respond a 100K content, and you're using webserver+jk via net/ajp13, tomcat will send 100K by the network which will be compressed 'à la volée' by mod_deflate. You've got a 100K network use (tc-webserver) + about 30k network use (webserver-browser). If you've got the compression done in java side, you'll have only 30+30 network use and you know that bandwidth today is more important for IT and ADMINs that CPU/RAM. May be a solution could be to bench and optimize the Amy works on gzip compression filter ? Of course compression may also be present in browser-server, ie while uploading large file. When you're using tomcat/jk in SOAP situation, having gzip activated make operation appears really quickers since the volume of datas in both side could be important. Just my 0.01 EUR. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: gzip-encoding in TC 4.1.x/5.x
Henri Gomez wrote: I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime. GZIPOutputstream is quit fast today. I think I'll disagree whenever I'll try it. C'est le jeu ;) Ideally, I'd like a ByteChunk compress(ByteChunk) with nice recycle methods so that no object even gets allocated. Right, but I'm currently playing with stuff which read/write large files, and reading/writing with GZIPstream make the program 4* faster ! One of the problems is that the compressed streams from the JDK are not recyclable, cause a lot of possibly synced method calls, and so on. Plus, it's kinda ugly to fit the OS and IS models into the Coyote HTTP/1.1 filter model. Does anyone know about compression code which would use byte arrays on input/output ? I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers. You can't do it, unless the code is in the adapter, and that's bad design (it's a protocol feature, so it should be in the protocol hanlder). Couldn't the compression goes in filter, like Amy does sometimes ago ? You can use it there if you want. However, transfer encoding is a protocol feature. So it seems logical to handle this at the protocol layer (for example, chunked is a transfer encoding, and also hanlded at the protocol handler level). Plus you get a nice server wide configuration on the native webserver, rather than individual settings depending on where the resource is served from. It just seems much cleaner. I don't quite see the Apache - Tomcat link being bandwidth constrained except in very specific situations. In loopback, it uses special optimized processing, and if there are separate boxes for Apache and Tomcat, then they should IMO use a dedicated network link. I don't see what you can do to improve Amy's filter performance, as it has to: - be thread safe - use inefficient methods from the servlet API (which create garbage, etc) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
