On Jul 11, 2011, at 6:59 AM, Pedro Melo <melo@simplicidade.org> wrote:
Hi,
On Sun, Jul 10, 2011 at 8:41 PM, Mr. Puneet Kishor <punk.kish@gmail.com> wrote: [...]
So, here I ask the following: the above is working, but is rapidly going to become cumbersome in three regards --
1. It will become tricky keeping track of the port numbers for each app, and make sure they match between what has been set in httpd.conf (for proxy purposes) and what has been used to call in the `plackup` command;
It does. I run about 10 small apps this way, documentation is the only solution I've got.
You could play tricks with $0 to add the port number and the name of the app so that you can easily check with ps but I never felt the need for that.
2. It will become very cumbersome shutting off or restarting one or more Starman app because I would have to find out the parent process of each app, and kill that in order to kill all the child workers; and
Two solutions: the first is the quicker to implement, the second is the variation on the first that I use.
First: Use the --pid option of plackup and give it a very descriptive name, in a well known directory. With that, you can use kill -SIGNAL_NAME `head -1 /path/to/pids/app_descriptive_name` ... You can even use tab completion.
Second: create yet another dancer app :) that lists the pid files directory, and allows you to remote kill the apps. Basically a Dancer-powered web frontend to the previous solution.
Wow! This is a seriously kludgey situation, your suggestions seem like the best way to alleviate this mess somewhat. I guess, in a way, Apache has the same kind of mess, but it must be all under the hood. For me, as a user, I like that I have a single command (apachectl) with which I can start, stop or restart the server.
3. If I have 10 or 20 apps on the same server, with 10 Starman workers for each app, I would have 100 or 200 perl processes running on my computer even if my apps are really low traffic. I tried setting the number of workers to 2 or 2, but found that the server started dropping connections. Is having so many perl processes running not problematic?
Depends on the memory available and the load each app will have. You could start less workers (2 or 3) per app, monitor their usage and increase those who need that (make these values parameters on you config file, for example).
Well, it was not the memory usage that was/is a problem right now. At this time I have only a few Dancer apps, but they are going to grow to about 10 or a dozen or so. Right now, the problem I experienced was that when I started Starman with only two workers, it would simply drop every other connection. If I kept on hitting the refresh button on the browser, every other connection would croak. Increasing the number of workers fixed this. This tells me that perhaps the minimum realistic number of workers might be between 5 and 10, even for low traffic web sites. Which means that with 10 or so apps, I will have 50 to a 100 Perl processes running concurrently on my computer.
I believe starman preloads the app so most of the memory will be shared between workers.
I could be wrong, but the way I understand Apache to work is that it will start a few workers, and then fork a new child for every incoming connection. So, even with 10 apps, it would not have more than a dozen or so child processes. In any case, no matter how many there are, they can be easily controlled by a single apachectl invocation. I am liking Starman for now, and it is kinda like mod_perl in its persistence, but I am also discovering a new-found appreciation for Apache.