Thin

Comments and changes to this ticket

• 

  Kevin Williams January 30th, 2008 @ 04:03 PM

  • → Milestone changed from “” to “0.7.0”
  • → State changed from “new” to “open”
• 

  Alex MacCaw January 31st, 2008 @ 03:37 AM

  Looks like a I used an old Thin repos to make the patch - a lot of things have changed since then so I'll update the patch to the lastest repos revision.

• 

  Alex MacCaw January 31st, 2008 @ 07:29 AM

  Ok, here's the updated patch. At the moment I can get Swiftiply to do about 1226 requests per second, while nginx is around 5780.

  • thin_swiftiply3.diff 6.5 KB
• 
  This has been marked as spam

  Kirk Haines May 1st, 2008 @ 11:42 PM

  That seems awfully low. I'll take a look at the code as soon as I have time.

  Kirk Haines

• 

  macournoyer January 31st, 2008 @ 10:11 AM

  thx Kirk, I'll wait for your feedback before applying the patch

• 

  macournoyer January 31st, 2008 @ 03:37 PM

  post_init if @swiftiply
  

  should be placed at the end of Connection#process not receive_data or else the request will be resetted at each packet received.

  That might be the reason why it's slower then expected.

• 

  macournoyer January 31st, 2008 @ 03:53 PM

  I did a quick benchmarks w/ a small rails app and perf seems very much the same:

  nice -n20 ab -n5000 -c3 0.0.0.0:8080/simple

  Swiftiply: 109.93 req/sec

  Nginx w/ unix sockets: 108.13 req/sec

• 
  This has been marked as spam

  Kirk Haines May 1st, 2008 @ 11:47 PM

  This patch gives Swiftiply (http://swiftiply.swiftcore.org/) support to Thin. It allows you to pass a --swiftiply option to Thin, with an optional authentication key. Clustering with Swiftiply also works.

• 

  macournoyer January 31st, 2008 @ 09:15 PM

  uh? I think lighthouse ate your comment or something kirk, you posted the ticket description.

• 

  Alex MacCaw February 1st, 2008 @ 06:29 AM

  I found out the reason for that performance problem (and am almost too embarrassed to admit to it). I was fetching the default index.html page, rather than doing a proper rails action. Nginx was configured for caching, so it served up that static page, while swiftiply was not. With that rectified I now get an average of 85.31 req/s for nginx, compared to 87.15 for swiftiply - which is very good for a ruby balancer. It's amazing to think that we can now deploy Rails apps with just a Ruby stack (forget about the C for the moment ;)). All anyone needs to get running is a couple of gems. They can even do the monitoring in God.

• 
  This has been marked as spam

  Kirk Haines May 1st, 2008 @ 11:57 PM

  This patch gives Swiftiply (http://swiftiply.swiftcore.org/) support to Thin. It allows you to pass a --swiftiply option to Thin, with an optional authentication key. Clustering with Swiftiply also works.

• 
  This has been marked as spam

  Alex MacCaw May 1st, 2008 @ 11:57 PM

  Kirk, are you some sort of lighthouse bot? ;)

• 
  This has been marked as spam

  Kirk Haines May 1st, 2008 @ 11:57 PM

  That's annoying. Replies via email seem to not be working right.

  Okay, what I had said is that it's good that you found the problem, since I wasn't going to be able to get to it until last night.

  Then this morning I said that I'm currently running about 20 sites an on all-ruby stack, with that number increasing weekly. Also, Swiftiply does support sending files from the Rails cache dir. Static performance is not quite so fast as nginx, but it is pretty fast. Whips Apache's tail handily.

• 

  macournoyer February 9th, 2008 @ 02:14 AM

  applied w/ some modifications, now on git master

  thx a lot for the contribution Alex!

• 

  macournoyer February 9th, 2008 @ 02:16 AM

  • → State changed from “open” to “resolved”
• 

  Matt Todd February 9th, 2008 @ 03:10 PM

  /me applauds excitedly!