edit
We've changed it to "custom" pricing for now, and will work on an updated pricing table to better reflect our intention of having an SLA included. Thanks again!
Apologies for the "amateurish" impression, it was actually meant to be a plan that would include the entry level SLA with guaranteed response times. After reading some of the feedback here, it's definitely something we're aiming to fix in the next update. Thank you for your feedback! :)
edit
We've changed it to "custom" pricing for now, and will work on an updated pricing table to better reflect our intention of having an SLA included among other things. Thanks again! :)
Re: the deluxe version. Hmm, that wasn't our intention, we merely wanted to include a plan that had the entry level SLA pricing attached to it for support with guaranteed response-times. Apologies if it wasn't clear enough, but we'll be sure to fix this in a future site update.
Re: third server, if you're a startup, you'd end up buying 2 startup licenses. If you're not a startup, that'd be 2 pro licenses (or as you mentioned, buy 25 pro licenses to get up to 50 servers). Hope that clears things up a bit, it definitely is good to get constructive feedback like this so we can try and fix it. Much thanks! :)
The Sofa guys are super talented and I wish Koen and his team all the best on this new and exciting venture! Congrats to Facebook on acquiring such an outstanding team! :-)
Cappuccino has this neat feature of being able to use nibs that you create in Interface Builder by converting it to their own format cib (iirc for web optimization, at least I've noticed .cib filesizes in general be (significantly) smaller than their .nib counterparts, but this could be coincidental).
Normally you use a commandline tool called nib2cib for this which you had to execute everytime you changed your nib to get a corresponding updated cib. This arguably breaks the workflow a bit (it's pretty easy to forget to do a nib2cib after modifying your nib). The tool Klaas Pieter created aims to eliminate that extra step by watching your resources directory for changed nibs if I've understood correctly. Once it detects a changed nib it will run nib2cib for you on that nib for a fresh cib.
Ease of use, dynamic spawning of new processes and spinning them down according to the traffic you receive as opposed to a static pool of processes, fault tolerant to crashes through watchdog process which will automatically restart as much for you as it can in such an event, concurrently handling of multiple requests as opposed to a single request (thin has a multithread option but this is experimental iirc, so I'm not sure how this works yet in production). Basically less moving parts.
Thin uses mongrel / eventmachine / rack, all non-blocking concurrent libraries. Backed up by a good ORM (I use DataMapper, but AR may have got its concurrency patches), you may roll out quite a fast application with quite a low-end server machine.
So it all basically comes down to ease of deploy against more controlled environment.
I think every new rails application should use 1.9.2 and rails 3 by now. Concurrency should not be an issue.
Thin doesn't use Mongrel and Mongrel isn't non-blocking and isn't a library. Rack is not a non-blocking concurrent library.
You can use non-blocking concurrent libraries and use Thin in async mode yes. However the quality of support for it varies. Not everything supports Fiber-yielding-to-EventMachine at this time and for applications without long-running I/O blocking operations there's little difference in throughput between async-Thin and multiprocessing servers like Phusion Passenger. If you have long-running I/O blocking operations, like Twitter API calls that can last several seconds, then yes Thin is better.
On the ease of use and stability department, we believe Phusion Passenger is easier to set up than Thin. We also monitor and restart our stuff automatically so that if anything crashes you don't have to manually restart things like is the case with Thin.
As for resource consumption: Phusion Passenger can start and stop processes dynamically. On a low-end server you can configure it to not start your application process (or only start very few of them) until it's needed. We also have plans to implement multithreading support in future versions, with the eventual goal of being hybrid multiprocessed/multithreaded/evented so that the user can choose the best of all worlds.
> Thin doesn't use Mongrel [...] Rack is not a non-blocking concurrent library.
Well, Thin uses mongrel's parser. Which makes it a sort of a library. And by concurrent I actually meant thread-safe. But forget it.
The main point is: I cannot get any more better / optimal cpu usage with passenger (although I'm certainly getting some cpu / memory overhead). My single thin instance loads every single cpu core to 100% when attacked by httperf. And I was never able to crash it, although I probably didn't do my best.
Monitoring and managing tools are okay, though monit and munin have been here for ages and I sort of like what they're capable of.
But I still agree that ease of use is important for making ruby/rails even simpler and funnier to do. Whatever, no offense intended.
Apologies for the "amateurish" impression, it was actually meant to be a plan that would include the entry level SLA with guaranteed response times. After reading some of the feedback here, it's definitely something we're aiming to fix in the next update. Thank you for your feedback! :)