# WEBrick and mod\_ruby performance

**URL:** <https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826>\
**Category:** ruby-talk\
**Created:** [3 September 2003 22:43 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826 "2003-09-03T22:43:59Z")\
**Posts on this page:** 16\
**Page:** 1

<div class="post-metadata">

**Author:** ![Jeff\_Mitchell](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@Jeff\_Mitchell](https://rubytalk.org/u/Jeff_Mitchell)\
**Post date:** [3 September 2003 22:43 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/1 "2003-09-03T22:43:59Z")

</div>

I’ve been scoping out ruby for an upcoming server project.

For my purpose, performance will be a factor because the server will  
be slending data in real-time much like a multipayer game server such  
as Quake (as opposed to waiting for user input). Quake is an extreme  
example, though – it wouldn’t be nearly that demanding.

I am very impressed with WEBrick, and this would be my primary choice  
were it not for performance concerns.

How does WEBrick scale? Looking through the code, it appears that new  
requests are handled by a ruby Thread – as opposed to a native thread  
or a fork. What happens with 40 threads, all transferring data and  
doing stuff, all being handled by a single ruby process setjmp-ing and  
longjmp-ing around? I’m guessing performance would be poor.

Next option is mod\_ruby. Now I don’t even understand how mod\_ruby  
works with Apache 2.0 since the ruby interpreter isn’t thread-safe.  
So that’s all a mystery to me. Apache 1.3 + mod\_perl is probably  
well-tested and perhaps the most appropriate choice.

Are the above assumptions correct, and are there other options? One  
more option which comes to mind is to simply write a forking ruby  
server from scratch. This would mean more development time, but how  
much more I’m not sure.

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard1](https://avatars.discourse-cdn.com/v4/letter/a/f19dbf/32.png) [@Ara.T.Howard1](https://rubytalk.org/u/Ara.T.Howard1)\
**Post date:** [4 September 2003 00:24 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/2 "2003-09-04T00:24:07Z")

</div>

you should definitely check out fastcgi and the ruby fastcgi binding. it’s  
AWESOMELY fast:

~ \> ab [http://eli/env.cgi](http://eli/env.cgi) | grep ‘per second’  
Requests per second: 4.04 [#/sec] (mean)

~ \> ab [http://eli/env.fcgi](http://eli/env.fcgi) | grep ‘per second’  
Requests per second: 557.10 [#/sec] (mean)

(that’s two orders of MAGNITUDE!)

~ \> cat env.fcgi  
#!/usr/local/bin/ruby  
require ‘cgi’  
require ‘fcgi’

FCGI.each\_cgi do |cgi|  
content = ‘’  
env =   
cgi.env\_table.each do |k,v|  
env \<\< [k,v]  
end  
env.sort!  
env.each do |k,v|  
content \<\< %Q(#{k} =\> #{v}  
\n)  
end  
cgi.out{content}  
end

env.cgi is the exact same program - it runs either way: as a cgi or fcgi based  
on extension. it’s a terrible cgi i realize - but it demonstrates the speed  
difference which can only get better, not worse:

here is a slightly more realistic benchmark and examples:

NORMAL CGI PROGRAM:

/usr/local/httpd/htdocs \> ab [http://127.0.0.1/a.cgi](http://127.0.0.1/a.cgi) | grep ‘Requests’  
Requests per second: 10.83 [#/sec] (mean)

/usr/local/httpd/htdocs \> cat a.cgi  
#!/usr/bin/env ruby  
require ‘cgi’  
require ‘postgres’  
require ‘amrita/template’

# our template

html = \<\<-html

- 

  
  
  
html  
template = Amrita::TemplateText.new html

# this connection is made EVERY time!

pgconn = PGconn.new  
tuples = pgconn.query “select \* from foo”

# generate content from database

template.expand((content = ‘’), :tuples =\> tuples)

# blast out

cgi = CGI.new  
cgi.out{ content }

FAST CGI PROGRAM (SAME PROGRAM PORTED TO FCGI):

/usr/local/httpd/htdocs \> ab [http://127.0.0.1/a.fcgi](http://127.0.0.1/a.fcgi) | grep ‘Requests’  
Requests per second: 245.58 [#/sec] (mean)

/usr/local/httpd/htdocs \> cat a.fcgi  
#!/usr/bin/env ruby  
require ‘cgi’  
require ‘fcgi’  
require ‘postgres’  
require ‘amrita/template’

# our template

html = \<\<-html

- 

  
  
  
html  
template = Amrita::TemplateText.new html

# this connection is made ONE time!

pgconn = PGconn.new

FCGI.each\_cgi do |cgi|  
tuples = pgconn.query “select \* from foo”

```
# generate content from database
template.expand((content = ''), :tuples => tuples)

# blast out
cgi.out{ content }

```

end

still MUCH faster. some of the other advantages include being able to monitor  
your web processes in top and NOT being able to affect the apache process.

as to your webrick questions i cannot say - but it does look _very_ cool.

-a

> **···**
>
> On Wed, 3 Sep 2003, Jeff Mitchell wrote:
> 
> > I’ve been scoping out ruby for an upcoming server project.
> > 
> > For my purpose, performance will be a factor because the server will  
> > be slending data in real-time much like a multipayer game server such  
> > as Quake (as opposed to waiting for user input). Quake is an extreme  
> > example, though – it wouldn’t be nearly that demanding.
> > 
> > I am very impressed with WEBrick, and this would be my primary choice  
> > were it not for performance concerns.
> > 
> > How does WEBrick scale? Looking through the code, it appears that new  
> > requests are handled by a ruby Thread – as opposed to a native thread  
> > or a fork. What happens with 40 threads, all transferring data and  
> > doing stuff, all being handled by a single ruby process setjmp-ing and  
> > longjmp-ing around? I’m guessing performance would be poor.
> > 
> > Next option is mod\_ruby. Now I don’t even understand how mod\_ruby  
> > works with Apache 2.0 since the ruby interpreter isn’t thread-safe.  
> > So that’s all a mystery to me. Apache 1.3 + mod\_perl is probably  
> > well-tested and perhaps the most appropriate choice.
> > 
> > Are the above assumptions correct, and are there other options? One  
> > more option which comes to mind is to simply write a forking ruby  
> > server from scratch. This would mean more development time, but how  
> > much more I’m not sure.
> 
> ====================================
> 
> > Ara Howard  
> > NOAA Forecast Systems Laboratory  
> > Information and Technology Services  
> > Data Systems Group  
> > R/FST 325 Broadway  
> > Boulder, CO 80305-3328  
> > Email: [ara.t.howard@noaa.gov](mailto:ara.t.howard@noaa.gov)  
> > Phone: 303-497-7238  
> > Fax: 303-497-7259  
> > ~ \> ruby -e ‘p(%.\x2d\x29..intern)’  
> > ====================================

---

<div class="post-metadata">

**Author:** ![Kwatch](https://avatars.discourse-cdn.com/v4/letter/k/76d3ee/32.png) [@Kwatch](https://rubytalk.org/u/Kwatch)\
**Post date:** [10 September 2003 13:48 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/3 "2003-09-10T13:48:35Z")

</div>

You can try ‘esehttpd’  
[http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html](http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html)

It is very fast as HTTP server and CGI engine,  
twice (or more) as fast as Apache + mod\_ruby.

> **···**
>
> –  
> regards  
> kwatch
> 
> [quixoticsycophant@yahoo.com](mailto:quixoticsycophant@yahoo.com) (Jeff Mitchell) wrote in message news:[a45fa95e.0309031429.549b72a3@posting.google.com](mailto:a45fa95e.0309031429.549b72a3@posting.google.com)…
> 
> > I’ve been scoping out ruby for an upcoming server project.
> > 
> > For my purpose, performance will be a factor because the server will  
> > be slending data in real-time much like a multipayer game server such  
> > as Quake (as opposed to waiting for user input). Quake is an extreme  
> > example, though – it wouldn’t be nearly that demanding.
> > 
> > I am very impressed with WEBrick, and this would be my primary choice  
> > were it not for performance concerns.
> > 
> > How does WEBrick scale? Looking through the code, it appears that new  
> > requests are handled by a ruby Thread – as opposed to a native thread  
> > or a fork. What happens with 40 threads, all transferring data and  
> > doing stuff, all being handled by a single ruby process setjmp-ing and  
> > longjmp-ing around? I’m guessing performance would be poor.
> > 
> > Next option is mod\_ruby. Now I don’t even understand how mod\_ruby  
> > works with Apache 2.0 since the ruby interpreter isn’t thread-safe.  
> > So that’s all a mystery to me. Apache 1.3 + mod\_perl is probably  
> > well-tested and perhaps the most appropriate choice.
> > 
> > Are the above assumptions correct, and are there other options? One  
> > more option which comes to mind is to simply write a forking ruby  
> > server from scratch. This would mean more development time, but how  
> > much more I’m not sure.

---

<div class="post-metadata">

**Author:** ![Dmitry\_Borodaenko](https://avatars.discourse-cdn.com/v4/letter/d/dc4da7/32.png) [@Dmitry\_Borodaenko](https://rubytalk.org/u/Dmitry_Borodaenko)\
**Post date:** [4 September 2003 14:47 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/4 "2003-09-04T14:47:49Z")

</div>

> you should definitely check out fastcgi and the ruby fastcgi binding. it’s  
> AWESOMELY fast:
> 
> ~ \> ab [http://eli/env.cgi](http://eli/env.cgi) | grep ‘per second’  
> Requests per second: 4.04 [#/sec] (mean)

What are you comparing it against: plain cgi, mod\_ruby, or webrick?

> **···**
>
> On Thu, Sep 04, 2003 at 09:24:07AM +0900, ahoward wrote:
> 
> > ~ \> ab [http://eli/env.fcgi](http://eli/env.fcgi) | grep ‘per second’  
> > Requests per second: 557.10 [#/sec] (mean)
> 
> –  
> Dmitry Borodaenko

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [10 September 2003 14:55 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/5 "2003-09-10T14:55:39Z")

</div>

kwatch wrote:

> You can try ‘esehttpd’  
> [http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html](http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html)
> 
> It is very fast as HTTP server and CGI engine,  
> twice (or more) as fast as Apache + mod\_ruby.

Why am I just now hearing about this?! Ugh. $40 on an apache book, oh  
well, now I can put apache on my resume and forget about it. 😉 Thanks  
for the link.

Michael

---

<div class="post-metadata">

**Author:** ![Jeff\_Mitchell](https://avatars.discourse-cdn.com/v4/letter/j/e480ec/32.png) [@Jeff\_Mitchell](https://rubytalk.org/u/Jeff_Mitchell)\
**Post date:** [4 September 2003 18:06 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/6 "2003-09-04T18:06:32Z")

</div>

Dmitry Borodaenko [d.borodaenko@sam-solutions.net](mailto:d.borodaenko@sam-solutions.net) wrote in message news:[20030904144727.GB9114@sam-solutions.net](mailto:20030904144727.GB9114@sam-solutions.net)…

> **···**
>
> > On Thu, Sep 04, 2003 at 09:24:07AM +0900, ahoward wrote:
> > 
> > > you should definitely check out fastcgi and the ruby fastcgi binding. it’s  
> > > AWESOMELY fast:
> > > 
> > > ~ \> ab [http://eli/env.cgi](http://eli/env.cgi) | grep ‘per second’  
> > > Requests per second: 4.04 [#/sec] (mean)
> > 
> > What are you comparing it against: plain cgi, mod\_ruby, or webrick?
> > 
> > > ~ \> ab [http://eli/env.fcgi](http://eli/env.fcgi) | grep ‘per second’  
> > > Requests per second: 557.10 [#/sec] (mean)
> 
> ahoward’s post was unclear to me as well.
> 
> The performance of fastcgi would be essentially the same as  
> for mod\_ruby, would it not?

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard1](https://avatars.discourse-cdn.com/v4/letter/a/f19dbf/32.png) [@Ara.T.Howard1](https://rubytalk.org/u/Ara.T.Howard1)\
**Post date:** [4 September 2003 20:46 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/7 "2003-09-04T20:46:47Z")

</div>

> > you should definitely check out fastcgi and the ruby fastcgi binding. it’s  
> > AWESOMELY fast:
> > 
> > ~ \> ab [http://eli/env.cgi](http://eli/env.cgi) | grep ‘per second’  
> > Requests per second: 4.04 [#/sec] (mean)
> 
> What are you comparing it against: plain cgi, mod\_ruby, or webrick?

plain cgi.

Linux 2.4.18-27.8.0 i686  
httpd-2.0.47  
ruby-1.6.8

-a

> **···**
>
> On Thu, 4 Sep 2003, Dmitry Borodaenko wrote:
> 
> > On Thu, Sep 04, 2003 at 09:24:07AM +0900, ahoward wrote:
> 
> > > ~ \> ab [http://eli/env.fcgi](http://eli/env.fcgi) | grep ‘per second’  
> > > Requests per second: 557.10 [#/sec] (mean)
> > 
> > –  
> > Dmitry Borodaenko
> 
> ====================================
> 
> > Ara Howard  
> > NOAA Forecast Systems Laboratory  
> > Information and Technology Services  
> > Data Systems Group  
> > R/FST 325 Broadway  
> > Boulder, CO 80305-3328  
> > Email: [ara.t.howard@noaa.gov](mailto:ara.t.howard@noaa.gov)  
> > Phone: 303-497-7238  
> > Fax: 303-497-7259  
> > ~ \> ruby -e ‘p(%.\x2d\x29…intern)’  
> > ====================================

---

<div class="post-metadata">

**Author:** ![Michael\_Campbell1](https://avatars.discourse-cdn.com/v4/letter/m/e274bd/32.png) [@Michael\_Campbell1](https://rubytalk.org/u/Michael_Campbell1)\
**Post date:** [10 September 2003 15:30 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/8 "2003-09-10T15:30:22Z")

</div>

How “production quality” is esehttpd? (As compared to apache) Speed  
is good, but I’m a big believer in “Make it run. Make it run right.  
Make it run fast. In that order.”

> **···**
>
> — Michael Garriss [mgarriss@earthlink.net](mailto:mgarriss@earthlink.net) wrote:
> 
> > kwatch wrote:
> > 
> > > You can try ‘esehttpd’  
> > > [http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html](http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html)
> > > 
> > > It is very fast as HTTP server and CGI engine,  
> > > twice (or more) as fast as Apache + mod\_ruby.
> > 
> > Why am I just now hearing about this?! Ugh. $40 on an apache  
> > book, oh  
> > well, now I can put apache on my resume and forget about it. 😉  
> > Thanks  
> > for the link.
> 
> * * *
> 
> Do you Yahoo!?  
> Yahoo! SiteBuilder - Free, easy-to-use web site design software  
> [http://sitebuilder.yahoo.com](http://sitebuilder.yahoo.com)

---

<div class="post-metadata">

**Author:** ![Ara.T.Howard1](https://avatars.discourse-cdn.com/v4/letter/a/f19dbf/32.png) [@Ara.T.Howard1](https://rubytalk.org/u/Ara.T.Howard1)\
**Post date:** [10 September 2003 17:29 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/9 "2003-09-10T17:29:22Z")

</div>

this looks o.k. - but the ENTIRE webserver is blocked when running ONE cgi  
program. eg. it’s not a forking server. if you want speed, ease of  
development, safety, and _scalability_ i’d check out using apache/fastcgi/ruby

- might want to hang on to that apache book. 😉

-a

> **···**
>
> On Wed, 10 Sep 2003, Michael Garriss wrote:
> 
> > kwatch wrote:
> > 
> > > You can try ‘esehttpd’  
> > > [http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html](http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html)
> > > 
> > > It is very fast as HTTP server and CGI engine,  
> > > twice (or more) as fast as Apache + mod\_ruby.
> > 
> > Why am I just now hearing about this?! Ugh. $40 on an apache book, oh  
> > well, now I can put apache on my resume and forget about it. 😉 Thanks  
> > for the link.
> 
> ====================================
> 
> > Ara Howard  
> > NOAA Forecast Systems Laboratory  
> > Information and Technology Services  
> > Data Systems Group  
> > R/FST 325 Broadway  
> > Boulder, CO 80305-3328  
> > Email: [ara.t.howard@noaa.gov](mailto:ara.t.howard@noaa.gov)  
> > Phone: 303-497-7238  
> > Fax: 303-497-7259  
> > ~ \> ruby -e ‘p(%.\x2d\x29…intern)’  
> > ====================================

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [10 September 2003 17:47 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/10 "2003-09-10T17:47:40Z")

</div>

ahoward wrote:

> > kwatch wrote:
> > 
> > > You can try ‘esehttpd’  
> > > [http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html](http://ghost.math.sci.hokudai.ac.jp/esehttpd/en/index.html)
> > > 
> > > It is very fast as HTTP server and CGI engine,  
> > > twice (or more) as fast as Apache + mod\_ruby.
> > 
> > Why am I just now hearing about this?! Ugh. $40 on an apache book, oh  
> > well, now I can put apache on my resume and forget about it. 😉 Thanks  
> > for the link.
> 
> this looks o.k. - but the ENTIRE webserver is blocked when running ONE cgi  
> program. eg. it’s not a forking server. if you want speed, ease of  
> development, safety, and _scalability_ i’d check out using apache/fastcgi/ruby
> 
> - might want to hang on to that apache book. 😉

Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well  
that book is still right next to my monitor, close call. 😉 I wonder  
if I can abstract away the server somehow so I can port my app to any  
server?

I’m curious about using fastcgi with apache. Right now I’m not using  
cgi.rb at all and just using the Apache::Request class (using my own  
cookie class, etc). Are there speed benefits of using fastcgi over this  
approach? If so can you give me a push in the fastcgi direction (a link  
or whatever)?

TIA  
Michael

> **···**
>
> > On Wed, 10 Sep 2003, Michael Garriss wrote:

---

<div class="post-metadata">

**Author:** ![Aredridel1](https://avatars.discourse-cdn.com/v4/letter/a/d07c76/32.png) [@Aredridel1](https://rubytalk.org/u/Aredridel1)\
**Post date:** [10 September 2003 18:02 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/11 "2003-09-10T18:02:37Z")

</div>

> Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well  
> that book is still right next to my monitor, close call. 😉 I wonder  
> if I can abstract away the server somehow so I can port my app to any  
> server?
> 
> I’m curious about using fastcgi with apache. Right now I’m not using  
> cgi.rb at all and just using the Apache::Request class (using my own  
> cookie class, etc). Are there speed benefits of using fastcgi over this  
> approach? If so can you give me a push in the fastcgi direction (a link  
> or whatever)?

cgi.rb is that abstraction. It handles apache requests, cgi and  
fast\_cgi all in the same code. An app written with fast\_cgi in mind  
using the CGI module will work in all three environs.

Ari

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [10 September 2003 18:42 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/12 "2003-09-10T18:42:46Z")

</div>

Aredridel wrote:

> > Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well  
> > that book is still right next to my monitor, close call. 😉 I wonder  
> > if I can abstract away the server somehow so I can port my app to any  
> > server?
> > 
> > I’m curious about using fastcgi with apache. Right now I’m not using  
> > cgi.rb at all and just using the Apache::Request class (using my own  
> > cookie class, etc). Are there speed benefits of using fastcgi over this  
> > approach? If so can you give me a push in the fastcgi direction (a link  
> > or whatever)?
> 
> cgi.rb is that abstraction. It handles apache requests, cgi and  
> fast\_cgi all in the same code. An app written with fast\_cgi in mind  
> using the CGI module will work in all three environs.

Excuse my noobness on this. So when I do a look on RAA I find  
FastCGI-0.5 by Eli Green and also I find that there is a mod\_fastcgi  
for apache. Which are we talking about? Or do I have to have  
FastCGI-0.5 sit on top of mod\_fastcgi?

Michael

---

<div class="post-metadata">

**Author:** ![Idan\_Sofer](https://avatars.discourse-cdn.com/v4/letter/i/d6d6ee/32.png) [@Idan\_Sofer](https://rubytalk.org/u/Idan_Sofer)\
**Post date:** [10 September 2003 19:01 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/13 "2003-09-10T19:01:40Z")

</div>

Not entirely correct, fcgi can create cgi.rb enviroment, but that’s not it’s  
native interface, same goes for mod\_ruby.

Also, their are certain assumptions about the persistence of the application,  
plain old cgi will never persist, while fastcgi is persistent by it’s very  
nature.

> **···**
>
> On Wednesday 10 September 2003 21:02, Aredridel wrote:
> 
> > cgi.rb is that abstraction. It handles apache requests, cgi and  
> > fast\_cgi all in the same code. An app written with fast\_cgi in mind  
> > using the CGI module will work in all three environs.

---

<div class="post-metadata">

**Author:** ![David\_Corbin1](https://avatars.discourse-cdn.com/v4/letter/d/8491ac/32.png) [@David\_Corbin1](https://rubytalk.org/u/David_Corbin1)\
**Post date:** [10 September 2003 23:00 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/14 "2003-09-10T23:00:11Z")

</div>

But it doesn’t abstract the response control for the three different environs.  
Support fot thatis needed too.

> **···**
>
> On Wednesday 10 September 2003 14:02, Aredridel wrote:
> 
> > > Ah, ugh, dang, and that graph on the esehttpd site was so cool. Well  
> > > that book is still right next to my monitor, close call. 😉 I wonder  
> > > if I can abstract away the server somehow so I can port my app to any  
> > > server?
> > > 
> > > I’m curious about using fastcgi with apache. Right now I’m not using  
> > > cgi.rb at all and just using the Apache::Request class (using my own  
> > > cookie class, etc). Are there speed benefits of using fastcgi over this  
> > > approach? If so can you give me a push in the fastcgi direction (a link  
> > > or whatever)?
> > 
> > cgi.rb is that abstraction. It handles apache requests, cgi and  
> > fast\_cgi all in the same code. An app written with fast\_cgi in mind  
> > using the CGI module will work in all three environs.
> > 
> > Ari
> 
> –  
> David Corbin [dcorbin@machturtle.com](mailto:dcorbin@machturtle.com)

---

<div class="post-metadata">

**Author:** ![Idan\_Sofer](https://avatars.discourse-cdn.com/v4/letter/i/d6d6ee/32.png) [@Idan\_Sofer](https://rubytalk.org/u/Idan_Sofer)\
**Post date:** [10 September 2003 18:53 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/15 "2003-09-10T18:53:52Z")

</div>

FastCGI is a communication protocol, so it requires support from both ends,  
the web server and the “service”.

The communication occurs either using stdin/stdout, UNIX socket domains or  
TCP.

> **···**
>
> On Wednesday 10 September 2003 21:42, Michael Garriss wrote:
> 
> > Excuse my noobness on this. So when I do a look on RAA I find  
> > FastCGI-0.5 by Eli Green and also I find that there is a mod\_fastcgi  
> > for apache. Which are we talking about? Or do I have to have  
> > FastCGI-0.5 sit on top of mod\_fastcgi?

---

<div class="post-metadata">

**Author:** ![Michael\_Garriss1](https://avatars.discourse-cdn.com/v4/letter/m/958977/32.png) [@Michael\_Garriss1](https://rubytalk.org/u/Michael_Garriss1)\
**Post date:** [10 September 2003 19:13 UTC](https://rubytalk.org/t/webrick-and-mod-ruby-performance/7826/16 "2003-09-10T19:13:57Z")

</div>

Idan Sofer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----  
> Hash: SHA1
> 
> > Excuse my noobness on this. So when I do a look on RAA I find  
> > FastCGI-0.5 by Eli Green and also I find that there is a mod\_fastcgi  
> > for apache. Which are we talking about? Or do I have to have  
> > FastCGI-0.5 sit on top of mod\_fastcgi?
> 
> FastCGI is a communication protocol, so it requires support from both ends,  
> the web server and the “service”.
> 
> The communication occurs either using stdin/stdout, UNIX socket domains or  
> TCP.

Thanks for the info. I will look into fastcgi more carefully now.

Regards,  
Michael

> **···**
>
> > On Wednesday 10 September 2003 21:42, Michael Garriss wrote: