Mais limpa e mais rápida configuração do servidor de Django

votos
42

Estou prestes a implantar um site de médio porte alimentado por Django. Eu tenho um servidor Ubuntu dedicado.

Estou realmente confuso sobre qual serversoftware de usar. Então eu pensei: por que não pedir stackoverflow.

O que eu estou procurando é:

  • Fácil de configurar
  • Rápido e fácil sobre os recursos
  • Pode servir mediafiles
  • Capaz de servir a múltiplos djangosites no mesmo servidor
  • Prefiro não instalar o PHP ou qualquer outra coisa que suga recursos, e para o qual eu não tenho nenhum uso para.

Tenho ouvido falar de mod_wsgi e mod_python no Apache, o nginx e lighty. Quais são os prós e contras destes e eu perdi alguém?

@Barry : De alguma forma eu me sinto como Apache é inchado por mim. E sobre as alternativas?

@BrianLy : Ok, eu vou verificar mod_wsgi um pouco mais. Mas por que eu preciso Apache se eu servir arquivos estáticos com lighty? Eu também conseguiu servir a própria aplicação Django com lighty. Isso é ruim de qualquer maneira? Sorry for beeing :-) tão estúpido

ATUALIZAÇÃO : E sobre lighty e nginx - que são os usos-casos em que estes são a escolha perfeita?

Publicado 25/08/2008 em 14:28
fonte usuário
Em outras línguas...                            


13 respostas

votos
26

Desde que eu estava à procura de mais algumas respostas em profundidade, decidi pesquisar o assunto me em profundidade. Por favor, deixe-me saber se eu fui mal qualquer coisa.

Alguns recomendação geral é usar um servidor separado para lidar com a mídia. Por separado, quero dizer um servidor que não está em execução Django. Este servidor pode ser, por exemplo:

  • Lighttpd (Lighty)
  • Nginx (EngineX)
  • Ou algum outro servidor leve

Então, para Django, você pode ir por caminhos diferentes. Você também pode:

  • Sirva Django via Apache e:

    • mod_python

      Esta é a / maneira bem documentada estável e recomendado. Contras: usa muita memória.

    • mod_wsgi

      Pelo que eu entendo, mod_wsgi é uma alternativa mais recente. Parece ser mais rápido e fácil sobre os recursos.

    • mod_fastcgi

      Ao usar FastCGI você está delegando a porção de Django para outro processo. Desde mod_python inclui um interpretador Python em cada pedido que ele usa muita memória. Esta é uma maneira de contornar esse problema. Também há algumas preocupações de segurança.

      O que você faz é que você iniciar o seu servidor Django FastCGI em um processo separado e, em seguida, configura apache via reescreve a chamar este processo quando necessário.

Ou você pode:

  • Sirva Django sem usar Apache , mas com outro servidor que suporta FastCGI nativamente:

    (A documentação menciona que você pode fazer isso se você não tem quaisquer necessidades específicas do Apache. Eu acho que a razão deve ser para poupar memória.)

    • lighttpd

    Este é o servidor que executa o Youtube. Parece fácil de usar e rápido, porém eu vi relatórios sobre memoryleaks.

    • nginx

    Eu vi benchmarks, alegando que este servidor é mais rápido do que lighttpd. É principalmente documentado em russo embora.

Outra coisa, devido às limitações na Python seu servidor deve estar em execução no modo bifurcada, não roscado.

Portanto, esta é a minha pesquisa atual, mas eu quero mais opiniões e experiências.

Respondeu 27/08/2008 em 09:41
fonte usuário

votos
9

Estou usando Cherokee .

De acordo com os seus benchmarks (grão de sal com eles), ele lida com carga melhor do que ambos Lighttpd e nginx ... Mas isso não é por isso que eu usá-lo.

Eu usá-lo porque se você digitar cherokee-admin, ele começa um novo servidor que você pode entrar em (com um one-time password) e configurar todo o servidor através de um webmin bem-feito. Essa é uma característica do assassino. Ele já me salvou um monte de tempo. E ele está salvando meu servidor um monte de recursos!

Quanto django, eu estou correndo como um processo SCGI rosca. Funciona bem. Cherokee pode mantê-lo funcionando também. Novamente, muito bom recurso.

A versão atual do Ubuntu repo é muito antiga, então eu aconselho você usar o seu PPA . Boa sorte.

Respondeu 09/12/2008 em 18:08
fonte usuário

votos
6

Como disse @Barry, a documentação usa mod_python . Eu não usei Ubuntu como um servidor, mas tinha uma boa experiência com mod_wsgi no Solaris. Você pode encontrar documentação para mod_wsgi e Django no mod_wsgi site.

Uma rápida revisão de suas necessidades:

  • Fácil de configurar eu encontrei apache 2.2 bastante fácil de construir e instalar.
  • Rápido e fácil sobre os recursos , eu diria que isso depende do seu uso e tráfego. * Você não pode querer servidor todos os arquivos usando Apache e usar LightTPD (lighty) para arquivos estáticos do servidor.
  • Pode servir arquivos de mídia eu suponho que você quer dizer imagens, arquivos flash? Apache pode fazer isso.
  • Vários sites no mesmo servidor servidor virtual hospedagem em Apache.
  • Prefiro não instalar outras extensões Comentário fora qualquer coisa que você não quer na configuração do Apache.
Respondeu 25/08/2008 em 15:00
fonte usuário

votos
5

A maneira oficialmente recomendado para implantar um projeto Django é usar mod_python com Apache. Isto está descrito na documentação. O pro principal com isto é que é a maneira mais bem documentado, mais apoiado, e mais comum para implantar. O con é que ele provavelmente não é o mais rápido.

