Neu bei Rails, ist diese Art von Leistung normal?

Question

Ich habe eine app, und in nur Controller sind, wird eine Aktion so konfiguriert:

def do_call 
    response = <<EOF 
<real-time-stat> 
<awt type="integer">1</awt> 
<cc type="integer">5</cc> 
<cp type="integer">0</cp> 
<dc type="integer">0</dc> 
<ef type="float">100.0</ef> 
<rc type="integer">6</rc> 
<sl type="float">100.0</sl> 
<state type="integer">0</state> 
<ts type="datetime">2009-07-24T10:36:57Z</ts> 
<wc type="integer">0</wc> 
<wprc type="float">0.0</wprc> 
<real-time-stat> 
EOF 
    respond_to do |format| 
     format.xml { render :xml => response } 
    end 
    end 

Dies ist ein Test für eine Aktion, die in der Zukunft, die Felder aus einer MySQL-DB abrufen. Allerdings läuft diesen Code in Produktion Modus, von einem LOCAL WEBrick Server auf Port 3000 läuft auf einem Pentium 4 (ein bisschen alt, aber Dual-Core) Maschine, bekomme ich Reaktionszeiten (gemessen von YSlow, ein Yahoo! Add-On für Firebug) von 175 bis 500 Millisekunden (wild fluktuierend)!

Ist das normal? Mache ich es falsch? In Anbetracht der Tatsache, dass ich mehrere Abfragen in einer einzigen Antwort und XML-ify alle von ihnen (mit ActiveResource) aggregieren möchte, bekomme ich Glockengeläute, dass es unmöglich skalieren kann ...: |

Danke für jede Rückmeldung!

EDIT: Wechsel zu Mongrel ändert sich die Situation nicht viel, noch 175-300 ms pro Antwort. Die Protokolle zeigen jedoch 0 bis 15 ms pro "abgeschlossener" Anfrage (200 OK). Ist der Unterschied auf die Darstellung des XML-Codes durch Firefox zurückzuführen? Wenn nicht, woher kommt es?

Answer 1

Wenn Sie nur einen Webserver lokal ausführen und ihn mit Firefox zur Leistungsmessung verwenden, werden Sie erratische, irreführende und fragwürdige Ergebnisse erhalten.

Versuchen Sie, alles außer Ihrem Webserver auszuschalten, und verwenden Sie entweder ab oder HTTPerf, um eine zuverlässigere Metrik für die Leistung zu erhalten.

Wenn Sie immer noch schlechte Antwortzeiten sehen, wenn Sie nur eine Zeichenfolge zurückspucken, ist ein gutes Werkzeug RubyProf, das Sie ausführen können und sehen, wo Rails Zeit verbringt.

Answer 2

Ich kann nur an einen anderen Webserver denken. Webrick ist sehr langsam.

Mit Mongrel oder Thin erhalten Sie bessere Leistung.

Auch wenn Sie sich im Produktionsmodus befinden, überprüfen Sie einfach die Konfigurationseinstellungen production.rb, und stellen Sie sicher, dass Klassencaching usw. immer noch aktiviert ist.

Answer 3

Antwort von der Hand: WebRick nicht verwenden. Es ist langsam. Wirklich langsam. Installieren Sie Mongrel und Rails wird es automatisch verwenden. Verwenden Sie in der Produktion Mongrel oder Passenger.

Answer 4

Wirrick ist langsam. Versuchen Sie es erneut unter einem schönen Passagier-Setup und melden Sie sich dann erneut.

Answer 5

Es gibt mehrere Implikationen, die dazu führen, dass Ihr Test nicht zu repräsentativ ist. Lassen Sie mich ein paar erklären:

1. Sie Test in einer Entwicklungsumgebung ausgeführt wird. Die Entwicklungsumgebung (definiert in config/environments/development.rb) unterscheidet sich stark von der Produktionsumgebung (definiert in config/environments/development.rb). Erstens werden die Klassen nicht zwischengespeichert, sodass der größte Teil Ihrer Anwendungsbibliotheken bei jeder Anforderung neu geladen wird. Bei der Produktion zwischenspeichert Rails Ihre Objekte beim Booten und analysiert die Codebasis nicht erneut. Dies ist ein Super-Leistungsschub.

2. Wie Sie gesagt haben, verwenden Sie den schlechtesten Webserver, der zur Verfügung steht. Sie sollten Mongrel verwenden oder, um einen echten Benchmark auszuführen, sollten Sie denselben Server verwenden, den Sie in der Produktion verwenden werden.

3. Es ist oft eine gute Regel, Tests in einer Umgebung durchzuführen, die der letzten entspricht oder ähnlich ist. Wenn Sie einen Test im Entwicklungsmodus ausführen und versuchen zu erraten, wie er online funktioniert, erhalten Sie keine guten Informationen.

4. Sie vermissen Cache. Rails bietet viele verschiedene Cache-Level. Um Ihre Leistung zu verbessern, könnten Sie in Erwägung ziehen, Ihre Modellanforderungen und/oder Ihre Antworten mit dem Zwischenspeichern von Seiten/Aktionen/Fragmenten zwischenzuspeichern.Möglicherweise möchten Sie auch HTTP-Header verwenden, die 304 HTTP-Header senden, wenn der Inhalt nicht geändert wird, und einen Reverse-Proxy einrichten.

5. Für diesen speziellen Fall der Antwort, möchten Sie vielleicht die volle Rails Aktion/Controller-Stack und implementieren eine Rails :: Metallschicht überspringen, so dass Ihre Antwort so schnell serviert wird, wie es fertig ist

Answer 6

wickeln Sie Ihren Anruf in

start = Time.now 
    ... 
    elapsed_time = Time.now - start 

und sehen, wie viele Sekunden es dauert.

Andere Tests auf Ihrer Entwickler-Plattform unzuverlässig sein, bis es zu Server-Produktionen einsetzen

Answer 7

WEBrick auf Verbindungs ​​IPs standardmäßig einen Reverse-DNS-Lookup. Mit anderen Worten, es versucht zu sehen, ob Ihre IP-Adresse mit einem Domain-Namen verknüpft ist. Dies ist unnötig und dauert zu lange, so dass Sie es deaktivieren können.

Öffnen Sie die Datei "l/ruby ​​/ lib/ruby ​​/ 1.9.1/webrick/config.rb" und suchen Sie die Zeile mit ": DoNotReverseLookup => nil". Ändern Sie nil in true.

Viel Spaß!