2016-05-02 9 views
4

Ich bench Benchmarking eine einfache Hallo Welt Beispiel in Scala play Framework 2.5 und in Golang. Golang scheint das Spiel deutlich zu übertreffen und ich würde gerne wissen, wie ich das Spiel-Framework optimieren könnte, um die Performance zu verbessern. Ich verwende im Anschluss an die Benchmarkscala Play 2.5 vs Golang Benchmark und Optimierung der Leistung im Spiel Rahmen

ab -r -k -n 100000 -c 100 http://localhost:9000/ 

Ich play 2.5 in prod Modus mit der Standardkonfiguration überall in meinem Projekt läuft. Kann mir jemand bei der Leistungsoptimierung des Play Servers helfen, um die beste Leistung zu erzielen? Ich habe den Standard-Dispatcher-Thread-Pool gelesen, aber ich bin mir nicht sicher, welche Einstellungen ich für meinen PC verwenden soll. Gibt es noch andere Bereiche, die ich überprüfen könnte, die mit der Leistung helfen würden?

hier sind meine marchine Spezifikationen

Intel(R) Xeon(R) W3670 @ 3.20GHz 3.19GHz, 12.0 GM RAM, running windows 7 64-bit 

Bitte beachten Sie, dass ich sbt bin mit (sauber und Bühne), um den Server in im prod Modus und die Ausführung der bat-Datei auf Ziel/universal/Bühne gefunden laufen /Behälter/. Hier ist der Quellcode für das Spiel

package controllers 

import play.api.mvc._ 


class Application extends Controller { 


    def index = Action { 
    Ok("Hello, world!") 
    } 

} 

hier ist das Ergebnis von der ab Benchmark

ab -r -k -n 100000 -c 100 http://localhost:9000/ 
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking localhost (be patient) 
Completed 10000 requests 
Completed 20000 requests 
Completed 30000 requests 
Completed 40000 requests 
Completed 50000 requests 
Completed 60000 requests 
Completed 70000 requests 
Completed 80000 requests 
Completed 90000 requests 
Completed 100000 requests 
Finished 100000 requests 


Server Software: 
Server Hostname:  localhost 
Server Port:   9000 

Document Path:  /
Document Length:  13 bytes 

