[Express-js] performance and routing

[Christoph Jasinski]

Hi 

While building a "big" express app, I just wonder how fast the app would be using the MVC-pattern. So I profiled (with old good ab) the app and saw pretty bad performance. I wondered whether the MVC-pattern was the problem. Next I went through some examples from the express repo and founbd the following (it wasn't very scientific):

• application following mvc did X req/sec (which was in my eyes pretty slow - it might be ejs. But I did jade too)
• application following route-seperation did almost 2*X
• application with plain old routes inside app.js (or the main file) having layout+partials almost 4*X

Is it me doing something wrong or are these just facts? Which would mean that I would put all logic/routes in one file although that's pretty ugly when doing big apps.

Any hints help is welcome. It was all profiled while running under NODE_ENV=production.

Cheers,

Chris

[Oleg Slobodskoi]

hi, can you publish your code for this tests?

2011/3/29 Christoph Jasinski <christoph...@googlemail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "Express" group.
> To post to this group, send email to expre...@googlegroups.com.
> To unsubscribe from this group, send email to
> express-js+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/express-js?hl=en.
>

--
regards,
Oleg Slobodskoi
--------------------------------------------------------------------
Xing: https://xing.com/profile/Oleg_Slobodskoi
Twitter: https://twitter.com/oleg008
Github: https://github.com/kof

[vision media [ Tj Holowaychuk ]]

numbers would help me know if what you are seeing is expected or not

--

You received this message because you are subscribed to the Google Groups "Express" group.
To post to this group, send email to expre...@googlegroups.com.
To unsubscribe from this group, send email to express-js+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/express-js?hl=en.

--
Tj Holowaychuk
Vision Media
President & Creative Lead

[Oleg Slobodskoi]

in generall resource based routing ala mvc should not be slower,
because after first request all modules should be cached if you doing
it right.

2011/3/29 Christoph Jasinski <christoph...@googlemail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "Express" group.
> To post to this group, send email to expre...@googlegroups.com.
> To unsubscribe from this group, send email to
> express-js+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/express-js?hl=en.
>

--

[vision media [ Tj Holowaychuk ]]

The reality is people benchmark node with only I/O, say transferring a small file, and think wow it's so fast. Then they

try rendering a template per request, and all of a sudden it looks slow, because it's a single thread and the template work is performed

100% in this single thread. When it comes to this fact, node is not necessarily faster than anything else out there, although v8 is heavily optimized, it's still just a programming language like any other

[Joshua Cohen]

Hey, on the bright side, I'm getting 500+ req/s (ab -n10000 -c200) on a page doing real work (multiple mongodb lookups, much rendering). This was running under Cluster w/ 4 processes, NODE_ENV=production. This was more than 4x what I was seeing on a dual core (so 2 processes) system. So yes, running a single process under load is not going to scale all that well, but if you run multiple processes things look pretty good from where I'm sitting ;).

[vision media [ Tj Holowaychuk ]]

most my "real" stuff ends up getting around ~1200 rps for a single process, which is still great considering when I did php/drupal stuff with agressive page cache I maybe got 800, with regular cache maybe 300, and without cache ~30 haha

[Christoph Jasinski]

Hi

My benchmark was done on my little netbook (Intel Atom N270). I remembered that rendering a simple site using express was very fast the other day (node was at version 0.2.X at that time). Given my memory is working correctly, I remember performance like 800-1200  req/sec rendering something (not IO in all cases mentioned here - file transfer). So when I benchmark a route from my express app (node=v0.4 and express=v.2.X) I was expection (even on slow CPU) a lot of request. As a ruby developer I know that sinatra would render that much on my machine. So anyway node and express are fast. I don't blame express or node for beeing slow. Which I meant relative to "normal" node performance. And as I mentioned my benchmark wasn't very scientific.

As I plan (and already started) a "big" app and want to have the code to be somehow not in a single file, I was wondering which MVC-style in express would have the best performance result. You can do routes in 3 different ways (as far as I see it though express examples).

(1) the classic : express/examples/mvc

(2a) alternative: express/examples/routes-seperation / (2b)route-middleware

(3) all I the "main" file

So I went to each of the above examples and ran it in production mode and apache benchmarked it "ab -n 1000 -c 50 ...."

Number (1) and (2a) both have a layout and a view they render in ejs. So that equal in both. But in my case (maybe I did something really wrong) I got ~280 req/sec for (1) and ~500 req/sec which I found weird, as I think that in both cases the routes/controllers are

 red and set once. When doing (2b) it gives me 650 req/sec while profiling (3) I got something around 850 req/sec. 

So to me the choice would be to take either (2b) or (3) if I think I'm the next "Facebook" ;)

Personally, I don't think that console.log is slowing that thing that much, although in production most examples are not verbose about that. Am I "profiling" wrongly? I know it's not really scientific, just hypothetically dirty. And I know somtimes it's ejs and sometime jade. But am I right that it really matters how you define your routes (main file, controller, route files, ... )

Thanks and cheers,

Chris

  

