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 > >> > > >> >> >> earlier does it seem that I have properly configured daemon > >> > > >> >> >> mode? > >> > > >> >> >> Thanks. > > >> > > >> >> >> On Nov 11, 12:22 pm, Alex Robbins > >> > > >> >> >> <[email protected]> > >> > > >> >> >> wrote: > > >> > > >> >> >> > If you are really running mod_wsgi in daemon mode, then > >> > > >> >> >> > django and > >> > > >> >> >> > satchmo won't be able to affect the size of the httpd > >> > > >> >> >> > processes. > >> > > >> >> >> > The > >> > > >> >> >> > python interpreter should live in the mod_wsgi daemon, > >> > > >> >> >> > which is a > >> > > >> >> >> > completely separate process. I have had troubles before > >> > > >> >> >> > with > >> > > >> >> >> > mod_wsgi > >> > > >> >> >> > running in embedded mode, even though it is supposed to be > >> > > >> >> >> > daemon. > >> > > >> >> >> > Can > >> > > >> >> >> > you see any processes for mod_wsgi? If you don't get the > >> > > >> >> >> > config > >> > > >> >> >> > exactly right, it won't use daemon > > ... > > 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]<satchmo-users%[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.
