> Yeah I guess the best thing'd be to fix IO#write in the core, instead
> of a hack to work around it :) I have no idea what #write does but
> it appears that it is suboptimal, at least for this one distro on
> this one machine.
I do not think so, IO#write writes "exactly" n bytes even if the
op
Wayne Seguin wrote:
> Using write_nonblock is an absolutely great suggestion; the only real
> issue with write_nonblock is that it doesn't work in all environments.
> While Ruby is supposed to fall back on blocking IO when async is
> unavailable in the underlying system the reality is sketchy at be
Roger,
Using write_nonblock is an absolutely great suggestion; the only real
issue with write_nonblock is that it doesn't work in all environments.
While Ruby is supposed to fall back on blocking IO when async is
unavailable in the underlying system the reality is sketchy at best.
Through
>>out.write("hello!\n"*10_000)
>
> AFAIK that's not the fastest of operations.
String creation itself turns out to not take too long:
>> Benchmark.measure { "hello!\n"*10_000}
=> #
So it's not a huge bottleneck. Replacing it with a static string yields
approx. the same results, which I
On 30 Aug 2008, at 21:57, Roger Pack wrote:
As a note--using the mongrel example from
http://mongrel.rubyforge.org/web/mongrel/files/README.html and Mongrel
1.1.5
It yielded (for me) ~800 req/s [running ab -n 1000 -c 1
http://localhost:3000/test]
and if I changed
out.write("hello!\n")
