[dancer-users] blocking

[John Stoffel]

David> If 10 people visit my page at the moment, and the page has to
David> retrieve database/memcached info for the 10 people, and it
David> takes 1 second to do all the pre-work to load the page, then
David> each of those requests for each person, is done separately,
David> taking a total of 10 seconds for the last person to retrieve
David> their data, since it has to wait for each other process to
David> finish before attending to the next person.

So... isn't this an issue that you alluded too earlier, that starman
doesn't seem to be forking properly?  If you have starman in front,
handling the initial connections and it should be forking off copies
to handle the work, right?

So for each connection, there would be a seperate instance of Dancer
(ideally already in Starman, compiled and ready to roll...) that would
be doing the work of those 10 connections.  And this assumes that your
database/memcached can handle those 10 connections in parallel as
well.

It looks like you need to do the '--preload-app' switch though to make
starman be more performant for you.  You don't really explain how you
setup your tests in starman, so it's hard to know.   And it's also
hard to know where the (user visible) slowdown is happening.

If you do your simple example below, and have starman run it, and put
it under test with 'siege' (or any other load testing web tool) to do
requests in parallel, how well does it work? 

I'm probably missing the entire point here, but happy to learn new
things.  


David> At a basic level in nodejs, you do this (as an example):

David> router.get('/', function (req, res, next) {
David>    Post.find(function(err, Patients) {
David>     if (err) { return next(err) }
David>     res.json(People)
David>    },'Firstname Surname')
David> })

David> And although this is per session blocker in node, it still allows other sessions to continue.
David> I want to know how to achieve this or a similar effect in Dancer2. Or, do I just look at it as an
David> issue with Perl and solve it through something like AnyEvent::Util::fork_call

David> David

David> On Wed, Nov 18, 2015 at 12:32 AM, Rick Leir <richard.leir at canadiana.ca> wrote:

David>     On Tue, Nov 17, 2015 at 7:00 AM, <dancer-users-request at dancer.pm> wrote:

David>             delayed {
David>               my $TextToWrite = ReturnText();
David>               sleep(10); # Do something that takes a few seconds
David>               content "$TextToWrite";
David>               done;
David>            };
   
David>     The sleep call will always cause blocking, even a sleep(0). Likewise a flush. In the sense
David>     that there is a context switch to some other thread or process. 
   
David>     How are you testing whether it is blocking? Sorry, I do not know what you are trying to do.
   
David>     Linux will not schedule a cpu intensive task to the exclusion of I/O. You can affect its
David>     scheduling using nice:
David>     http://stackoverflow.com/questions/2012852/control-a-perl-scripts-cpu-utilization
   
David>     If you really want nonblocking then you can look at nice for io
David>     http://linux.die.net/man/1/ionice
David>     or spawn a C program with pthreads and freeze your screen!
David>     cheers -- Rick

David>     _______________________________________________
David>     dancer-users mailing list
David>     dancer-users at dancer.pm
David>     http://lists.preshweb.co.uk/mailman/listinfo/dancer-users

David> _______________________________________________
David> dancer-users mailing list
David> dancer-users at dancer.pm
David> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users