Concurrency Level:  100 
Time taken for tests: 1.537 seconds 
Complete requests:  100000 
Failed requests:  0 
Keep-Alive requests: 100000 
Total transferred:  15400000 bytes 
HTML transferred:  1300000 bytes 
Requests per second: 65061.81 [#/sec] (mean) 
Time per request:  1.537 [ms] (mean) 
Time per request:  0.015 [ms] (mean, across all concurrent requests) 
Transfer rate:   9784.69 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 0.0  0  1 
Processing:  0 2 1.9  1  72 
Waiting:  0 2 1.9  1  72 
Total:   0 2 1.9  1  72 

Percentage of the requests served within a certain time (ms) 
    50%  1 
    66%  2 
    75%  2 
    80%  2 
    90%  3 
    95%  3 
    98%  5 
    99%  8 
100%  72 (longest request) 

hier ist der Quellcode für golang

package main 

import (
    "fmt" 
    "net/http" 
) 

func handler(w http.ResponseWriter, r *http.Request) { 
    fmt.Fprintf(w, "Hello, world!") 
} 

func main() { 
    http.HandleFunc("/", handler) 
    http.ListenAndServe(":8080", nil) 
} 

hier ist das Ergebnis von ab Benchmark für Golang

ab -r -k -n 100000 -c 100 http://localhost:8080/ 
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking localhost (be patient) 
Completed 10000 requests 
Completed 20000 requests 
Completed 30000 requests 
Completed 40000 requests 
Completed 50000 requests 
Completed 60000 requests 
Completed 70000 requests 
Completed 80000 requests 
Completed 90000 requests 
Completed 100000 requests 
Finished 100000 requests 


Server Software: 
Server Hostname:  localhost 
Server Port:   8080 

Document Path:  /
Document Length:  13 bytes 

Concurrency Level:  100 
Time taken for tests: 0.914 seconds 
Complete requests:  100000 
Failed requests:  0 
Keep-Alive requests: 100000 
Total transferred:  15400000 bytes 
HTML transferred:  1300000 bytes 
Requests per second: 109398.30 [#/sec] (mean) 
Time per request:  0.914 [ms] (mean) 
Time per request:  0.009 [ms] (mean, across all concurrent requests) 
Transfer rate:   16452.48 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 0.0  0  1 
Processing:  0 1 1.5  1  52 
Waiting:  0 1 1.5  1  52 
Total:   0 1 1.5  1  52 

Percentage of the requests served within a certain time (ms) 
    50%  1 
    66%  1 
    75%  1 
    80%  1 
    90%  1 
    95%  2 
    98%  5 
    99%  7 
100%  52 (longest request) 

Wir danken Ihnen im Voraus Francis

UPDATE!

die folgenden Ergebnisse zu einer verbesserten Leistung, aber ich bin in andere Ideen immer noch daran interessiert, die

package controllers 

import play.api.mvc._ 
import scala.concurrent.Future 
import play.api.libs.concurrent.Execution.Implicits.defaultContext 


class Application extends Controller { 


    def index = Action.async { 
    Future.successful(Ok("Hello, world!")) 
    } 

} 

Benchmark

ab -r -k -n 100000 -c 100 http://localhost:9000/ 
This is ApacheBench, Version 2.3 <$Revision: 1706008 $> 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ 
Licensed to The Apache Software Foundation, http://www.apache.org/ 

Benchmarking localhost (be patient) 
Completed 10000 requests 
Completed 20000 requests 
Completed 30000 requests 
Completed 40000 requests 
Completed 50000 requests 
Completed 60000 requests 
Completed 70000 requests 
Completed 80000 requests 
Completed 90000 requests 
Completed 100000 requests 
Finished 100000 requests 


Server Software: 
Server Hostname:  localhost 
Server Port:   9000 

Document Path:  /
Document Length:  13 bytes 

Concurrency Level:  100 
Time taken for tests: 1.230 seconds 
Complete requests:  100000 
Failed requests:  0 
Keep-Alive requests: 100000 
Total transferred:  15400000 bytes 
HTML transferred:  1300000 bytes 
Requests per second: 81292.68 [#/sec] (mean) 
Time per request:  1.230 [ms] (mean) 
Time per request:  0.012 [ms] (mean, across all concurrent requests) 
Transfer rate:   12225.66 [Kbytes/sec] received 

Connection Times (ms) 
       min mean[+/-sd] median max 
Connect:  0 0 0.0  0  1 
Processing:  0 1 2.2  1  131 
Waiting:  0 1 2.2  1  131 
Total:   0 1 2.2  1  131 

Percentage of the requests served within a certain time (ms) 
    50%  1 
    66%  1 
    75%  1 
    80%  2 
    90%  2 
    95%  3 
    98%  5 
    99%  7 
100% 131 (longest request) 
+3

Das liegt daran, dass Sie eine Low-Level-HTTP-Bibliothek (go net/http) mit einem High-Level-Framework (Play) vergleichen. Das High-Level-Framework macht viel mehr Dinge, weil es mehr Utilities bietet und dann langsamer ist. Ein fairer Vergleich wäre zwischen Netty (die http "Bibliothek" von Play) mit Go "net/http". Ich würde auch empfehlen, die Tests gegen das Spiel zu starten, bis Sie konsistente Ergebnisse erhalten (wegen der JIT-Kompilation beim JVM). – marcospereira

+3

@marcospereira Ich würde kaum nennen "net/http" "Low-Level", es ist eine wichtige Abstraktion.Sie können eine Route mit einer einzelnen Codezeile öffnen und die eingehende Anfrage wird analysiert und in ein nettes Objekt umgewandelt, in dem alle Daten leicht zugänglich sind. Ich würde dieses ziemlich hohe Niveau nennen, da das Ding tatsächlich binäre Daten empfängt, die nicht einmal alle ein Stück sind. Zum OP; Warum benutzt du nicht einfach Play? Es nervt. Das sind meine 2 Cent. Es ist Leistung saugt, weil es übermäßig abstrahiert ist und ich wette, Sie werden nicht 80% von dem, was es Ihnen gibt, verwenden, während Ihre Leistung zu 100% der Zeit leiden wird. – evanmcdonnal

+2

Low-Level im Vergleich zu einem Full-Stack-Framework wie spielen. Das war was gemeint. – marcospereira

Antwort

2

Wie @marcospereira gesagt hat, ergibt sich die Leistung verbessern könnte, ist spielen eine relativ High-Level-Framework, das sich darauf konzentriert, das viel fortschrittlichere Typ-System in Scala zu nutzen, um Ihnen eine Menge Funktionen und Sicherheit zu geben, was Ihnen wiederum hilft, Code zu schreiben, der nach Ihren Bedürfnissen umformbar und skalierbar ist. Nichtsdestotrotz habe ich in der Produktion großartige Leistung davon bekommen.

Abgesehen davon, dass Sie versuchen, Ihren Benchmark unter Linux mit native socket transport auszuführen, wiederhole ich, was @marcospereira gesagt hat, um Ihren Benchmark ein paar Mal auszuführen, ohne Ihren Play Server zu stoppen. Die Standardabweichung in Ihren Play-Benchmark-Ergebnissen scheint ungewöhnlich hoch zu sein (Durchschnittswerte von 1 bei SD-Werten von 2,2), was darauf hindeutet, dass JIT möglicherweise Ihren Code noch nicht vollständig für Sie optimiert hat.