Which webserver to use in production?

Rails
1

Apologies in advance if this ignites a war of comflicting opinions…

I’m a few days away from going live with my first RoR application. It
is completely database centric and each user will have his own queries
so cacheing will not really help.

I have a dedicated linux server being built by my hosting provider and I
need to tell them which webserver to use. The databse is MySQL btw.

Should it be Apache with FastCGI or lighttpd?

I’ve not idea yet on the number of users but if this took off then maybe
5000? Maybe I’ll need 10 boxes!!!

I suppose the best I could liken it to is Hotmail. So the question how
much gear will I need to support 5000 concurrent users?

Of course it could take 100 years to get to 5000 users in which case
I’ll need to think of something else for my pension!

2

for lots of concurrent users i’d recommend Apache since lighttpd has 0
support for concurrent users being a single process single threaded
application. Lighttpd is very good at what it does though, and is
very fast for what it is, however apache is tried and true for this
kind of large scale deployment.

On 7/24/06, jh100000 [email protected] wrote:

Posted via http://www.ruby-forum.com/.

Rails mailing list
[email protected]
http://lists.rubyonrails.org/mailman/listinfo/rails

–
Ryan McGovern
UCIT Public Computer Labs
Lab assistant / “web guy”
412a Teachers College
513-556-2418

3

On 07/24/06 07:11, ryan mcgovern wrote:

is completely database centric and each user will have his own queries
I suppose the best I could liken it to is Hotmail. So the question how
much gear will I need to support 5000 concurrent users?

Of course it could take 100 years to get to 5000 users in which case
I’ll need to think of something else for my pension!

Ryan,
I’m not sure how you’re making those determinations about Lighttpd being
unsuitable for concurrent users… select-based servers like lighty or
thttpd are documented (google some benchmarks) as being quite capable of
serving multiple users at once.

-Marshall

4

jh100000 wrote:

Should it be Apache with FastCGI or lighttpd?

How about neither? Or if you really want Apache toss Mongrel behind it.
FastCGI is not a good solution and is not really stable. The FastCGI
project for Apache last I recall has been dead for some time now.
FastCGI for Lighttpd has issues right now unless they’ve been addressed.

Other options:

  1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly
    easy)
  2. Pound + Mongrel (Simple)
5

Are you sure you mean concurrent users? That means handling 5000
simultaneous requests. I doubt there are more then a couple of dozen
sites on the whole internet that come close to that. Remember, 5000
logged in users on your site does not translate to 5000 concurrent
users. Depending on your traffic patterns it probably translates to
less than 100 or so.

6

I use Pound with mongrel_cluster behind Apache with mod_proxy, because
I’m
running Apache 2.0 and using it for vhosting some other apps. If you can
get
'em to install Apache 2.2 you can use Apache + mod_proxy_balancer and
mongrel_cluster.

Mongrel is super-simple to set up and use, seems quite stable, and
mongrel_cluster makes it very easy to manage. I used Lighty on a web app
that saw pretty intense usage earlier this year, and I had some problems
with zombie FastCGI processes, and reviving it usually required a
reboot.
This only happened a couple times, though, so my overall experience with
Lighty was very good. It’s also easy to set up and use. My biggest
concern
with Lighty is that it seems that development has stalled… They
haven’t
released an update in some time.

Matt

7

I’ve never tried LiteSpeed before, so this is a totally naive
question…
How would you scale LiteSpeed across multiple machines? At some point
you’re
going to hit a wall where one machine can’t handle the load, no matter
how
powerful it is… In my experience, the FastCGI or Mongrel solution of
having a server like Lighty or Apache balance across multiple app
instances
on multiple machines seemed attractive and easy to scale. Deployment is
easy, too.

If you use LiteSpeed with LSAPI, would you just keep adding LiteSpeed
servers and balance across them with another LiteSpeed server acting as
a
static load balancer? Or use Pound or some other specialized load
balancer
to balance across the LiteSpeed servers?

Also, is there any documention on deploying into LiteSpeed with
Capistrano?
I know there’s a lot of hooks in mongrel_cluster for Capistrano, but I’m
unaware of how it would work with LiteSpeed…

Thanks,

Matt

8

Matt W. wrote:

I’ve never tried LiteSpeed before, so this is a totally naive
question…
How would you scale LiteSpeed across multiple machines? At some point
you’re
going to hit a wall where one machine can’t handle the load, no matter

There is a litespeed enterprise version that I assume handles this.

9

There is no big differences between LiteSpeed and other solutions for
scaling across multiple servers. Like you said, you can use LiteSpeed
web server as a load balancer in front of a LiteSpeed cluster just like
what you will do with lighttpd or Apache. LiteSpeed has better
performance as we knew. Enterprise Edition is recommended for the load
balancer role. We are going to release a dedicate load balancer which
can do stateful load balancing if the internal stateless load balancer
does not meet your needs.

Since Pond is multi-threaded, its scalability is not as good.

Deploying Rails applications into LiteSpeed with Capistrano should be
easier than that with mongrel_cluster, I think, since you don’t need to
patch deploy.rb at all. With LiteSpeed + LSAPI, there is no need to
start mongrel manually, everything has been taken care of by web server.

Just read a tutorial on “Rails + Mongrel + Apache + Capistrano”, I have
to say, that are a heck lot of configurations, and it is only a single
server setup. Similar setup can be done much more easily with LiteSpeed

  • LSAPI + Capistrano, and performance should be better. Unless rails are
    deployed on multiple servers, you don’t need to bother load balancing at
    all. :slight_smile:

If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :slight_smile:

Best Regards,
George W.

10

