Thin web server


#1

Hi,

Today only I came to know about ‘thin’ web server. I have installed the
gem and used it. But I don’t know whether ‘thin’ web server is better
than webrick or mongrel. If so, can you please compare these web
servers?

Thanks in advance…


#2

Webrick is the webserver bundled with rails and is makes u ready to
start
development instantly… it is not suitable for production environments
as
stated in the rails wiki
http://wiki.rubyonrails.org/rails/pages/WEBrick.
so get it out of the comparisons.

There are several resources out there which made comparison between thin
and
mongrel.
thin is known to be faster than mongrel and has less memory consumption.
check this out:
http://fukamachi.org/wp/2008/02/28/mongrel-vs-thin/
http://www.wikivs.com/wiki/Mongrel_vs_Thin

It also has the advantage of using sockets to communicate with the load
balancerhttp://macournoyer.wordpress.com/2008/01/26/get-intimate-with-your-load-balancer-tonight/which
can be a great plus

It is recommended that u get to know Thin more.

On Wed, Dec 3, 2008 at 11:16 AM, Karthi kn
<removed_email_address@domain.invalid

wrote:


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


Mahmoud Said
Software Developer
blog.modsaid.com
www.eSpace.com.eg
+20-16-1223857


#3

Thanks a lot Mahmoud. The links you gave were very useful.


#4

You are welcome,

Actually I tried benchmarking them last night…
with 10000 requests and concurrency level 400… requesting a static
resource of size 1.5KB
thin was quite faster…

