Thanks!

My, how very different my experience has been.

Ramaze: 'gem install ramaze' Copy&Paste “simple.rb”. launch it. Woo! I'm seeing a web page! Good start!

Padrino. 'gem install padrino' padrino project myproject -d sequel, bundle install (?), padrino admin, padrino rake seed. Error.

Yea, the one-file Ramaze launch doesn't have a database hooked up. But for “out of the box,” I had *something* working almost instantly. I spent about two hours trying to get Padrino to give me a web page with data from my database. Despite some helpful advice from the #padrino IRC folks, I got stuck, and moved to Ramaze. It 'incremented' much better: I got a text-only page served, then one with dynamic Ruby variables appearing, then got the database connected. Far less frustrating, and far more productive.

For the memory consumption (if I remember correctly) can be decreased a bit if you run the app without bundler, btw consider that you load a full stack of padrino including admin, mailer and helpers gen and you can adjust it to load only what you really need.

The directory structure for Padrino is near to others frameworks BUT you can tweeak according to your needs.

Thanks so much!

I fully admit I am not experienced with ramaze which is why I was hoping to get somebody more familiar to look over the test app and fix any issues I missed. How do I set ramaze to 'live' mode? I figured setting the environment to production would automatically use sensible defaults as is the case in sinatra/rails/padrino/merb ?

In more_advanced, I opted for each framework to use their 'default stack' although I admit this causes confounding variables. The question becomes which is more accurate then? Are more people going to be using the framework with the default stack or is it more accurate to make all the chosen tools homogenous. The issue was with camping for instance that doesn't even support haml. However in the 'more_advanced' branch every other framework is in fact using haml so I don't think it was too misleading unless I am mistaken. I mention this caveat in the github readme.

As regard to caching, I assume that it is enabled when I set the environment mode to production on the server. For rails/sinatra/padrino/merb I think that is all which is necessary. I would very much appreciate if you could look through the ramaze apps in the three branchs (or at least more_advanced) and let me know what I should change to be more fair. I honestly want to produce the best benchmarks possible. I will happily update all our results once the changes have been made.

Thanks again for your feedback!

1) No ORM was involved or appeared to be involved in the “more_advanced” benchmark. It was good to see a progression from dirt simple to more complex scenario. For me, I usually don't involve a framework until I need to hit a database, so I stick with webby and static pages until the need for data arises, so I would've been highly interested in the more_advanced test if it had an ORM involved.

2) Running the benchmarks with all the logging and debugging facilities of development mode turned on. I didn't see, for example in the Ramaze project, where you specified “live” mode when benchmarking.

3) Refrain from showing test results for haml mixed with others with erb with others with markaby. I think that is, at best, misleading, but if you do do it, express a “this is the preferred production set up of the respective frameworks” disclaimer. In other words, compare apples to apples at every level of the stack with the aim being that the only real variable is the framework layer. Sinatra supports all of the templating engines, so in your case where you're representing Padrino vs. the world, configure it to go up against the best of each of the other frameworks rather than as I did by configuring Padrino to match my favored environment of Sequel and Erubis as my ORM and rendering engines of choice. Or ensure all the frameworks chosen in the suite can run with the settings chosen for Padrino.

4) Is caching turned on in all the right places for each of the platforms? I know Ramaze in particular had some issues with caching haml templates and that may be turned off for Ramaze presently until the caching issues are resolved.

Those were some of the questions I asked myself.

We honestly want to provide the best benchmarks possible. Do you think that the applications we chose weren't a good fit? or we were not testing through apache/passenger (used a single thin process)? What caused our benchmarks to be 'off' in your opinion?