Another claim is that JSGI is far more intuitive, which I consider false. First of all the library does not follow common nodejs idioms, and the configuration also causes the “boomerang effect”, although in the end only the community will decide what they want.
benchmarks generally consisted of testing the Connect middleware loop which invokeshandle()` on each of the layers. Even with the typical “Hello World” benchmark these claims can be quickly disproven, since a simple for loop measures in the microseconds, and has no effect in comparison to ANY real-world application routine.
The following gist contains the test files used. As you can see Connect middleware can easily be used stand-alone and in my opinion feels more natural to implement, where as the JSGI middle is comparably awkward.
Below are the results of
ab -n 8000 -c 50 -k http://dev:8080/ per each server. Funny enough, JSGI actually placed last in the “Hello World” game:
connect: 8859 rps jsgi: 8357 rps node: 9184 rps
OMG JSGI IS SO SLOW.. well no, it is just fine, but so is Connect. We are talking about milliseconds here! ANY call to the database ANY “real” operation will be far more expensive.Response Curve
In my Connect Introduction article the following graph illustrates that Connect has nearly no overhead, as the response curve is almost identical to that of a plain node server.
The truth is, be it Connect, JSGI, fab, or plain old node, none of these will have a profound effect on performance, and can certainly not be considered a bottleneck.
Use what you like! Connect is backed by the all mighty Ext JS team, is licensed MIT until the end of time, and is in development by several node rockstars, it will adapt as the community sees fit, but is already gaining speed.