django embedded web server

[Picio]

Hello,
I saw in the official docs that It's not a good practice to use the
django embedded web server in any production envionment.
I have a little Intranet with 4 workstation and a home made server
(based on an old pc).
There are no reason to think about security in this LAN because It's
only me, my wife and two other friends working. There are no
performance concerns since the I app I built It's very simple and only
2 or 3 users may work on It at the same time.
So,
what are the risks you see in me using the django web server to deploy
a little web app?

Picio

[Malcolm Tredinnick]

The development server is only single threaded. So one request at a
time. Since requests include each and every stylesheet, every image,
etc, that can be quite a number of requests per page.

If there is ever a problem where one browser doesn't close the
connection completely, it will block all other requests. This shouldn't
happen (since it will only be speaking HTTP/1.0, so persistent
connections aren't available), but I've heard people mentioning that
they'd had IE not closing the connection completely. Completely
unconfirmed by me; may or may not be a real problem.

There is no really robust error recovery in the server: if your code
throws an exception, it may be sufficient to stop the server's main loop
(not all exceptions cause this, but it's possible to have this happen).

All that said, try it out and see. If it doesn't work, you'll notice
pretty quickly and then you're no worse off than you are now. It's not
like it's going to take forever to set up the experiment (I would hope).

Regards,
Malcolm

[Picio]

Hello, I got the point thanks.
Which one is more easy to configure between
Apache + mod_python + django
and
Lighttpd +flup + fastcgi + django?

The platform will be a pIII 650 with windows2000 sp4, max user no. is 4.
Picio

[Picio]

2006/10/10, Malcolm Tredinnick <mal...@pointy-stick.com>:

[Joseph Heck]

I've been using Apache+Mod_Python+Django on windows without any trouble at all. The biggest "trick" is to set the configuration to enable the mod_python module and pass requests through to the right handler.

I don't know if it'll help you, but here's some of the example config pieces I use on my own little internal server:

Alias /media/ "C:\Python24/Lib/site-packages/Django-0.91-py2.4.egg/django/contrib/admin/media/"
<Directory "C:/Python24/Lib/site-packages/Django-0.91-py2.4.egg/django/contrib/admin/media">
    Options Indexes MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
<Location "/media/">
    SetHandler None
</Location>
<LocationMatch "\.(jpg|gif|png)$">
    SetHandler None
</LocationMatch>

<Location "/simon/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE simon.settings
    PythonPath "['C:\p4\p4-tss\users\jheck'] + sys.path"
    PythonDebug On
    PythonInterpreter simon
</Location>

<Location "/perforce/">
    SetHandler python-program
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE perforce.settings
    PythonPath "['C:\p4\p4-tss\users\jheck'] + sys.path"
    PythonDebug On
    PythonInterpreter perforce
</Location>

[Picio]

WoW thanks, I'll give it a try.
Is lighttpd setup more easy?
Picio

2006/10/11, Joseph Heck <josep...@gmail.com>:

[Joseph Heck]

just depends on what you're used to. I've not done lighttpd on windows, so I couldn't say. Since I had Apache, there didn't seem much reason to investigate and use Lighttpd+Flup on Windows.

I use Lighttpd+Flup+Django on TextDrive, and it runs fine there - but that's a unix system and most of the pieces were already easily available.

-joe

[Rob Hudson]

Malcolm Tredinnick wrote:
> The development server is only single threaded. So one request at a
> time. Since requests include each and every stylesheet, every image,
> etc, that can be quite a number of requests per page.

Can or will this ever change? If I understand correctly, the base WSGI
web server implementation (in django/core/servers/basehttp.py, class
ServerHandler) is multi-threaded (or at least it has the variable that
suggests so: wsgi_multithread = True).

I'm not clear on what would have to change to make this happen. If all
of Django would need to be changed to support a multithreaded
environment than I can see that as being too much and for a small or
unwanted gain. (Apache or other webserver typically handles the
threading so why should Django?) But if it's some tweaks to the
underlying included server...?

> If there is ever a problem where one browser doesn't close the
> connection completely, it will block all other requests. This shouldn't
> happen (since it will only be speaking HTTP/1.0, so persistent
> connections aren't available), but I've heard people mentioning that
> they'd had IE not closing the connection completely. Completely
> unconfirmed by me; may or may not be a real problem.

I hadn't realized or thought about this. Thanks for bringing it up.

> There is no really robust error recovery in the server: if your code
> throws an exception, it may be sufficient to stop the server's main loop
> (not all exceptions cause this, but it's possible to have this happen).

I've seen this happen where the server just drops to the command prompt
suddenly.

We've got a case where we may want to try to create a self-contained
Django instance to send to reviewers or clients. Not a production
environment but something that can run easily on a desktop. Seeing
some of these issues is enlightening.

I think our approach might have been to write a wrapper script to
launch something like Lighttpd for static files and Django for each
page request on separate ports to make the page load look more
responsive. For a single user on the desktop I think this might work
but we haven't attempted or tested it yet.

-Rob

[Russell Keith-Magee]

On 10/12/06, Rob Hudson <trebor...@gmail.com> wrote:
>
> Malcolm Tredinnick wrote:
> > The development server is only single threaded. So one request at a
> > time. Since requests include each and every stylesheet, every image,
> > etc, that can be quite a number of requests per page.
>
> Can or will this ever change?

I'm sure it could, but I'm almost certain it wont.

Django provides a light webserver to make development easy, not
because it has delusions of being a replacement for Apache. There are
plenty of excellent web servers out there, and the developers of those
webservers spend their time trying to make them faster, lighter and
more secure. We _could_ spend a lot of effort trying to improve
Django's internal webserver, but all we would end up doing is creating
YAWS (Yet Another Web Server) - while simultaneously diverting effort
away from fixing bugs and adding features.

Yours,
Russ Magee %-)

[Istvan Albert]

Russell Keith-Magee wrote:
>
> I'm sure it could, but I'm almost certain it wont.

The only problem with this is that some kind of sites cannot be tested
with the development server.

If the site streams back the output and incrementally builds it then it
cannot for example read in the css even though the browser would want
to load it in before the page completes. If there are certain
simultanous ajax calls that take a little while to complete they will
block the server as well.

That being said I understand why the server is such as it is, and why
it makes little sense to mess around with it. Maybe someone who knows
more about WSGI can step up and integrate an existing multithreaded
WSGI server.

i.

[Rob Hudson]

I'm also of the opinion that Django can only benefit by making the
built-in development web server better.

If I can develop Django projects without the need to install Apache (or
other web server) and use SQLite, that's awesome. For static files I
can just use something like this:

(r'^(?P<path>.*)$', 'django.views.static.serve',
{'document_root' : '/path/to/my/files/'})

I can do all my development self-contained in Django and have it
function as if it were hosted. Multi-threaded would be desired in this
case. And the barrier to setup and play with Django is much
diminished, I think.

-Rob

[Steve M]

I've been following this and related threads with some interest. I
think it would be nice to have a pure python (requiring no setup of,
e.g., Apache) webserver included with Django that was more capable than
the current Django development server. I recently stumbled across this:

http://pythonpaste.org/module-paste.httpserver.html

It is a multi-threaded WSGI webserver. It comes with paste, which by
the way seems to have a lot to offer, but even if the whole of paste
cannot be cleanly integrated with Django, doesn't the theory of WSGI
imply that it should be trivial to get a Django project running on this
server? I assume you would pass django.core.handlers.WSGIHandler to the
paste.httpserver.serve() function, although I haven't looked enough to
see how to connect it with a specific project.

So how realistic is it to replace the Django development server
(assuming licenses permit) with this server? Any reason it wouldn't be
desirable? I guess the single threaded devel server could make
debugging some problems less complex? Maybe I should just give it a
shot.

[Steven Armstrong]

http://pythonpaste.org/djangopaste/
http://trac.pythonpaste.org/pythonpaste/browser/Paste/DjangoPaste