Respondeu 25/08/2008 em 14:49
fonte usuário

votos
2

Na minha opinião melhor / pilha mais rápido é verniz-nginx-uwsgi-django. E eu estou usando-o com sucesso.

Respondeu 09/05/2011 em 22:01
fonte usuário

votos
2

Mantenha-o simples: Django recomenda Apache e mod_wsgi (ou mod_python) . Se servir arquivos de mídia é uma parte muito grande do seu serviço, considere Amazon S3 ou Rackspace CloudFiles.

Respondeu 15/06/2009 em 03:09
fonte usuário

votos
2

Eu estou lutando para entender todas as opções também. Em este post eu encontrei alguns benefícios do mod_wsgi em comparação com mod_python explicou.

Vários sites de baixo tráfego em uma pequena VPS tornar o consumo de RAM a principal preocupação, e mod_python parece ser uma má opção lá. Usando lighttpd e FastCGI, eu consegui obter o uso de memória mínimo de um site simples Django até residente virtual e 6.5MiB 58MiB (depois de reiniciar e servir uma única solicitação não-RAM-pesado).

Tenho notado que a atualização do Python 2,4 a 2,5 no Debian Etch aumentou o consumo de memória mínimo dos processos Python por alguns por cento. Por outro lado, melhor gerenciamento de memória 2.5 do pode ter um efeito oposto maior sobre processos de longa duração.

Respondeu 06/10/2008 em 08:56
fonte usuário

votos
2

Estou usando nginx (0.6.32 tirado de Sid ) com mod_wsgi . Ele funciona muito bem, embora eu não posso dizer se é melhor do que as alternativas, porque eu nunca tentei qualquer. Nginx tem memcached suporte embutido, que pode talvez interoperar com o cache middleware Django (eu realmente não usá-lo, em vez disso, preencher o cache manualmente usando python-memcache e invalidá-la quando são feitas alterações), então o cache atinge ignorar completamente Django (minha máquina de desenvolvimento podem servir cerca de 3000 pedidos por segundo).

Uma ressalva: nginx' mod_wsgialtamente não gosta de locais nomeados (ele tenta passá-los em SCRIPT_NAME), então o óbvio ' error_page 404 = @django' fará com que inúmeros erros obscuros. Eu tinha que consertar mod_wsgi fonte de corrigir isso.

Respondeu 24/09/2008 em 12:58
fonte usuário

votos
2

A melhor configuração não é tão conhecido que eu penso. Mas aqui é:

  1. Use nginx para servir pedidos (dinâmica para aplicação, conteúdo estático diretamente).
  2. Usar servidor web python para servir conteúdo dinâmico.

Duas soluções mais rápidas para o servidor web baseado em Python é:

Você precisa olhar para o Google para encontrar melhor configuração atual para Django (ainda em desenvolvimento).

Respondeu 20/09/2008 em 19:06
fonte usuário

votos
1

Eu tenho um aviso para usar Cherokee. Quando você faz alterações para Django Cherokee mantém o processo antigo, em vez de matá-lo e começar um novo.

No Apache eu recomendo fortemente este artigo.

http://www.djangofoo.com/17/django-mod_wsgi-deploy-exampl

É fácil de configurar, fácil de matar ou reiniciar depois de fazer alterações.

Basta digitar o terminal

sudo /etc/init.d/apache2 restart

e as mudanças são vistas instantaneamente.

Respondeu 13/02/2013 em 00:55
fonte usuário

votos
1

Há muitas maneiras, a abordagem para fazer this.For essa razão, eu recomendo a leitura do artigo relacionado com o processo de implantação em DjangoAdvent.com: Eric Florenzano - Implantando o Django com FastCGI: http://djangoadvent.com/1.2/deploying -django-site-usando-fastcgi / Leia também: Mike Malone - Escala Django Stochastictechnologies Blog: A configuração perfeita Django Mikkel Hoegh Blog: 35% de resposta em tempo-aperfeiçoamento de comutação-uwsgi-nginx

Saudações

Respondeu 28/10/2010 em 05:05
fonte usuário

votos
1

Usamos nginx e FastCGI para todas as nossas implantações de Django. Isto é principalmente porque geralmente implantar em cima da Slicehost, e não querem doar toda a nossa memória para Apache. Eu acho que isso seria o nosso "caso de uso".

Quanto aos comentários sobre a documentação sendo principalmente em russo - Eu encontrei a maioria das informações sobre o wiki Inglês a ser muito úteis e precisas. Este site tem exemplos de configurações para Django também, a partir do qual você pode ajustar sua própria configuração nginx.

Respondeu 04/09/2008 em 14:53
fonte usuário

votos
1

Se você estiver usando lighthttpd, você também pode usar FastCGI para servir Django. Eu não tenho certeza de como a velocidade compara com mod_wsgi, mas se a memória corretamente, você tem um par dos benefícios que você obteria com mod_wsgi que você não iria ficar com mod_python. A principal delas é que você pode dar a cada pedido de seu próprio processo (que é realmente útil para manter memória de diferentes aplicativos separados, bem como para tirar proveito de computadores multi-core.

Edit: Só para acrescentar no que diz respeito à sua atualização sobre nginix, se a memória corretamente novamente, nginix usa "greenlets" para lidar com a concorrência. Isso significa que você pode precisar de ser um pouco mais cuidadosa para se certificar de que um aplicativo não come-se todo o tempo do servidor.

Respondeu 25/08/2008 em 16:06
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more