Re: Open questions on Snowy deployment

[Jeff Schroeder <jeffschroed gmail com>]

On Mon, Apr 12, 2010 at 6:38 AM, Brad Taylor <brad getcoded net> wrote:
> Hey Ray,
>
> First off, thanks for putting in the work to get Snowy up and running on
> GNOME infrastructure.  You rock!
>
> As one of Snowy's hackers, I hope you don't mind me chiming in here:
>
>> 1) What software stack that we prefer to use?
>>     I mean (OS + web server + module + database), we have many choices.
>>     OS: RHEL,  Ubuntu,  Fedora etc, but this seems not a problem, the
>> server is sponsored by Redhat, so that RHEL would probably better.
>>     Web server: Apache,  lightttpd,  Ngnix?
>
> Nginx seems to be the new hotness, but I have little experience with it.
> Apache may be a safer option because it's used by the rest of the GNOME
> infrastructure, and more folks on this list will have experience with it
> versus Nginx.
>
>>     Module: mod_wsgi,  mod_python,  FastCGI?
>
> mod_wsgi seems to be what everyone is using these days.  Snowy is
> shipped with a wsgi configuration file, that, although has only bee
> lightly tested, should get you started.
>
>>     Database: mysql, postgresql, sqlite?
>
> Mysql definitely.  Snowy hasn't been tested on postgres, and there may
> be compatibility issues.

Apache/mod_wsgi/mysql. Try suggesting deploying _any_ django app with
mod_python in #django on freenode... chances are you'll be ridiculed.
We have a really beefy mysql instance on drawable so the database can
be stored there. Make sure to only give snowy access to it's own
database so it can't break anything. Oh wait, software never has bugs
*grin*

>> 2) Should we separate the components to many servers as distributed
>> architecture?
>>     - static files (media server)
>>     - database
>>     - load balancer
>
> IMHO, stick with one server for right now, and make sure you keep plenty
> of performance stats (e.g.: requests per minute per URL, number of
> queries, slow queries, etc).  When we start getting more users, then you
> can find out what the slowest parts of the system are, and optimize the
> stuffing out of them.  This is the biggest reason behind doing a phased
> deployment (invite-only, larger invite-only, open public beta, live).

Always try to keep things simple unless needs dictate otherwise. Less
is more so +1 to Brad's comments.

>> 3) Should we use memcached as a cache server?
>
> Yes, definitely.  Django uses cache heavily, and using the database for
> this is a great way to shoot yourself in the face, performance-wise.

Well didn't knuth say premature optimization was the root of all evil?
Lets see if we actually have any performance problems and how many
users sign up for tomboy online before setting up something exotic
like memcached. Does snowy use the django cache middleware? If not,
that might be a good start. Sorry I've not had a chance to poke at the
snowy code. Real life has gotten more busy than I'd like recently.

-- 
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com