[dancer-users] single-threaded

[Warren Young]

On Nov 24, 2015, at 12:29 PM, Warren Young <wyml at etr-usa.com> wrote:
> 
> Try this: create environments/single-threaded.yml, with the “simple" web server and session manager.  Put it behind a proxy server, then run a concurrent web benchmark against it.  I use Siege[*], and it just gave me a concurrency value of 36.60 on my app here.  

Scratch that.  I was misinterpreting what “concurrency” means in Siege reports.  36.6 doesn’t mean 36.6 simultaneous transfers, it means 36.6 conns were blocked at a time on average.  High concurrency is a bad thing, not a good thing.

But that test result was bogus because I was using old invalid test data.  On regenerating the URL list that Siege uses to be valid for my current web app, a Siege run with 25 concurrent connections gives a concurrency < 1.  That means that even though the dynamic part of the app is single-threaded, on average, clients *never* had to wait for service, even though there were 25 simultaneous conns all trying to pull data at once.

The answer to “why?” is as before: because most of the URLs are handled by the reverse proxy server, not by the Perl web server underneath it.

Realize that testing with 25 Siege users is equivalent to many times that many real users, since Siege runs through the URLs as fast as possible.  Unlike a human, it doesn’t take time to read the generated web page, think about it, and move the mouse to the next clickable thing.

I encourage you to try the same test on your app.  Run it multi-threaded with a reasonable number of Siege conns, then switch it to single-threaded and retry.

I should point out that my single-threaded app uses the “simple” session manager, which means sessions are held in RAM, and are accessed without locking.  This is very fast, but means all sessions disappear when the Dancer app restarts.  That’s fine for my app, but might not be appropriate for all.