Remy Maucherat wrote:
Jean-Francois Arcand wrote:

Without access log valve, we are 20% faster. With the ByteBuffer one, 13%.


There are 3 access log valves ;) Maybe you should give a chart.

I did formally benchmark

+ FastCommonAccessLogValve
+ ByteBufferAccessLogValve

I didn't bother about AccessLogValve. I did a lot of exploration:

+ use a ByteBuffer, call ByteBuffer.asCharBuffer() and then use CharBuffer.put() (no StringBuffer/ThreadLocal). Works fine except there is some garbage in the log since when a CharBuffer view buffer is used against a ByteBuffer or using ByteBuffer.putChar(char x) will result in '^' (control) characters and null characters to be written to the ByteBuffer. These '^' (control) characters then get written to the access log.
+ StringBuffer without a ThreadLocal.
+ CharBuffer.allocate() with a ByteBuffer.allocateDirect()


I did also try to synchronize the valve invoke method and use the current thread to write the log (instead of using a background thread/writter thread).



I'll do my byte based improvements (to be able to save on char to byte) in your implementation.


The buffer isn't big enough. 16k will hold 500 requests maximum. If you were afraid of doing one I/O operations, it's bad, as you'll end up doing a lot of I/O synchronously. Can we allow the buffers to grow ?

Yes, but growing a direct byte buffer is very bad. I did put 16k as a baseline. Using a 128k will gives better results, but 256k didn't.


At
least they would need to be a lot bigger otherwise (we could "reinvest" the memory saved from not having a background thread :) ).
Another trick if you want to tweak the interval inside the valve, you can use an integer that you increment and do a modulo (i % n). I do that for the manager checks (one check every 6 invocations of backgroundProcess).

Yes, I can explore that. I will re-add the writerThread for now since the current implementation doesn't work since the byteBuffer will never be flushed. This is temporary. Again, consider this valve as exploration.


-- Jeanfrancois



Rémy


--------------------------------------------------------------------- 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]



Reply via email to