performance

[nick.go...@gmail.com]

i was wondering if rightscale devs could share a few details about production setup they use praxis in: app server, load, benchmarks, etc - just to see what kind of load praxis can handle

[Josep Blanquer]

Nick,

 We don't have any Praxis app in production today, but we are close to deploying the first few (in just a few weeks).

However, we do have many apps that are built in some previous incarnations of what Praxis is today (which are less performant and less featureful).

I did write a few words about that in the original blog post in case you haven't seen that (http://eng.rightscale.com/2014/08/22/unveiling_praxis.html). 

In terms of performance, that's a longer thing to discuss I guess, since it has many different aspects, from the Web aspect, to the mediatype rendering aspects, to the param coercing, to filtering....even to the DB performance (if you use our Praxis mapper, for example)

I'm happy to dive into any of them if need be, and in fact I was planning to write some microbenchmarks in the blog to get some basic numbers for comparisons and discussions...but I haven't had the time yet.

Let me just say this, though: performance has been at the front and center of our goals. So while there is always a tradeoff about ease of programming, features and raw performance, we've been fairly conscious of the performance implications. Now, I know that without putting numbers forth for all this is still too fuzzy and doesn't really respond your question head on...but let me give you a couple high-level datapoints that come to mind:

1. I do remember doing some micro-benchmarks a few weeks ago (you know, returning a typical "hello world" string action) and I was getting slightly better results than sinatra (they both were close to 20K r/s with 10 concurrent and persistent connections) compared to raw rack that was a little over 30Kr/s (which would be the ceiling in my Mac). Obviously the point of Praxis is not to be fast at returning a simple string :) ... so the gains would only get better with more complex/real apps that involve true parameter/header/payload parsing, mediatype rendering, validation...etc. The point is that the baseline seemed to be, at the very least, on par with Sinatra for the worst case scenario...which is considered a fast and lightweight framework to begin with.
2. We've also looked at rendering and type coercion in the past, and do some quick comparisons with somehow related gems. I do not recall any of the initial numbers but I do recall that we were quite pleased with the performance of the underlying attributor and praxis-blueprints gems (the ones that deal with the "types", "corecion", "validation", "rendering").... especially because we saw that it was either close to the performance of other gems that had many many less features, or had much better performance to gems that were more on par with the features.

Anyway, I hope that gives you a little more color on that area. And hopefully we can actually get some initial baseline numbers and write a blog entry about it so we can start discussing specifics.

Cheers!

Josep M.

On Mon, Oct 20, 2014 at 8:13 PM, <nick.go...@gmail.com> wrote:

i was wondering if rightscale devs could share a few details about production setup they use praxis in: app server, load, benchmarks, etc - just to see what kind of load praxis can handle

--
You received this message because you are subscribed to the Google Groups "praxis-development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-developm...@googlegroups.com.
To post to this group, send email to praxis-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/praxis-development/be0fc83a-1f84-4283-87c8-3e49de6f6ac2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nick gorbikoff]

Thanks. That's pretty much what I was looking for. A bit of assurance that if I invest time it won't disappoint in production in terms of performance. Right now we have an interal ERP-style Rails app, that is getting pretty sluggish, since we have to rewrite and reorganize it anyways, I'm looking into  an API / Javascript Frontend setup versus a Rails 4.2 update. I'm exploring options such as grape, rails-api, rocket pants and praxis . Here are may basic impressions so far 

• Grape - lacks structure. There was some discussion about adding a generator a few year ago but it went nowhere. Some people like it that way which is fine for a small project, but it becomes chaotic in a larger project, cause everyone has their own preferred way of doing things. And while it has a few outdated examples, the official documentation provides a twitter example. What does twitter have to do with real world db-backed app sample? So to tired of twitter examples everywhere. grrrr Anyways that was the number one choice, until I found praxis.
  
• Rails-api - is just a stripped down version of Rails, while it's lighter it's still a behemoth
• Rocket pants - is built on top of Rails-api. They are going through a major-rewrite, and it's hard to gauge write now.
• Praxis - I like praxis so far for it's combination of basic structure, flexibility and good documentation and getting started guide that took me to working basic app in an hour ( it took me a whole freaking day to setup grape working properly with Rail 4 as an api engine because documentation and sample are conflicting and everyone is doing it "their" way)

--
--------------------------------------

Nick Gorbikoff
nick.go...@gmail.com

[Josep Blanquer]

just one note about the generators.

We need to add more stuff in that area, and hopefully we can do that soon. For example:

Have a generator for a skeleton app: the right directories, the rackup files, gemfiles, rspec structure initialization...etc.

Generators for adding an API resource: which perhaps will create a shell for a resource_definition file, a controller file and perhaps a mediatype file..

etc,

A blank skeleton, but fully configured for you to get going is the first one that will come out (just a matter of finding an hour or two of time)

Cheers,

Josep M. 

[nick gorbikoff]

I grock that.

While I'm all for people customizing their apps, I think certain structure should be suggested if not enforced - models, validators, service objects, mailers, .... . I'm getting tired of dealing with people's code where they lump everything into one big fat class that's impossible to read. 

For instance I'm actually surprised that it took Rails so long to come up with Concerns. I think the problem is that there many people getting into development right now ( actually there is going to be a big wave in 2-4 years from now according to some CS professors) who don't have good software design background. Took me a few years to pick up good design principles on my own ( my alma mater  didn't provide a good background in that case unfortunately  ) . Just a small rant here.