On 12/3/10 3:45 PM, Alex Robbins wrote:
I use nginx + gunicorn in production for 3 or 4 sites and am very
happy with it. I have a friend who is using lighttpd instead, and is
also happy. I guess you should just read the docs and figure out whose
config files you like most :)
Alex
On Fri, Dec 3, 2010 at 3:46 PM, Josh<[email protected]> wrote:
I think I'll give Nginx a shot, maybe lighttpd too. Does anyone have
any comment on nginx vs. lighttpd in conjunction with gunicorn. I
know gunicron's page reccomends nginx. Thoughts?
-Josh
On Dec 2, 11:10 am, Stuart Laughlin<[email protected]> wrote:
I used Bruce's link to get another django site (not satchmo) up and running
on nginx and gunicorn. Went smoothly and running well, but still getting
used to it. I'm new to both those techs, plus supervisord, so it's a
learning curve.
--Stuart
On Dec 2, 2010 1:06 PM, "Josh"<[email protected]> wrote:
Bruce you had mentioned that you were preparing an article about
deploying on lighttpd and gunicorn. I was wondering if you had
finished it and if so where it was accessible. I am trying various
deployment options to figure which is the fastest/easiest.
Does anyone else have any experience or advice about this or know of
any good tutorials/resources.
Thanks!
-Josh
On Nov 12, 6:57 am, Alex Robbins<[email protected]>
wrote:
I think most people use mod_wsgi simply because it is the
djangoproject recommendation.
http://docs.djangoproject.com/en/1.2/howto/deployment/
"If you’re new to deploying Django and/or Python, we’d recommend you
try mod_wsgi first. In most cases it’ll be the easiest, fastest, and
most stable deployment choice."
Also, the value, quantity and quality of Graham Dumpleton's assistance
would be hard to overstate. He is everywhere, answering questions in
great detail and being very, very helpful. I think mod_wsgi's success
is due almost entirely to his huge investment of time showing people
how to use it. Also, mod_wsgi can be run without need external
processes setup by the user. For example, your fcgi orgunicorn
deployment would need something like supervisord running to manage it.
Perhaps setting up your own daemon, which supervises other daemons is
intimidating to some people.
I was very surprised to seegunicornmentioned as the obvious
deployment solution at djangocon, since it isn't even mentioned in the
docs. Having tried nginx+gunicornthough, I certainly prefer it. It is
faster and has a smaller memory footprint.
Alex
On Thu, Nov 11, 2010 at 8:21 PM, Bruce Kroeze<[email protected]> wrote:
I'd also love to hear a rational explanation justifying mod_wsgi over
fastcgi or proxying togunicorn. Most sites simply don't have the
traffic
where performance is an issue, so ... why? Considering maintenance as a
major cost moving forward for deployed sites, I'd love to be told why
apache/mod_wsgi is a reasonable solution. From what I can guess, it is
simple laziness, but I'd love to be shown wrong.
On Thu, Nov 11, 2010 at 4:54 PM, Josh<[email protected]> wrote:
C I am curious, I am assuming you would recommend fastcgi over
mod_wsgi and if so how come? I feel like there is so many people
telling you one over the other its hard to get straight facts and not
just "mod_wsgi is besttteststs...." Thanks for the input!
On Nov 11, 4:52 pm, Josh<[email protected]> wrote:
I think I have hunted the problem down. I had inadvertently included
the flatpages urls twice in two separate urls. One of them was
store/
urls.py and imported satchmo_store.urls and added the flatpages url.
The other was store/localsite/urls.py which is my root urls, but it
was included the store.urls and added the flatpages urls and other
urls for some custom stuff (like the redirect I mentioned in an
earlier post). So both urls were adding the flatpages url. Now I am
only using the store.localsite.urls (it now import satchmo_store.urls
instead of store.urls) and I have completely removed the flatpages
from those store.localsite.urls (I think the middleware was and now
it
definitely is taking care of flatpages anyway). When loading pages
memory use goes up but once pages are done loading the memory
stabilizes and I am assuming will eventually go down when the child
processes are killed by hitting their timeout. Thanks for all of the
help, I'm still going to take a look atgunicornas well because
performance has been an issue and anything to make it faster would be
great.
-Josh
On Nov 11, 2:19 pm, Alex Robbins<[email protected]>
wrote:
Yeah, I'm with Bruce on that. We switched from mod_wsgi to
nginx/gunicornbecause it was a pain and took more resources.
Alex
On Thu, Nov 11, 2010 at 3:52 PM, Bruce Kroeze<[email protected]>
wrote:
Bleah.
I'm going to jump in here and say - as I always do in this type
of
situation
- that Apache is a terrible solution for Django/Satchmo.
Djangoproject's
recommendation is simply wrong for most use cases.
This is yet another reason why. You can't determine where the
leak
is. Is
it Apache? Is it mod_wsgi misconfigured? Who knows? It isn't
something
you can get to the bottom of without a ton of testing, and in the
meantime
your site is crashing.
Who cares? Stop using Apache. Mod_wsgi stinks, almost as much
as
mod_python.
My preferred solution these days has changed, and I'm preparing a
detailed
article about it, but it isn't very far from this solution.
http://brandonkonkle.com/blog/2010/jun/25/provisioning-new-ubuntu-ser...
Differences in my most-preferred-solution: I use buildout
instead
of pip,
and Lighttpd instead of Nginx. Neither change would affect the
superiority
of this solution.
Here's the big deal - this is why you should do this in a
nutshell:
1) You will explicitly know which process is eating memory, since
you will
have separate django daemon threads.
2) Green Unicorn will allow you to kill and recycle worker
threads
after
timeouts. If it really is Satchmo eating memory, then that will
release the
memory on a continual basis.
2.5) Green Unicorn is almost unbelievably nice. Really. I love
it.
3) Your site will almost certainly be faster. In any case, much
faster
compared to a crashed server.
4) Figuring out what is wrong will be much much easier.
#4 is the biggest issue, IMHO. 90% of the cost of a store is
maintenance.
Anything that makes the store easier to maintain and debug is
worth
it,
even if #3 is not true. Worth a little speed slowdown (doubtful
in
any
case) in exchange for testability and clarity.
Good Luck,
Bruce Kroeze
On Thu, Nov 11, 2010 at 1:27 PM, Alex Robbins
<[email protected]> wrote:
Sorry, at this point its hard for me to say exactly what is
going
on.
I'd say if you can't see any processes with the name you
assigned
in
the config directive, then it seems like there probably aren't
daemon
processes. This is what happened to me earlier. I had to tweak
and
mess with the daemon process settings to get it to work. If I
remember
my situation correctly, the process group wasn't setup right,
but
yours looks ok to me.
As for how is it running at all? If it isn't in daemon mode,
then
it
is running in embedded mode. There is a python interpreter in
every
httpd process, which would take a lot of ram if you spawned a
bunch
of
httpd worker processes.
Alex
On Thu, Nov 11, 2010 at 3:13 PM, Josh<[email protected]> wrote:
Ok so the conf now looks like this:
WSGIDaemonProcess hatikva.com user=hatikva group=hatikva
python-path=/
usr/local/lib/python2.6/site-packages display-name=%{GROUP}
WSGIProcessGroup hatikva.com
WSGIScriptAlias / /home/hatikva/store/apache/store.wsgi
but when I ps -A I don't see anything like wsgi:hatikva. Does
this
potentially mean it's not really running in daemon mode? If
so
any
ideas on how it is running at all?
On Nov 11, 12:53 pm, Alex Robbins<
[email protected]>> >> > > >> > wrote:
Yeah, looks like you are right. I think I normally used that
'display-name option' that Graham mentioned. Sorry about the
confusion
there. If you use that, then do they show up in ps?
Alex
On Thu, Nov 11, 2010 at 2:47 PM, Josh<[email protected]>
wrote:
I also noticed that down near the bottom of this thread
http://groups.google.com/group/modwsgi/browse_thread/thread/9d0e72b2c...
Graham Dumpleton said that "Under 'top' or 'ps', the
mod_wsgi
daemon
process will still show as a apache/httpd process." So I
think it
all
gets lumped together.
On Nov 11, 12:38 pm, Josh<[email protected]> wrote:
Hmm, i don't think I'm actually seeing the daemons. What
do
they
show
up as under COMMAND (I dont see anything with wsgi). But
there is
another small dev site running on the same server (they
are
both
theoretically set up under daemon mode as I showed above).
I
think
that if it wasn't in daemon mode they wouldn't both work
although I
could be wrong about that. Looking at the apache conf I
posted
...
read more »
--
You received this message because you are subscribed to the Google Groups "Satchmo
users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en.
I got it working with lighttpd but I'm having some trouble figuring out
how to not pass everything to gunicorn though the proxy (i.e. have
/static/ and /media/ served by lightppd). right now I have
alias.url = (
"/static/" => "/path/to/static/",
"/media/" =>
"/usr/local/lib/python2.6/site-packages/django/contrib/admin/media/"
)
url.rewrite-once = (
"^(/static.*)$" => "$1",
"^(/media.*)$" => "$1",
"^/favicon\.ico$" => "/media/favicon.ico",
)
proxy.server = ( "/" =>
( (
"host" => "127.0.0.1",
"port" => 29000
) )
)
This doesn't work. Does anyone know what I have done wrong?
-Josh
--
You received this message because you are subscribed to the Google Groups "Satchmo
users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/satchmo-users?hl=en.
