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.
>
>

-- 
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.

Reply via email to