2015-06-28 3 views
7

Ich benutze nginx + gunicorn zum Servieren einer Django-App und habe es auf EC2 (m1.small instance) bereitgestellt.Django + Gunicorn + nginx ergibt sehr schlechte Leistung. Kann nicht einmal 8 qps bekommen

Ich habe diese Ansicht:

def hi(request): 
    return HttpResponse('hi', content_type='text/plain') 

abgebildet /hi/ url. Es gibt im Grunde nur hi um [myurl]/hi zurück.

Nun, wenn ich laden Test dieser Domain ([myurl]/hi) von loader.io, bedeutet dies nicht einmal die 250 Kunden über 30 Sekunden Test. (Ca. 8 Anfragen pro Sekunde)

This is (Teil von) meine nginx access.log Datei. Es gibt im Grunde nur 499 s nach wenigen 200 s. (Timeout in loader.io ist auf 10 Sekunden eingestellt)

Ich muss etwas ernsthaft falsch machen. Wie finde ich heraus?

ich profilierte es yet-another-django-profiler mit und finden Sie die Ausgabe: enter image description here

ich diese django app auf Elastic Beanstalk eingesetzt (die Apache-Server verwendet) zu (m3.large Beispiel), und auch da ich schreckliche Leistung bekommen . Meine Middleware ab jetzt ist:

MIDDLEWARE_CLASSES = (
    'django.contrib.sessions.middleware.SessionMiddleware', 
    # 'django.middleware.common.CommonMiddleware', 
    # 'django.middleware.csrf.CsrfViewMiddleware', 
    # 'silk.middleware.SilkyMiddleware', 
    # 'yet_another_django_profiler.middleware.ProfilerMiddleware', 
    # 'debug_toolbar.middleware.DebugToolbarMiddleware', 
    'django.contrib.auth.middleware.AuthenticationMiddleware', 
    # 'django.contrib.auth.middleware.SessionAuthenticationMiddleware', 
    # 'django.contrib.messages.middleware.MessageMiddleware', 
    # 'django.middleware.clickjacking.XFrameOptionsMiddleware', 
    # 'django.middleware.security.SecurityMiddleware', 
) 

früher nichts davon wurde als Kommentar gekennzeichnet. Als ich diese 9 Zeilen auskommentierte, bekam ich einen Leistungsschub. Jetzt kann ich 60 qps aus dieser App bekommen. Aber ich denke, dass ich mehr Fehler mache und dass es weiter skalieren kann. Diese

+1

Meine erste Vermutung wäre, dass Sie die Systeme falsch konfiguriert haben. Zum Beispiel haben Sie vielleicht [nicht genügend Worker-Threads] (http://gunicorn-docs.readthedocs.org/en/latest/design.html#how-many-workers) für Gunicorn angegeben. Wenn Sie das bereits getan haben, sollten Sie anfangen, herauszufinden, wo Ihr Engpass liegt - CPU, RAM, Festplatte oder Netzwerk. Die Bereitstellung einiger CPU- und Antwortzeiten, während Sie unter Last sind (z. B. von 'vmstat' und Blick auf Anfrage-/Antwortzeiten von' tcpdump'), würde an dieser Stelle helfen. –

+1

1. Was ist der Befehl, den Sie zum Starten von Gunicorn verwenden? 2. Wie sieht Ihre Einstellungsdatei aus (insbesondere die Middleware)? 3.Was sonst läuft auf diesem Server? – Seth

+0

@Seth: Ja, Middleware war Teil des Problems. Es läuft nichts mehr auf dem Server. Außerdem starte ich Gunicorn [mit diesem Skript] (http://pastebin.com/DezHbyiC). – kamalbanga

Antwort

1

ist nur ein Stich in der Dunkelheit ohne mehr zu gehen, und ich habe nicht genug Ruf auf Ihre ursprüngliche Frage zu äußern: Ich habe bemerkt, dass Ihr gunicorn Startskript hat

--log-level=debug

Wenn Sie Debug haben Level-Logging (in Gunicorn und speziell im Django-Projekt) würde erklären, warum die Performance gesteigert wurde, indem die Middleware auskommentiert wurde und warum man die Performance aus einer anderen Deployment-Architektur weiter verschlechtern würde.

Debug-Ebene protokolliert Ausgaben eine Menge Informationen.

0

Ich habe keine Ahnung, was Sie falsch gemacht haben, aber kann ich Ihnen vorschlagen, wieder mit uWSGI anstelle von Gunicorn zu testen? Laut vielen Benchmarks scheint uWSGI eine bessere Leistung als Gunicorn zu bieten. Wenn sich die Leistung nicht wesentlich ändert, können Sie Ihre Untersuchung auf nginx- oder EC2-Konfigurationen konzentrieren. Ich möchte nicht missionieren, nur ermutigen Sie durch einen Prozess der Beseitigung zu finden.

Hoffe, es wird helfen!