When you deploy a new version of an app with Capistrano, the /current
symlink is updated to point to the new version of the app… Usually
Capistrano calls reaper to kill any running FastCGI processes, and
spawner
to start up a the new version that’s pointed to by /current. Does
LiteSpeed

  • LSAPI circumvent this and automatically detect the switch between the
    two
    versions of the app, and then start immediately handling requests with
    the
    new version?

If so, that would rock… I’m getting ready to look into deployment with
a
poetentially high-traffic app, and this would be a really cool solution.

Thanks!

Matt

11

There is no doubt that we will recommend LiteSpeed + LSAPI. :wink:
Not only because we are the developers of LiteSpeed Web Server, but also
LiteSpeed + LSAPI has solve some problems that other setup cannot.

There is my take based on information collected, please correct me if I
were wrong. Not to criticize others, just want to help people making
decisions.

Apache/lighttpd + FCGI: Apache and lighttpd does not support FCGI
persistent connections, lighttpd FCGI has reliability issue. Cannot do
dynamic spawning due to high cost at Rails framework initialization
time, system resource could be wasted under some situation like Rails
hosting services.

Mongrel is very easy to use, and Rails performance is pretty good as
well. Its weakness is on serving static files, usually need to be use
with other web servers in production environment that receiving high
traffic. Need to run multiple instances with mongrel_cluster to take
advantage a SMP server and serving multiple clients at the same time,
the setup has been complicated a little bit. Same as FCGI, you cannot do
dynamic spawning with mongrel either.

Since Pound cannot serve static content, Pound + mongrel_cluster is not
a optimum solution unless most of traffic is dynamically generated,
adding an extra layer of web server helps, but it will complicate things
even more and introduce higher latency and server load. Lighttpd +
mongrel_cluster is not recommended by Zed, the developer of mongrel, due
to bug in lighttpd proxy, at this moment.

LiteSpeed + mongrel_cluster probably is the best solution for user who
prefers Mongrel right now. Jason from textdrive.com has written that
Apache 2.2 + mongrel_cluster has the best performance in his blog, We
cannot confirm that because we haven’t played with Apache 2.2 yet,
however, textdrive.com and strongspace.com are all powered by LiteSpeed
currently. :wink:

LiteSpeed + Rails via LSAPI is designed to overcome issues mentioned
above after analysis their Pros and Cons.

Here is a Rails benchmark by third party. It is in Japanese, but the
graph is an universal language.
http://wota.jp/ac/?date=20060608

Tutorial on LiteSpeed + Ruby is in our Wiki
http://www.litespeedtech.com/community/wiki/doku.php

Best Regards,
George W.

12

Ed,

I’m actually pretty amazed with how transparent Capistrano deployments
are,
regardless of the web server. I had a shortlived data entry app running
earlier this year that had a large number of people working round the
clock
on it, and I ran several deployments while they were working without a
single problem. As long as your deployment itself works, it shouldn’t be
much of an issue for downtime.

Matt

13

I am also curious about this. I’m writing a rails app for a high
traffic
site and it can’t afford to be unreachable for more about 1 second.

ed

14

This is also an area of interest to me as we will be releasing our RoR
app too. I have to say I hadn’t given much consideration to LiteSpeed
much before reading this post. After some research it really does seem
like an excellent solution, especially from a performance and security
perspective.

15

Generally speaking, what happens is that the web server is switched
to serving a static maintenance page while the code is switched out,
the reenabled for dynamic content once the update is done.

16

On 7/25/06, George W. [email protected] wrote:

Since Pond is multi-threaded, its scalability is not as good.

Does it mean that multi-threading is in general slower? How does
litespeed handle this problem?

If mongrel_cluster is easy to you, give LiteSpeed + LSAPI a try. :slight_smile:

Interesting. What is the difference between LSAPI and FastCGI?

Best Regards,
George W.

–
Kent

17

Does it mean that multi-threading is in general slower?
No necessarily, but usually, thread scheduling and synchronization are
extra costs, and it requires more memory for per-thread stack space,
that’s usually limits the scalability of multi-thread application.
How does litespeed handle this problem?

LiteSpeed is single threaded and uses event-driven non-blocking socket.

Interesting. What is the difference between LSAPI and FastCGI?
Similar. You can think LSAPI as specially optimized FastCGI for
LiteSpeed. :slight_smile:

George

18

When you deploy a new version of an app with Capistrano, the /current
symlink is updated to point to the new version of the app… Usually
Capistrano calls reaper to kill any running FastCGI processes, and
spawner to start up a the new version that’s pointed to by /current.
Does LiteSpeed + LSAPI circumvent this and automatically detect the
switch between the two versions of the app, and then start immediately
handling requests with the new version?
If you run LiteSpeed + LSAPI on a cluster node, you only need to let
Capistrano to call “lsws/bin/lswsctrl restart” to archive the same
result. restart is graceful without any downtime.

19

On 7/24/06, Mark H. [email protected] wrote:

  1. http://www.litespeedtech.com Litespeed + LSAPI (Fast and fairly
    easy)
  2. Pound + Mongrel (Simple)
  1. Apache + mod_fcgid

Isak

20

Ed,

Can you share a little bit about your current rails setup with minimum
downtime? I am interested to know and it will benefit others.

With LiteSpeed, there is no downtime during a graceful restart, even
during a server software upgrade, so front-end web server is always
available. However, the server will queue up requests when back-end
Rails restart. Unfortunately, the Rails framework takes some time to get
initialized for each instance, usually longer than 1 second, I believe.
LSAPI reduced this to minimum by forking all new Rails processes off an
already initialized parent process. Only the parent process need to take
time to initialize the framework once. The saving is significant if you
need to start many rails instances all at once.

Best Regards,
George