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. There are extra stuff that you can do if you reallly have lots of apps, like having an extra config file per app and a script that takes care of starting plackup with all the proper parameters based on that config file. You could even generate the apache/nginx reverse proxy config from the same file, to make sure the port always matches. I did that for a client...
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). I believe starman preloads the app so most of the memory will be shared between workers. Bye, -- Pedro Melo @pedromelo http://www.simplicidade.org/ http://about.me/melo xmpp:melo@simplicidade.org mailto:melo@simplicidade.org