2011/3/29 vision media [ Tj Holowaychuk ] <t...@vision-media.ca>

[vision media [ Tj Holowaychuk ]]

it depends on a lot of things, for example even using connect's logger() will generally shave ~2500 rps off, because, it's doing stuff lol there is a buffer option for example which will speed that up, and options for most the middleware that will help, so it really depends. 0.4.x in my experience has been slower than node 0.2.x though

[Christoph Jasinski]

Thanks much for the feedback. Just out of curiousity I check some things on my netbook. 

Profiling the simplest express app with nothing except one route ('/') which sends back a short string had served something around 880 rqs/s. So that's the limit.

Would be interesting to compete with ruby's sinatra. So I created a small sinatra app which also renders a string and returns it. The best result I got in production mode was 305 rqs/s. So that's was only a string interpolation. I have no idea how that number would drop if I would render a layout an a view. 

So to summarize it. express/node is way-way faster than sinatra is. But there IS a (maybe big) performance difference how you manage the routes in your app. Nevertheless, express beats everyone, just like Chuck Norris. But keep the routes in mind.

Havn't tried cluster yet. Seems very promising. But when you routing on a single process is already 4X faster than normal, it would speed up the cluster too.

[Christoph Jasinski]

Now another question.

Did anyone ever thought about splitting an app into small applications?

Suppose we have a blog, hypothetically that would be a post, comment, user and core part.

Would it make sense to have (internally) a little users app and a posts/comments app, and a core app which redirects/forwards the call to the proper app?

Cheers,

Chris

2011/3/30 Christoph Jasinski <christoph...@googlemail.com>

[Oisin Hurley]

On Wednesday 30 March 2011 at 05:54, Christoph Jasinski wrote:
So to summarize it. express/node is way-way faster than sinatra is. But there IS a (maybe big) performance difference how you manage the routes in your app. Nevertheless, express beats everyone, just like Chuck Norris. But keep the routes in mind.

This result shows that express is way faster than sinatra for a single
route that just echoes a string :) Probably not a result you could make
a technology choice on... bear in mind that if you are looking for
performance in a real application, you may decide to stick a memcache
in there, or if you are doing an API-only server, you will be load-balancing
it thru a queue system - so there are usual more moving parts that need
measuring.

> Havn't tried cluster yet. Seems very promising. But when you routing on a single process is already 4X faster than normal, it would speed up the cluster too.

Putting in a cluster will require the kind of caching and queuing I mention
above. Don't forget that if you have data persistence in the backend that
is going to add a performance hit.

So - you have to make a choice, but you don't have time to make
the kind of system that you need to measure to be accurately informed
about the choice - this happens to everyone - all you can do are look
at what's out there already and see how it goes for them

Here's an article on the Exceptional product's architecture, which I
found pretty cool, and it might be interesting for you to check out.
Interestingly, there's a note there about maybe moving to node.js
at some point...

http://blog.getexceptional.com/post/976830048/some-notes-about-our-new-api-implementation

cheers
--oh

[Christoph Jasinski]

But when a framework is slow in rendering a string, then it will not be a performance hero while rendering a layout and view instead ;)

Cheers,

Chris

2011/3/30 Oisin Hurley <oisin....@gmail.com>

--

[Oisin Hurley]

> But when a framework is slow in rendering a string, then it will not be a
> performance hero while rendering a layout and view instead ;)

Just saying you can't extrapolate from a string echo to a whole scalable
app. Neither can you even extrapolate from echoing a string to rendering
a layout/view -- the rendering code might be jet fast in the slow string
echoer and a dog in the fast string echoer :)

TJ did some of this kind of stuff in an oldish blog entry at

http://tjholowaychuk.com/post/543953703/express-vs-sinatra-benchmarks

which shows that your expectation of express.js being much better at
responses is pretty solid when you make it more realistic, i.e. including
haml/sass ports. There's yer proof ;)

cheers
--oh

[TJ Holowaychuk]

That benchmark is months and months old, I believe with node 0.1.x

-- 
TJ Holowaychuk
Sent with Sparrow

[Oisin Hurley]

On Wednesday 30 March 2011 at 16:30, TJ Holowaychuk wrote:
That benchmark is months and months old, I believe with node 0.1.x

11 months old, in fact. I think my point was that the blog entry
contained a better exemplar of how to go about doing performance
comparisons...

Did you keep the code for the test around by any chance? I'll
volunteer to bring it up to date and run with the latest versions
of stuff.

--oh

[TJ Holowaychuk]

unfortunately not, I had a script in express, then moved it to connect, and then removed

it all together because it required quite a few dependencies to run correctly

-- 
TJ Holowaychuk

[Christoph Jasinski]

Sorry it was this.fault || Self.fault
Haven't seen the logger. So MVC is bringing 480 rqs/s that awesome. Thanks guys.

Chris

On Wednesday, March 30, 2011, TJ Holowaychuk <tjholo...@gmail.com> wrote:
>
>
> unfortunately not, I had a script in express, then moved it to connect, and then removedit all together because it required quite a few dependencies to run correctly