Mongrel:
Concurrency Level: 400
Time taken for tests: 37.370 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 17470000 bytes
HTML transferred: 15510000 bytes
Requests per second: 267.59 [#/sec] (mean)
Time per request: 1494.800 [ms] (mean)
Time per request: 3.737 [ms] (mean, across all concurrent
requests)

Thin:
Concurrency Level: 400
Time taken for tests: 16.051 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 17328660 bytes
HTML transferred: 15517755 bytes
Requests per second: 623.02 [#/sec] (mean)
Time per request: 642.037 [ms] (mean)
Time per request: 1.605 [ms] (mean, across all concurrent
requests)

the gap was reduced though when i dropped the concurrency level to 1
Mongrel
Concurrency Level: 1
Time taken for tests: 20.795 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 17470000 bytes
HTML transferred: 15510000 bytes
Requests per second: 480.87 [#/sec] (mean)
Time per request: 2.080 [ms] (mean)
Time per request: 2.080 [ms] (mean, across all concurrent
requests)

Thin
Concurrency Level: 1
Time taken for tests: 14.597 seconds
Complete requests: 10000
Failed requests: 0
Write errors: 0
Total transferred: 17320000 bytes
HTML transferred: 15510000 bytes
Requests per second: 685.06 [#/sec] (mean)
Time per request: 1.460 [ms] (mean)
Time per request: 1.460 [ms] (mean, across all concurrent
requests)

that’s was a bit expected due to the fact that thin uses EventMachine
instead of spawning threads for handling requests like mongrel… the
more
concurrency level u have… the more context switching between threads…
so
if you are deploying a website that expects high traffic… that’s a very
important point to consider.

On Thu, Dec 4, 2008 at 11:21 AM, Karthi kn
<removed_email_address@domain.invalid

wrote:

Thanks a lot Mahmoud. The links you gave were very useful.

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


Mahmoud Said
Software Developer
blog.modsaid.com
www.eSpace.com.eg
+20-16-1223857


#5

On Thu, Dec 4, 2008 at 11:59 AM, Frederick C. <
removed_email_address@domain.invalid> wrote:

Although anyone sane is using nginx/apache for static content,
and for
dynamic stuff the time spent in rails will almost always dominate the
overhead from mongrel/thin (and of course pre 2.2 only one of those
requests is handled per instance at any one time)

Fred

I totally agree Fred,
i was just testing them directly on my local machine. so i used a static
resource instead of a very small rails action.
Most of the time will be wasted in the ruby code executing the action
itself. I just wanted to focus on the rest of the time (that application
independent part)


Mahmoud Said
Software Developer
blog.modsaid.com
www.eSpace.com.eg
+20-16-1223857


#6

On 4 Dec 2008, at 09:44, Mahmoud Said wrote:

that’s was a bit expected due to the fact that thin uses
EventMachine instead of spawning threads for handling requests like
mongrel… the more concurrency level u have… the more context
switching between threads… so if you are deploying a website that
expects high traffic… that’s a very important point to consider.

Although anyone sane is using nginx/apache for static content, and for
dynamic stuff the time spent in rails will almost always dominate the
overhead from mongrel/thin (and of course pre 2.2 only one of those
requests is handled per instance at any one time)

Fred


#7

Mahmoud Said a écrit, le 12/04/2008 10:44 AM :

[…]
that’s was a bit expected due to the fact that thin uses EventMachine
instead of spawning threads for handling requests like mongrel… the
more concurrency level u have… the more context switching between
threads…

Ruby threads are green threads : there’s no context switching. And IIRC
they are built around select internally so they basically use the same
underlying system code EventMachine uses.

Lionel


#8

On Thu, Dec 4, 2008 at 12:36 PM, Karthi kn
<removed_email_address@domain.invalid

wrote:

My thought is that, both Mongrel/Thin will spend same time in rails. Or
will there be any difference?

i guess both should spend nearly the same time in rails code… you’ll
notice
the difference if you have small request (requests that required not
much
processing)

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


Mahmoud Said
Software Developer
blog.modsaid.com
www.eSpace.com.eg
+20-16-1223857


#9

My thought is that, both Mongrel/Thin will spend same time in rails. Or
will there be any difference?


#10

On Thu, Dec 4, 2008 at 1:10 PM, Lionel B. <
removed_email_address@domain.invalid> wrote:

underlying system code EventMachine uses.

I’m not sure about how ruby green threads or implemented. but I guessed
they
have some scheduling mechanism (within the user space) that is different
from the EventMachine approach. Thus scheduling and switching overhead.
Maybe I’m wrong… and there is some other reason that makes thins quite
faster for small requests.

I tried comparing them again for a very small request that does nothing
but

render :text=>‘1234567890’

thin is 79% faster than mongrel

Mongrel

Server Software: Mongrel
Server Hostname: localhost
Server Port: 3001

Document Path: /
Document Length: 10 bytes

Concurrency Level: 500
Time taken for tests: 60.121 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 468000 bytes
HTML transferred: 10000 bytes
Requests per second: 16.63 [#/sec] (mean)
Time per request: 30060.399 [ms] (mean)
Time per request: 60.121 [ms] (mean, across all concurrent
requests)
Transfer rate: 7.60 [Kbytes/sec] received

Thin

Server Software: thin
Server Hostname: localhost
Server Port: 3000

Document Path: /
Document Length: 10 bytes

Concurrency Level: 500
Time taken for tests: 33.922 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 444652 bytes
HTML transferred: 10060 bytes
Requests per second: 29.48 [#/sec] (mean)
Time per request: 16961.071 [ms] (mean)
Time per request: 33.922 [ms] (mean, across all concurrent
requests)
Transfer rate: 12.80 [Kbytes/sec] received

For larger requests (requests that needs db queries and a lot of
processing)
they’re nearly the same

Lionel


Mahmoud Said
Software Developer
blog.modsaid.com
www.eSpace.com.eg


#11

Karthi kn wrote:

Hi,

Today only I came to know about ‘thin’ web server. I have installed the
gem and used it. But I don’t know whether ‘thin’ web server is better
than webrick or mongrel. If so, can you please compare these web
servers?

Thanks in advance…
The main advantage of Thin over Mongrel, is not only increased
throughput, you also get:

  • easy clustering
  • smaller memory footprint

Thin has been running for over 8 months now at www.digiprof.fr, and we
only experienced a crash once, certainly due to a memory leak somewhere
in our application code.