On Mon, Jun 04, 2007 at 01:04:13PM +0300, Aycan iRiCAN wrote:
Hi,
First I want to thank you for your great effort. I tried to stress the current iolib. Attached is a simple HTTP reply generator. I used sbcl 1.0.5 VM on a 32 bit AMD desktop machine. I used siege with lot's of concurrent connections. Here is the first inspection:
I've attached your code which I modified a bit in order to be able to debug it more easily
I got 1490 transactions per second. The performance is great (I got around 500 trans/sec with a threaded version) but when I repeat the test, SBCL crashes silently and eats all my cpu. I don't get any errors or some output.
it crashes here too with the latest SBCL, with a memory-fault-error(most of the time, I also got various types of heap corruption) - I had to run SBCL directly from the terminal because indeed Slime seems not to be able to cope with a memory fault in the REPL thread. On my computer SBCL crashed directly if I run the test for just 7 seconds I've also tried CMUCL which is a bit sturdier(but essentially it crashes too), while CLISP had no problems(although it is slower that SBCL or CMUCL):
hechee@blackhole iolib $ siege -b -c10 -t400S http://localhost:8001/ ** siege 2.65 ** Preparing 10 concurrent users for battle. The server is now under siege... Lifting the server siege... done. Transactions: 216139 hits Availability: 100.00 % Elapsed time: 400.81 secs Data transferred: 30.30 MB Response time: 0.02 secs Transaction rate: 539.26 trans/sec Throughput: 0.08 MB/sec Concurrency: 9.95 Successful transactions: 216139 Failed transactions: 0 Longest transaction: 9.06 Shortest transaction: 0.00
Also the :timeout parameter to add-fd should not be nil by default, if so I got type errors with lengthy content sizes.
I believe that it's better if the users of the library specify themselves the timeout both for the simplicity of the library code and for the fact that it's difficult to select a default timeout that is ok for everyone
Is it possible to outperform java io performance?
once the features will all be implemented and we get to optimize the code, I think it can certainly be done