I just tried a few experiments and realized the :dispatch? option is broken 
in the latest Immutant release. :(

This is a result of some changes we made to better support WebSockets.

We were already hoping to get a release out this week, so we'll add that to 
the list of fixes.

Sorry about that,
Jim

On Sunday, February 28, 2016 at 1:32:09 PM UTC-5, Jim Crossley wrote:
>
> Hi, 
>
> Luminus uses Immutant, which uses Undertow, so it should be possible 
> to tune the Luminus app to approach the performance of the TechEmpower 
> Undertow app. The relevant options to immutant.web/run [1] are 
> :dispatch?, :io-threads, and :worker-threads. 
>
> The Undertow app sets IO threads here [2] and worker threads here [3], 
> so you can easily set those same values in the Luminus app. 
>
> But the real performance bump will come from the :dispatch? option. By 
> default, :dispatch? is true, i.e. requests handled by threads in the 
> IO pool are dispatched to a thread in the worker pool. For 
> compute-bound tasks like the JSON serialization benchmark, that 
> context switch is far more expensive than just having the IO thread 
> return the response. So you'd want to set :dispatch? to false in that 
> case. 
>
> The tricky bit here is that the Luminus app defines all its routes in 
> a single handler [4]. But for the more io-bound tasks, e.g. 
> DbSqlHandler [5], you'll want the default true value of :dispatch?. So 
> in order to get the best results for all the benchmarks, you'll need 
> to re-organize that app to run two handlers: one that dispatches and 
> one that doesn't. In Immutant, the simplest way to do this is to 
> distinguish each handler with a unique :path option. 
>
> I'm happy to assist whoever is maintaining that app with the tuning. 
>
> Thanks, 
> Jim 
>
> [1] 
> http://immutant.org/documentation/current/apidoc/immutant.web.html#var-run 
> [2] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L122
>  
> [3] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/HelloWebServer.java#L160
>  
> [4] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Clojure/luminus/hello/src/hello/routes/home.clj#L44
>  
> [5] 
> https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Java/undertow/src/main/java/hello/DbSqlHandler.java#L38
>  
>
> On Sat, Feb 27, 2016 at 9:40 PM, gvim <gvi...@gmail.com <javascript:>> 
> wrote: 
> > In the latest round of Techempower benchmarks: 
> > 
> > 
> https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=json 
> > 
> > ... I was surprised to find Luminus performing no better than Hapi 
> (Node) 
> > and significantly worse than Java frameworks. Figures are 
> requests/second: 
> > 
> > FORTUNES 
> > - Hapi:         1.9 
> > - Luminus:   0.9 
> > - Gemini:   55.5 
> > 
> > JSON SERIALISATION 
> > - Hapi:         0.3  (Raw db) 
> > - Luminus:   0.8 
> > - Rapidoid: 78.4 
> > 
> > 
> > SINGLE QUERY 
> > - Hapi:         2.9 
> > - Luminus:   8.7 
> > - Gemini:   75.8 
> > 
> > MULTI-QUERY 
> > - Hapi:           33.0 
> > - Luminus:     20.4 
> > - Dropwizard: 65.8 
> > 
> > DATA UPDATES 
> > - Hapi:        20.9 
> > - Luminus:  20.0 
> > - Ninja:       54.7 
> > 
> > PLAINTEXT 
> > - Hapi:            0.7 
> > - Luminus:      0.0 
> > - Rapidoid:  100.0 
> > 
> > 
> > 
> > Any ideas? 
> > 
> > gvim 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To post to this group, send email to clo...@googlegroups.com 
> <javascript:> 
> > Note that posts from new members are moderated - please be patient with 
> your 
> > first post. 
> > To unsubscribe from this group, send email to 
> > clojure+u...@googlegroups.com <javascript:> 
> > For more options, visit this group at 
> > http://groups.google.com/group/clojure?hl=en 
> > --- You received this message because you are subscribed to the Google 
> > Groups "Clojure" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to clojure+u...@googlegroups.com <javascript:>. 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to