2017-02-14 18 views
4

Я пытаюсь сравнить простой HTTP-сервер hello world в go. я сделал 2 испытания:Есть ли проблемы с производительностью при запуске приложений Golang на эластичном бобовом стебле?

  1. Использование Amazon EC2 - m3.medium экземпляр
  2. Использование Amazon Elastic бобовый стебель - также с одним экземпляром m3.medium

На первой установке, я мог до 18k req/sec. На втором, 1.6k req/sec.

Исходный код: (от: https://golang.org/doc/articles/wiki/)

package main 

import (
    "fmt" 
    "net/http" 
) 

func handler(w http.ResponseWriter, r *http.Request) { 
    fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:]) 
} 

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

Есть ли объяснение такой огромной разницы в производительности?

PS: тест инструмент: https://github.com/wg/wrk
Кроме того, одна важная вещь: Elastic Beanstalk всегда добавляет Nginx в качестве обратного прокси-сервера для его применения (и для Go приложений, которые я не был в состоянии удалить его) На первой установке , nginx вообще не было.

+1

Еще одно отличие состоит в том, что ваша настройка EB, скорее всего, связана с балансировкой упругих нагрузок. «Эластичная» часть означает, что она должна масштабироваться с трафиком, но я видел случаи, когда внезапный всплеск трафика (например, с тестом производительности) может вызвать проблемы до тех пор, пока ELB не поймает. – Brian

+0

Согласен с Брайаном. Для проверки гипотез вы могли сравнить 1) m3.medium за ELB, 2) m3.medium + ELB после, скажем, 15 минут устойчивой нагрузки, 3) m3.medium + ELB + nginx. – twotwotwo

+0

Моя настройка EB - это единственный экземпляр, но хорошая точка – rcmgleite

ответ

2

Короткий ответ: вы не измеряли одно и то же. В вашем собственном экземпляре вы измеряли собственный веб-сервер Go, тогда как на Beanstalk вы измеряли Nginx с родным Go Web-сервером позади.

Длинный ответ:

Если вы используете AWS Elastic Beanstalk в конфигурации Single Instance, вы получите тот же экземпляр, как будто вы используете EC2. Вы не получаете балансировщик эластичной нагрузки перед одной средой Beanstalk экземпляра.

Если вы используете Beanstalk, вы получите предварительно развернутый nginx (как вы уже сказали). Nginx оказывает значительное влияние на производительность, особенно в конфигурации с одним процессором, как с экземпляром m3.medium.

Эффект, который вы измеряли, никоим образом не вызван Beanstalk, а конфигурацией развертывания. Чтобы избежать такого снижения производительности, вы можете использовать собственный веб-сервер Go.

Чтобы поддержать мои рассуждения, я провел несколько тестов, чтобы продемонстрировать производительность. Следующие номера были сгенерированы путем запуска wrk экземпляра EC2 m3.medium в том же центре обработки данных, что и рабочая нагрузка.

Я установил одно приложение Go на Beanstalk, как на родном экземпляре EC2, и я установил сервер NGINX с той же конфигурацией, что и Beanstalk.

./wrk http://<server>/ --duration 20s --connections 300 

Beanstalk m3.medium instance DIRECT: 9230.52 Requests/sec 
Beanstalk m3.medium instance NGINX: 1502.14 Requests/sec 
EC2 m3.medium instance DIRECT:  13649.46 Requests/sec 
EC2 m3.medium instance NGINX:   2489.78 Requests/sec 
+0

Хороший ответ. Я сделал что-то подобное себе. На экземпляре EB открылся другой порт и привязали мое приложение к этому порту (минуя nginx). В результате производительность улучшилась, но не так сильно, как отдельное приложение. Вот почему я считаю, что что-то происходит с экземпляром EB. – rcmgleite