Именно таким вопросом задалась команда Почты Mail.Ru перед написанием очередного сервиса. Основная цель такого выбора — высокая эффективность процесса разработки в рамках выбранного языка/технологии. Что влияет на этот показатель?

• Производительность;
• Наличие средств отладки и профилирования;
• Большое сообщество, позволяющее быстро найти ответы на вопросы;
• Наличие стабильных библиотек и модулей, необходимых для разработки веб-приложений;
• Количество разработчиков на рынке;
• Возможность разработки в современных IDE;
• Порог вхождения в язык.

Кроме этого, разработчики приветствовали немногословность и выразительность языка. Лаконичность, безусловно, так же влияет на эффективность разработки, как отсутствие килограммовых гирь на вероятность успеха марафонца.

Исходные данные

Претенденты

Так как многие серверные микротаски нередко рождаются в клиентской части почты, то первый претендент — это, конечно, Node.js с ее родным JavaScript и V8 от Google.

После обсуждения и исходя из предпочтений внутри команды были определены остальные участники конкурса: Scala, Go и Rust.

В качестве теста производительности предлагалось написать простой HTTP-сервер, который получает от общего сервиса шаблонизации HTML и отдает клиенту. Такое задание диктуется текущими реалиями работы почты — вся шаблонизация клиентской части происходит на V8 с помощью шаблонизатора fest.

При тестировании выяснилось, что все претенденты работают примерно с одинаковой производительностью в такой постановке — все упиралось в производительность V8. Однако реализация задания не была лишней — разработка на каждом из языков позволила составить значительную часть субъективных оценок, которые так или иначе могли бы повлиять на окончательный выбор.

Итак, мы имеем два сценария. Первый — это просто приветствие по корневому URL:

GET / HTTP/1.1 Host: service.host  HTTP/1.1 200 OK  Hello World! 

Второй — приветствие клиента по его имени, переданному в пути URL:

GET /greeting/user HTTP/1.1 Host: service.host  HTTP/1.1 200 OK  Hello, user 

Окружение

Все тесты проводились на виртуальной машине VirtualBox.

Хост, MacBook Pro:

• 2,6 GHz Intel Core i5 (dual core);
• CPU Cache L1: 32 KB, L2: 256 KB, L3: 3 MB;
• 8 GB 1600 MHz DDR3.

VM:

• 4 GB RAM;
• VT-x/AMD-v, PAE/NX, KVM.

Программное обеспечение:

• CentOS 6.7 64bit;
• Go 1.5.1;
• Rustc 1.4.0;
• Scala 2.11.7, sbt 0.13.9;
• Java 1.8.0_65;
• Node 5.1.1;
• Node 0.12.7;
• nginx 1.8.0;
• wrk 4.0.0.

Помимо стандартных модулей, в примерах на Rust использовался hyper, на Scala — spray. В Go и Node.js использовались только нативные пакеты/модули.

Инструменты измерения

Производительность сервисов тестировалась при помощи следующих инструментов:

• wrk;
• ab;
• JMeter;
• boom.

В данной статье рассматриваются бенчмарки wrk и ab.

Результаты

Производительность

wrk

Ниже представлены данные пятиминутного теста, с 1000 соединений и 50 потоками:
wrk -d300s -c1000 -t50 --timeout 2s http://service.host

wrk -d300s -c1000 -t50 --timeout 2s http://service.host/greeting/hello

Столь хорошо выглядящие, но, к сожалению, неправдоподобные цифры в результатах Average Latency у Rust свидетельствуют об одной особенности, которая присутствует в модуле hyper. Все дело в том, что параметр -c в wrk говорит о количестве подключений, которые wrk откроет на каждом треде и не будет закрывать, т. е. keep-alive подключений. Hyper работает с keep-alive не совсем ожидаемо — раз, два.

Более того, если вывести через Lua-скрипт распределение запросов по тредам, отправленным wrk, мы увидим, что все запросы отправляет только один тред.

Для интересующихся Rust также стоит отметить, что эти особенности привели вот к чему.

Поэтому, чтобы тест был достоверным, было решено провести аналогичный тест, поставив перед сервисом nginx, который будет держать соединения с wrk и проксировать их в нужный сервис:

upstream u_go {     server 127.0.0.1:4002;     keepalive 1000; }  server {         listen 80;         server_name go;         access_log off;          tcp_nopush on;         tcp_nodelay on;          keepalive_timeout 300;         keepalive_requests 10000;          gzip off;         gzip_vary off;          location / {                 proxy_pass http://u_go;         } } 

wrk -d300s -c1000 -t50 --timeout 2s http://nginx.host/service

wrk -d300s -c1000 -t50 --timeout 2s http://nginx.host/service/greeting/hello

Как видно из результатов, overhead с nginx значителен, но в нашем случае нас интересует производительность сервисов, которые находятся в равных условиях, независимо от задержки nginx.

ab

Утилита от Apache ab, в отличие от wrk, не держит keep-alive соединений, поэтому nginx нам тут не пригодится. Попробуем выполнить 50 000 запросов за 10 секунд, с 256 возможными параллельными запросами.
ab -n50000 -c256 -t10 http://service.host/

ab -n50000 -c256 -t10 http://service.host/greeting/hello

Стоит отметить, что для Scala-приложения характерен некоторый «прогрев» из-за возможных оптимизаций JVM, которые происходят во время работы приложения.

Как видно, без nginx hyper в Rust по-прежнему плохо справляется даже без keep-alive соединений. А единственный, кто успел за 10 секунд обработать 50 000 запросов, был Go.

Исходный код

var cluster = require('cluster'); var numCPUs = require('os').cpus().length; var http = require("http"); var debug = require("debug")("lite"); var workers = []; var server;  cluster.on('fork', function(worker) {     workers.push(worker);      worker.on('online', function() {         debug("worker %d is online!", worker.process.pid);     });      worker.on('exit', function(code, signal) {         debug("worker %d died", worker.process.pid);     });      worker.on('error', function(err) {         debug("worker %d error: %s", worker.process.pid, err);     });      worker.on('disconnect', function() {         workers.splice(workers.indexOf(worker), 1);         debug("worker %d disconnected", worker.process.pid);     }); });  if (cluster.isMaster) {     debug("Starting pure node.js cluster");      ['SIGINT', 'SIGTERM'].forEach(function(signal) {         process.on(signal, function() {             debug("master got signal %s", signal);             process.exit(1);         });     });      for (var i = 0; i < numCPUs; i++) {         cluster.fork();     } } else {     server = http.createServer();      server.on('listening', function() {         debug("Listening %o", server._connectionKey);     });      var greetingRe = new RegExp("^\/greeting\/([a-z]+)$", "i");     server.on('request', function(req, res) {         var match;          switch (req.url) {             case "/": {                 res.statusCode = 200;                 res.statusMessage = 'OK';                 res.write("Hello World!");                 break;             }              default: {                 match = greetingRe.exec(req.url);                 res.statusCode = 200;                 res.statusMessage = 'OK';                 res.write("Hello, " + match[1]);                 }         }          res.end();     });      server.listen(8080, "127.0.0.1"); } 

package main  import (     "fmt"     "net/http"     "regexp" )  func main() {     reg := regexp.MustCompile("^/greeting/([a-z]+)$")     http.ListenAndServe(":8080", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {         switch r.URL.Path {         case "/":             fmt.Fprint(w, "Hello World!")         default:             fmt.Fprintf(w, "Hello, %s", reg.FindStringSubmatch(r.URL.Path)[1])         }     })) } 

extern crate hyper; extern crate regex;  use std::io::Write; use regex::{Regex, Captures};  use hyper::Server; use hyper::server::{Request, Response}; use hyper::net::Fresh; use hyper::uri::RequestUri::{AbsolutePath};  fn handler(req: Request, res: Response<Fresh>) {     let greeting_re = Regex::new(r"^/greeting/([a-z]+)$").unwrap();      match req.uri {         AbsolutePath(ref path) => match (&req.method, &path[..]) {             (&hyper::Get, "/") => {                 hello(&req, res);             },             _ => {                 greet(&req, res, greeting_re.captures(path).unwrap());             }         },         _ => {             not_found(&req, res);         }     }; }  fn hello(_: &Request, res: Response<Fresh>) {     let mut r = res.start().unwrap();     r.write_all(b"Hello World!").unwrap();     r.end().unwrap(); }  fn greet(_: &Request, res: Response<Fresh>, cap: Captures) {     let mut r = res.start().unwrap();     r.write_all(format!("Hello, {}", cap.at(1).unwrap()).as_bytes()).unwrap();     r.end().unwrap(); }  fn not_found(_: &Request, mut res: Response<Fresh>) {     *res.status_mut() = hyper::NotFound;     let mut r = res.start().unwrap();     r.write_all(b"Not Found\n").unwrap(); }  fn main() {     let _ = Server::http("127.0.0.1:8080").unwrap().handle(handler); } 

package lite  import akka.actor.{ActorSystem, Props} import akka.io.IO import spray.can.Http import akka.pattern.ask import akka.util.Timeout import scala.concurrent.duration._ import akka.actor.Actor import spray.routing._ import spray.http._ import MediaTypes._ import org.json4s.JsonAST._  object Boot extends App {   implicit val system = ActorSystem("on-spray-can")   val service = system.actorOf(Props[LiteActor], "demo-service")   implicit val timeout = Timeout(5.seconds)   IO(Http) ? Http.Bind(service, interface = "localhost", port = 8080) }  class LiteActor extends Actor with LiteService {   def actorRefFactory = context   def receive = runRoute(route) }  trait LiteService extends HttpService {   val route =     path("greeting" / Segment) { user =>       get {         respondWithMediaType(`text/html`) {           complete("Hello, " + user)         }       }     } ~     path("") {       get {         respondWithMediaType(`text/html`) {           complete("Hello World!")         }       }     } } 

Обобщение

Представим определенные в начале статьи критерии успеха в виде таблицы. Все претенденты имеют средства дебага и профилирования, поэтому соответствующие столбцы в таблице отсутствуют.

⁰ Производительность считалась на основании пятиминутных тестов wrk без nginx, по параметру RPS.
¹ Размер сообщества оценивался по косвенному признаку — количеству вопросов с соответствующим тегом на StackOverflow.
² Количество пакетов, индексированных на godoc.org.
³ Очень приблизительно — поиск по языкам Java, Scala на github.com.
⁴ Под многими любимую Idea плагина до сих пор нет.
⁵ По данным hh.ru.

Наглядно о размерах сообщества могут говорить вот такие графики количества вопросов по тегам за день:

Go

Rust

Scala

Node.js

Для сравнения, PHP:

Выводы

Понимая, что бенчмарки производительности — вещь достаточно зыбкая и неблагодарная, сделать какие-то однозначные выводы только на основании таких тестов сложно. Безусловно, все диктуется типом задачи, которую нужно решать, требованиями к показателям программы и другим нюансам окружения.

В нашем случае по совокупности определенных выше критериев и, так или иначе, субъективных взглядов мы выбрали Go.

Содержание субъективных оценок было намеренно опущено в этой статье, дабы не делать очередной наброс и не провоцировать холивар. Тем более что если бы такие оценки не учитывались, то по критериям, указанным выше, результат остался бы прежним.

ссылка на оригинал статьи http://habrahabr.ru/post/273341/