> Nice that you are working on increasing the control of environment > resources. However I think this is a step back as in normal > circumstances you'd wouldn't want an environment to completely stop if > they use "too much" CPU as you'd risk the processor being idle > instead, wasting CPU cycles. Instead, I think this should be > implemented by a nice level setting which should be supported by all > kernels. The nice level basically sets the priority of the threads, so > if one environment is running with a lower nice level, it will get > more CPU time if it currently competing with another environment that > has a higher nice level. This is basic CPU time resource management > and prevents idle cycles.
It doesn't stop an entire environment, it stops only the child that uses more than MaxCPUUsage. I believe that should be easy modify this code to work on Linux, all we need is change cpu_usage_pid() to read /proc. Nice Level doesn't work for very bad scripts (e.g. bad Joomla extensions or crazy Wordpress plugins). > Also, I have another feature suggestion. The biggest hurdle for me is > controlling the RAM actually. One of the problems with using PHP as an > apache module is basically that the apache childs suddenly consumes > 10-40x more memory after they have handled a PHP request. This > wouldn't be a problem is it wasn't for the fact that childs where > randomly assigned PHP requests so if you're not closing down childs > almost instantly after they have started, you'd end up with a bunch of > childs, each allocating a big chunk of memory while just idling. I'd > really want to be able to specify that incoming PHP requests should be > directed to children that have already handled PHP requests and are > now idling. E.g. if the incoming request is a PHP request, it should > first check if there are idle children that has not handled a PHP > request, and it should only pick another child if no such child is > available. Likewise, for all other requests, it should pick alive > "other children" first, and idle previous PHP handlers secondary. So > you'd have a "A-B Priority" where "if you get an A request, 1: use > idle A children 2: use idle B children, 3: start a new A child, **if > you get a B request: 1. use idle B children 2. use A children which > are "dirtied" to become B children 3. start a new B child". This > option could be controlled like this: > > AlphaBetaRouting On > BetaHandlers application/x-httpd-php application/python > > These options would be set on server level and processor level. Beta > handlers is basically a list of request "types" or "handlers" that is > used to identify "beta requests" that are first-hand assigned to "beta > dirtied children". This would be a bit difficult to implement on peruser. Today, multiplexers receives the connection and decides which processor will handle the request. A multiplexer doesn't know if the last processor request was a static file or not, so peruser would have to implement 2 different processors for each environment, 2 different listening sockets, et cetera. You can use nginx (KeepAlive On) to serve static files and forward all PHP and Python requests to Apache (KeepAlive Off). > > An extended feature of this would also set a limit on how many beta > handlers a server/processor can have. An overloaded search.php script > would then be unable to block access to other static files. There > could also be request time limits on beta requests. For example, I > don't want PHP/Python/etc scripts of my customers to run more than 30 > seconds. But downloading big files is no problem, a A child can be > locked up with that for hours as they don't consume much resources by > being alive anyway. A PHP script can be a download script that needs more than 30 seconds. _______________________________________________ Peruser mailing list [email protected] http://www.telana.com/mailman/listinfo/peruser
