Should embedded mode be disabled by default in mod_wsgi 3.0?
Graham Dumpleton
posts, is that although they use WSGIDaemonProcess to have a daemon
process created, they don't use WSGIProcessGroup to ensure that WSGI
application actually runs in it. Instead what happens is that it runs
in embedded mode. They either are oblivious that they have got it
wrong, or don't understand why it is still taking too much memory.
There already is a WSGIRestrictEmbedded directive in mod_wsgi 2.X
which allows one to disable the ability to have a WSGI application run
in embedded mode. That is, you must have
WSGIDaemonProcess/WSGIProcessGroup correctly setup. If you do not, you
will get a 500 error and message in the Apache error logs of:
Embedded mode of mod_wsgi disabled by runtime configuration
I was already intending to have mod_wsgi 4.0 disable embedded mode by
default, but now thinking of doing this earlier in mod_wsgi 3.0.
The overall intent of this is to discourage people using embedded
mode, especially when they have no clue about setting up Apache, and
encourage them to use the safer option of daemon mode.
I accept that I may have to make that error message which appears in
the logs more descriptive/prescriptive, but still think doing this
would be the best.
BTW, this doesn't apply to Windows or Apache 1.3 where embedded mode
is the only option.
Comments?
Graham
Michael Schurter
I would prefer embedded mode to be disabled by default. It seems like
a very useful option for people who know what they're doing and have a
very specific environment thats well suited for using embedded mode.
My guess is the vast majority of modwsgi users only ever want daemon
mode, and those who want embedded mode will know how to configure it.
But thats just IMHO and a wild guess at that. :-)
gert
wrote:
>
newbies (90%) that actually want to run in i don't care mode and don't
get there first page displayed because embedded mode is disabled by
default ?
Suggestion is simple the WSGIDaemonProcess it self disables embedded
mode, and you can re enable it if your 'really' know what you are
doing.
Graham Dumpleton
I'll admit that that is an interesting idea, but in itself dangerous.
If someone has an existing site running under embedded mode and they
decide to add a new application running in a daemon process, there
main site will stop working and they will not know why.
As for the newbies, this is why the error message in the Apache error
logs has to be better. Ie., something like:
"""Embedded mode of mod_wsgi disabled by runtime configuration.
Configure use of a daemon process using
WSGIDaemonProcess/WSGIProcessGroup directives, or enable embedded mode
using the WSGIRestrictEmbedded directive."""
Graham
gert
wrote:
> 2009/3/12 gert <gert.cuyk...@gmail.com>:
wrong, now way they are going to look in log files.
On the other hand one who already is capable of setting up embedded
mode first, and going to daemon mode, will likely find out pretty
quick embedded mode is disabled. Combining this with a message in the
log files that say's disabling embedded mode when the daemon starts
up. Not a single one will complain about it.
Graham Dumpleton
Returning a custom 500 HTML page is not unreasonable and could be considered.
In general have avoided doing that. I was setting Apache error-notes
with details of error, but that only shows up in standard error page
if multingual error documents enabled in Apache. Plus no longer set
error-notes in mod_wsgi 3.0 due to risk of information about system
setup being exposed.
Graham
gert
a) Custom 500 page that clearly tells instructions to enable embedded
mode in every language on the planned.
or
b) WSGIDaemonProcess disables the embedded mode, witch makes mod_wsgi
look very intelligent and easy to use without displaying annoying
error messages who newbies have no idea what the hell embedded mode
disabled means :-)
Chris Miles
+1 for same reasons.
Defaults should be best practice for the common case. Advanced users
with special cases can learn how to enable embedded mode and tune
Apache as required.
Bring it forward to mod_wsgi 3.0. Hell, Debian still won't supply 3.0
for a few more years, given their current form...
Cheers,
Chris Miles
Nimrod A. Abing
<graham.d...@gmail.com> wrote:
>
> A mistake I often see people making based on irc logs and some blog
> posts, is that although they use WSGIDaemonProcess to have a daemon
> process created, they don't use WSGIProcessGroup to ensure that WSGI
> application actually runs in it. Instead what happens is that it runs
> in embedded mode. They either are oblivious that they have got it
> wrong, or don't understand why it is still taking too much memory.
>
> There already is a WSGIRestrictEmbedded directive in mod_wsgi 2.X
> which allows one to disable the ability to have a WSGI application run
> in embedded mode. That is, you must have
> WSGIDaemonProcess/WSGIProcessGroup correctly setup. If you do not, you
> will get a 500 error and message in the Apache error logs of:
>
> Embedded mode of mod_wsgi disabled by runtime configuration
The problem lies in the default settings for these directives:
For prefork:
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
For worker:
StartServers
MaxClients
MinSpareThreads
MaxSpareThreads
ThreadsPerChild
MaxRequestsPerChild
As stated elsewhere in this group, the defaults from an out of the box
Apache configuration are good for static and CGI-generated content.
Maybe you just disable embedded mode if the values for the above
directives make for less than optimal performance.
Better if you leave embedded mode alone but put minimum recommended
values for the above directives in the Quick Configuration
documentation. Maybe even add a distinct section on Performance
Tuning. Don't get me wrong, documentation is excellent for mod_wsgi
but in most cases people would just like to get it up and running as
quickly as possible without wading through several pages of docs.
--
Best Regards,
Nimrod A. Abing
W http://arsenic.ph/
W http://preownedcar.com/
W http://preownedbike.com/
W http://abing.gotdns.com/
Jorge Vargas
it is the "slowest" of them all. "I don't care mode" should be the
*optimal* configuration for a fast response from the wsgi app.
speaking from the newbies perspective (which is different than the 90%
IMO), if it *just works* the first time you load it it should be the
best software in the planet.
> Suggestion is simple the WSGIDaemonProcess it self disables embedded
> mode, and you can re enable it if your 'really' know what you are
> doing.
so yes I kind of agree, if you are having conflicting directives in
your config file, mod_wsgi should fail to load, it's the only way to
make people (with broken configuration realize it's their fault and
not apache/mod_wsgi) that their site is slow. Sadly the average joe
won't read the log file, until pointed at it.
Graham Dumpleton
While we are having this discussion, I have made some changes and we
will see who screams first. That of course presumes one is using
mod_wsgi from trunk. I am pretty sure I know who it will be. :-)
Anyway, obviously, disabling embedded mode by default means that
without specifically setting up WSGIDaemonProcess/WSGIProcessGroup,
which many will not do, they are going to get an error on the first
try. This isn't going to be very welcoming. At the same time though,
nothing works with fastcgi without configuration either.
One option is that when embedded mode is disabled and no
WSGIDaemonProcess has been defined, that a default daemon process is
automatically created, with everything routed through to that. That
way everything would work and they wouldn't be the wiser that it
wasn't running in embedded mode. Only issue would be that to make is
perform reasonably, would have to be a multithreaded process which may
cause some code to not work if not multithread safe.
Doing that may be a bit too magic though as it hides what is
happening. Thus, best compromise may be the descriptive HTML error
page, although in general I don't like doing that as it exposes
details about what the server is running, which some people may not
want. But then it is only going to happen in a case where not
configured properly.
Graham
Graham Dumpleton
The other option is I do defer this to mod_wsgi 4.0 again like had
originally intended. Any solution then can tie in with the plan to add
support for transient daemon processes.
http://code.google.com/p/modwsgi/issues/detail?id=22
There could be a default rule setup where by if nothing explicitly
done, then an on demand daemon process created for each
virtualhost:port combination. If multiple WSGI applications mounted
for host, then they just run in separate sub interpreters as like they
do in embedded mode anyway.
Still have the issue of probably wanting only a single multithread
process. Possibly also want to have a default inactivity timeout set
so process is shutdown when not in use for a while.
Actually, I am started to like this idea and so can see some sense in
not disabling embedded mode in mod_wsgi 3.0 since the fallback if
transient daemon processes available much better.
Graham
Graham Dumpleton
Or finally, I just take a bit longer with mod_wsgi 3.0 and implement
transient daemon processes now.
I would just need to make sure I give some added priority to get
mod_wsgi 2.4 bug fix version out.
Graham
Lukasz Szybalski
On Mar 12, 12:49 am, Graham Dumpleton <graham.dumple...@gmail.com>
wrote:
> 2009/3/12 Graham Dumpleton <graham.dumple...@gmail.com>:
>
>
>
> > 2009/3/12 Jorge Vargas <jorge.var...@gmail.com>:
mode comes kind of from the docs. I don't know if the've changed but
initially when I was looking at them they recommended using the
embedded mode as default and optional daemon mode. I think if this was
reversed in documentation then most people would start using modwsgi
as a daemon mode first and then if they get familiar switch to
embedded mode.
That was my experience with it.
Thanks,
Lucas
Michael Schurter
> On Wed, Mar 11, 2009 at 8:29 PM, gert <gert.c...@gmail.com> wrote:
>> On Mar 12, 12:23 am, Michael Schurter <michael.schur...@gmail.com>
>>> <graham.dumple...@gmail.com> wrote:
>>> > Comments?
>>>
>>> I would prefer embedded mode to be disabled by default. It seems like
>>> a very useful option for people who know what they're doing and have a
>>> very specific environment thats well suited for using embedded mode.
>>> My guess is the vast majority of modwsgi users only ever want daemon
>>> mode, and those who want embedded mode will know how to configure it.
>>>
>>> But thats just IMHO and a wild guess at that. :-)
>>
>> Disabling it would have a major flip coin problem, what about the real
>> newbies (90%) that actually want to run in i don't care mode and don't
>> get there first page displayed because embedded mode is disabled by
>> default ?
>>
> speaking from the 90% perspective. "I don't care mode" is dangerous if
> it is the "slowest" of them all. "I don't care mode" should be the
> *optimal* configuration for a fast response from the wsgi app.
"Fastest" != "Optimal" For many people ease of administration and
number of features is far more important than a small increase in
requests per second. If you really think "faster is better" I'm not
sure why you're using Python to begin with. :) There are definitely
"faster" platforms out there.
Michael Schurter
> I think from a new user perspective the confusion of using embeded
> mode comes kind of from the docs. I don't know if the've changed but
> initially when I was looking at them they recommended using the
> embedded mode as default and optional daemon mode. I think if this was
> reversed in documentation then most people would start using modwsgi
> as a daemon mode first and then if they get familiar switch to
> embedded mode.
>
> That was my experience with it.
Agreed. For better or worse, most people just copy & paste the
modwsgi setup instructions for their application and only return to
the docs when something doesn't work as they expect.
So instead of changing code, you could just change the docs.
Michael Schurter
gert
wrote:
> 2009/3/12 Jorge Vargas <jorge.var...@gmail.com>:
the even better news is that i don't see custom html pages because
when i thought about it, hard coded html output would have been a
really bad idea in any case newbie or not.
the bad news is WSGIDaemonProcess doesn't disable jack ****
<VirtualHost 127.0.0.2:80>
WSGIDaemonProcess www.site1.net python-path=/usr/httpd/www/appwsgi/
www/lib user=www group=www processes=1 threads=25
WSGIProcessGroup www.site1.net
WSGIApplicationGroup %{GLOBAL}
ServerAdmin gert.c...@gmail.com
ServerName www.site1.net
DocumentRoot "www1"
ErrorLog logs/www.site1.net
LogLevel info
<Directory />
Options ExecCGI Indexes FollowSymLinks
DirectoryIndex index.htm
IndexIgnore .??*
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>
PS also my apache doesn't like Listen 81 127.0.0.1:81 or *:81 i had to
use 127.0.0.2 to create a second host ?
gert
> ServerNamewww.site1.net
> ErrorLog logs/www.site1.net
> LogLevel info
> <Directory />
> Options ExecCGI Indexes FollowSymLinks
> DirectoryIndex index.htm
> IndexIgnore .??*
> Order Deny,Allow
> Allow from all
> </Directory>
> </VirtualHost>
>
> PS also my apache doesn't like Listen 81 127.0.0.1:81 or *:81 i had to
> use 127.0.0.2 to create a second host ?
wrong :-)
[Thu Mar 12 21:07:32 2009] [info] [client 217.136.53.252] mod_wsgi
(pid=13645, process='www.site1.net', application=''): Loading WSGI
script '/usr/httpd/www1/hello.wsgi'.
Shouldn't this look different ?
root 10721 0.0 1.4 9492 6616 ? Ss 20:27 0:00 /usr/
httpd/bin/httpd -k restart
www 13645 0.0 1.2 230720 5948 ? Sl 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13674 0.0 1.5 18904 7240 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13675 0.0 1.5 18880 7088 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13676 0.0 1.1 9492 5600 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13677 0.0 1.2 9644 5980 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13678 0.0 1.5 18904 7232 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13679 0.0 1.4 18880 7068 ? S 21:07 0:00 /usr/
httpd/bin/httpd -k restart
www 13975 0.0 1.2 9632 5844 ? S 21:12 0:00 /usr/
httpd/bin/httpd -k restart
Graham Dumpleton
>> While we are having this discussion, I have made some changes and we
>> will see who screams first. That of course presumes one is using
>> mod_wsgi from trunk. I am pretty sure I know who it will be. :-)
>
> the good news is embeded mode is NOT disabled by default... alleluia
That is because I reverted the change. Everything should be how it was before.
Graham
Graham Dumpleton
Wiki documentation still need a major overhaul, but perhaps marginally
better now that there is the quick configuration guide.
The problem with making the first example use daemon mode is that it
will not work on Windows or Apache 1.3 Thus had avoided it and just
gone with what would at least work on all platforms.
Graham
gert
WSGIDaemonProcess www.site1.com user=joe group=joe processes=2
threads=25
WSGIDaemonProcess www.site1.com user=joe group=joe processes=2 threads=
%{TRANSIENT}
WSGIDaemonProcess www.site1.com user=joe group=joe processes=%
{TRANSIENT} threads=25
WSGIDaemonProcess www.site1.com user=joe group=joe processes=%
{TRANSIENT} threads=%{TRANSIENT}
Graham Dumpleton
If you mean changing the number of processes and/or threads in a
process group dynamically, much the same way that Apache does for
processes in worker/prefork MPM, the answer is no. Part of the reason
why daemon mode works well is that things are fixed. The dynamic
nature of things in embedded mode is the cause of unexpected memory
usage and load spikes as I recently blogged about.
The only measure of scaling back would have is that with on demand
created processes, inactivity timeout would shutdown the process but
not start it up again automatically, only being started when
subsequent request arrives.
Dynamically creating external threads may also cause problems with
accumulation of thread local data in Python. I'll have to actually
check what happens on winnt MPM as it already dynamically creates
threads from memory and so may already have this problem. :-(
Anyway, perhaps explain better what you are talking about.
Graham
Graham Dumpleton
No, I am safe. Number of threads per generation is fixed even on winnt MPM.
Graham
gert
wrote:
> 2009/3/13 gert <gert.cuyk...@gmail.com>:
> > suggestion to make more resourceful :-)
>
> > WSGIDaemonProcesswww.site1.comuser=joe group=joe processes=2
> > threads=25
> > WSGIDaemonProcesswww.site1.comuser=joe group=joe processes=%
> > {TRANSIENT} threads=25
>
> If you mean changing the number of processes and/or threads in a
> process group dynamically, much the same way that Apache does for
> processes in worker/prefork MPM, the answer is no. Part of the reason
> why daemon mode works well is that things are fixed. The dynamic
> nature of things in embedded mode is the cause of unexpected memory
> usage and load spikes as I recently blogged about.
>
> The only measure of scaling back would have is that with on demand
> created processes, inactivity timeout would shutdown the process but
> not start it up again automatically, only being started when
> subsequent request arrives.
>
> Dynamically creating external threads may also cause problems with
> accumulation of thread local data in Python. I'll have to actually
> check what happens on winnt MPM as it already dynamically creates
> threads from memory and so may already have this problem. :-(
>
> Anyway, perhaps explain better what you are talking about.
>
them together in the already existing directive WSGIDaemonProcess
Aldo i am not sure what the thread problems are, i am pretty sure it
will not affect all wsgi programs. I think you should leave as much
possibilities open because it will be just a matter of time before
they figure out to make the thread thing work properly.
Graham Dumpleton
Had already been thinking about how to overload on same directive.
Graham