Cry for help - make this faster

casper_the_ghost · September 27, 2006, 5:56am

yes, it will require deep ruby and ‘c’ knowledge

http://codeforpeople.com/lib/ruby/acgi/acgi-0.1.0/README

and, obviously

i think it’s a potentially powerful idea. if you know how to make it
faster,
please do so and send in a patch. at this point only a factor of 2x is
need
to close the gap on fastcgi. at this point the emphasis is on making it
as
fast as possible. scalibility and portability might come next.

good luck.

-a

casper_the_ghost · September 27, 2006, 3:40pm

Ara.T.Howard wrote:

faster,
please do so and send in a patch. at this point only a factor of 2x is
need
to close the gap on fastcgi. at this point the emphasis is on making it as
fast as possible. scalibility and portability might come next.

good luck.

-a

That looks way cool. I heartily support it. I have some C IPC
experience, but not in windows.

casper_the_ghost · September 27, 2006, 4:03pm

Ara.T.Howard wrote:

faster,
please do so and send in a patch. at this point only a factor of 2x is
need
to close the gap on fastcgi. at this point the emphasis is on making it as
fast as possible. scalibility and portability might come next.

good luck.

-a

this is a great thing - could it make it into ruby 2 std lib ( or did
i get something wrong) ?

casper_the_ghost · September 27, 2006, 4:27pm

On Wed, 27 Sep 2006, Hans F. wrote:

i think it’s a potentially powerful idea. if you know how to make it
but not in windows.
have a whack at it! i played with threaded versions, non-threaded
versions, versions using mmap, versions using named pipes, versions
using
shared memory (sysv ipc), etc. none were significantly fast than the
simple
version. also, i was trying to make a *nix impl which at least stood a
chance
of being ported to windows - thus the use of named pipes.

at the moment it’s just a toy, but it could become something.

regards.

-a

casper_the_ghost · September 28, 2006, 5:36am

Ara.T.Howard wrote:

faster,
please do so and send in a patch. at this point only a factor of 2x is
need
to close the gap on fastcgi. at this point the emphasis is on making it as
fast as possible. scalibility and portability might come next.

good luck.

-a
Hmmm … by portability do you mean “runs on other than Linux?”

What sort of performance testing framework are you using?

casper_the_ghost · September 27, 2006, 4:31pm

On Wed, 27 Sep 2006, Jonas H. wrote:

i think it’s a potentially powerful idea. if you know how to make it
something wrong) ?
i suppose that’s an idea - but at this point it’s far from ready for
prime
time.

cheers.

-a

casper_the_ghost · September 28, 2006, 6:20am

On Thu, 28 Sep 2006, M. Edward (Ed) Borasky wrote:

i think it’s a potentially powerful idea. if you know how to make it
faster,
please do so and send in a patch. at this point only a factor of 2x is
need
to close the gap on fastcgi. at this point the emphasis is on making it as
fast as possible. scalibility and portability might come next.

good luck.

-a

Hmmm … by portability do you mean “runs on other than Linux?”

i’m afraid so - sigh…

on a side note, i hear 2.6.17 will auto-tune the tcp-ip stack, that
ought to
make for a fast web app server…

What sort of performance testing framework are you using?

just ab

this is still in the proof of concept phase for sure.

cheers.

-a

casper_the_ghost · September 28, 2006, 6:41am

[email protected] wrote:

http://codeforpeople.com/lib/ruby/acgi/

-a

Hmmm … by portability do you mean “runs on other than Linux?”

i’m afraid so - sigh…

on a side note, i hear 2.6.17 will auto-tune the tcp-ip stack, that
ought to
make for a fast web app server…

I was thinking Tux, actually.

What sort of performance testing framework are you using?

just ab

There are quite a few out there.