On Oct 30, 2015, at 9:03 AM, WK <[email protected]> wrote: > > 2015-10-30 15:04 GMT+02:00 Joerg Fallmann <[email protected]>: >> Thanks for the very fast reply, >> I switched from Session::Simple to Session::Cookie and it works fine. >> No need for me to keep sessions without cookies. > > Pretty sure Session::Simple uses cookies too.
It does. > Session::Simple ... > is not meant for production. That’s only true if “production” means a cluster of computers, or if you need sessions to survive a restart of the Dancer app. If you never need to scale beyond a single computer, and it’s fine if restarting the Dancer app logs everyone out, Session::Simple not only works fine, it’s faster than the alternatives because you don’t have the I/O overheads associated with the more complicated mechanisms. > And I think, it had some bugs too. It’s working fine for us. Maybe you’re referring to the fact that it’s essentially single-threaded, which means you have to use it with a single-threaded HTTP server on the Dancer side. (e.g. HTTP::Server::Simple::PSGI instead of Starman.) This is also fine for smaller applications, since you get plenty of parallelism by proxying static assets with something like nginx. It does mean dynamic page hits choke down to a bottleneck, but in many web apps, that’s only one out of every hundred hits or so. A site that can be served from a single server might in fact never bottleneck this way in practice, since most of its clients will be idle, so that there is only ever zero or one dynamic page requests in progress at any given time. The rare cases where two or more dynamic page requests come in at a time are not worth optimizing; let the second wait until the first is finished. This does assume each Dancer transaction finishes quickly. It might not be practical if you’re doing something with WebSockets, for example. _______________________________________________ dancer-users mailing list [email protected] http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
