1

For some reason I could not find an answer to the question below, probably because it is just too obvious.

During my experiments with perl dancer, I added a route, which just sleeps for 10 seconds and then returns something. I did this in order to simulate a long-running operation. I noticed, that during these 10 seconds, dancer would not serve any other request. I understand that this is because dancer is single-threaded.

Now this single-threaded approach is obviously not suitable for even mildly demanding applications. So I believe there must be a nuber of established solutions. But I just don't seem to know the right search strings to google for.

To make things clear: I don't mind, when the reqest which initialted the long running operation itself gets blocked. What I want is that all other requests are sill being served.

Could anybody please enlight me in terms of

  • How do webservers traditionally handle long-running operations, without blocking other requests ?
  • Will there be threads/processes for each session, or can threads/processes be spawned on-demand, in situations, where I know the operation will take a long time
  • How is session information preserved when going multi-threaded, i.e. when a browser does not always talk to the same process?
  • Any particulat recommendations concerning dancer (feel free to recommend an alternative to dancer)
Martin Drautzburg
  • 5,143
  • 1
  • 27
  • 39

1 Answers1

2

  • This will depend on the web server and the underlying operating system - there is an answer on SO here in relation to Apache httpd here: What is Apache process model?

  • Note that 'out of the box' Dancer uses HTTP::Server::Simple which is single threaded, however, that is not the only option. See https://metacpan.org/module/Dancer::Deployment for a range of Dancer deployment options starting with Apache CGI which will provide concurrency for your web server. If you are working on *nix environments spawning a detached process will be easy - and harder but possible on Win32 - but you may need to send your results back to the client by some other mechanism than an http response (such as STOMP or websockets). Another approach is to spawn a separate long running process from the Dancer route, immediately return some lookup key to the client in that route, and then have the client poll on another route for completion of that process. Maybe the answer to this is that you need a web server in front of Dancer that can handle concurrent requests.

  • Your browser will store session information in a cookie and Dancer will store corresponding session information on the server and Dancer will match these up. This doesn't answer the third question except to say don't worry about it.

  • If Dancer is supporting all of your needs except for the concurrency / long running process issue then it sounds like reading up on your web server deployment options: https://metacpan.org/module/Dancer::Deployment might solve your problems. Note that as before if you are on a *nix environment you will have more options in terms of Perl based concurrent web servers but I am confident the problem can also be solved on Windows. We completed a proof of concept of this using IIS + FastCGI.

Community
  • 1
  • 1
Ross Attrill
  • 2,594
  • 1
  • 22
  • 31