18.06.2016 23:29
deviator 54 9700 Источник
Доброго времени суток, хабр!

Так как мне скоро предстоит разрабатывать веб-приложение, а писать на интерпретирумых языках как-то нет желания, тем более, что есть такие ЯП как D и Go, возникло желание сравнить их производительность при работе с веб (в сети не нашёл тестов, которые были бы свежими). Для D это vibe.d, а для Go, как я понял, не используются фреймворки. Так как Go я знаю менее чем «никак» решил не выпендриваться: тестовые приложения просто отдают страничку с некоторым текстом (ни баз данных, ни сложного роутинга, ни изображений).

Нагрузка давалась с помощью Apache Benchmark.



Приложение на D это стандартное vibe приложение, нас будут интересовать только
source/app.d
import vibe.d;

shared static this()
{
    auto settings = new HTTPServerSettings;
    settings.options |= HTTPServerOption.distribute; // без этой настройки vibe однопоточен
    settings.port = 8101;
    settings.bindAddresses = ["::1", "127.0.0.1"];

    listenHTTP(settings, &index);
}

void index(HTTPServerRequest req, HTTPServerResponse res)
{
    auto var = "hello habr";
    res.render!("index.dt",var);
}
и
views/index.dt
html
  head
  body
    h1 Привет, Хабр!

    p D is a systems programming language with C-like syntax.

    = var
сборка: dub build --build=release

В Go приложении нас интересуют соответствующие файлы
site_test_go.go
package main

import (
    "html/template"
    "net/http"
)

type Page struct {
    Var string
}

func indexViewer(w http.ResponseWriter, r *http.Request) {
    p := Page{Var:"hello habr"}
    t, _ := template.ParseFiles("index.html")
    t.Execute(w, p)
}

func main() {
    http.HandleFunc("/", indexViewer);
    http.ListenAndServe(":8100", nil);
}

и
index.html
<h1>Привет, Хабр!</h1>

<p>Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.</p>

<div>
    {{.Var}}
</div>

сборка: go build site_test_go.go

Нагрузка: ab -c200 -n50000 http://localhost:8101/ (8100 для site_test_go)

Начнём

Apache Benchmark

Немного различный код index файлов был сделан для соответствия Document Length (видимо vibe передаёт что-то в заголовке ответа)
dlang golang
Server Software: vibe.d/0.7.28
Server Hostname: localhost
Server Port: 8101

Document Path: /
Document Length: 182 bytes

Concurrency Level: 200
Time taken for tests: 4.481 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 16450000 bytes
HTML transferred: 9100000 bytes
Requests per second: 11157.90 [#/sec] (mean)
Time per request: 17.925 [ms] (mean)
Time per request: 0.090 [ms] (mean, across all concurrent requests)
Transfer rate: 3584.91 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 8 33.2 7 1009
Processing: 2 10 3.7 9 207
Waiting: 1 8 3.5 7 205
Total: 3 18 33.4 17 1020

Percentage of the requests served within a certain time (ms)
50% 17
66% 18
75% 18
80% 18
90% 19
95% 23
98% 29
99% 30
100% 1020 (longest request)

 Server Software:
Server Hostname: localhost
Server Port: 8100

Document Path: /
Document Length: 182 bytes

Concurrency Level: 200
Time taken for tests: 4.263 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 14950000 bytes
HTML transferred: 9100000 bytes
Requests per second: 11728.36 [#/sec] (mean)
Time per request: 17.053 [ms] (mean)
Time per request: 0.085 [ms] (mean, across all concurrent requests)
Transfer rate: 3424.59 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 8 14.9 7 1011
Processing: 2 9 2.3 9 211
Waiting: 1 7 2.4 7 210
Total: 10 17 15.1 16 1020

Percentage of the requests served within a certain time (ms)
50% 16
66% 17
75% 18
80% 18
90% 19
95% 20
98% 21
99% 22
100% 1020 (longest request)


Память

Замер производился с помощью gnome-system-monitor
dlang golang
до первого запроса memory: 680.0KiB
virtual: 907.5MiB
resident: 10.2MiB
writable: 343.3MiB
shared: 9.5MiB
 memory: 888.0KiB
virtual: 110.8MiB
resident: 5.2MiB
writable: 35.7MiB
shared: 4.4MiB
после запуска ab memory: 19.2MiB
virtual: 9.5GiB
resident: 28.7MiB
writable: 9.0GiB
shared: 9.6MiB
 memory: 6.5MiB
virtual: 1.3GiB
resident: 12.5MiB
writable: 1.0GiB
shared: 5.9MiB


Загрузка процессора

Замер производился с помощью gnome-system-monitor
dlang golang


Версии ПО

apr-util-1.5.4-1.fc22.x86_64

DMD64 D Compiler v2.071.0
DUB version 0.9.25, built on May 22 2016
vibe 0.7.28

go version go1.5.4 linux/amd64

Выводы

Производительность инструментов практически не различается (чему я удивлён, на самом деле).
Огорчило потребление памяти у D: практически в 3 раза больше чем у Go.
Исходя из графиков загруженности процессора, можно сделать вывод: планировщик заданий в Go устроен лучше — сразу распределяет нагрузку на ядра поровну, но в среднем загрузка ЦП у D ниже.
Стоит отметить, что приложение на D компилируется дольше (для веб разработки это может быть неприятным моментом).

PS: это мой первый эксперимент с производительностью веб (вообще пока не хорошо с веб знаком), так что буду очень рад, если вы укажите на ошибки в способе измерения и/или начальных условиях =)

для любителей языка D
группа в ВК
группа в Telegram
группа в Telegram (англ)


UPD:
Вот тут я понял, наверное, самоую большую ошибку, во всей этой проверке. vibe-d использует libevent2 и в этом тесте упирается производительностью именно в него (судя по результатам valgrind/callgrind). А go, как я понял, имеет собственную реализацию event-loop'а, причём сторонние библиотеки даже лучше по производительности чем из коробки (не понял как скомпилировать go, чтобы символы были в исполняемом файле для valgrind, go build -ldflags "-w" -gcflags "-N -l" не помогло).

Но всё-равно, тест конфигураций «из коробки», лично для меня был интересен.
Поделиться с друзьями
-->

Комментарии (54)


  1. Moxa
    19.06.2016 03:17
    #9662922

    а можно еще раз запустить бенчмарк, только с keep-alive'ом?
    ab -k -c 200 -n 50000…


    1. deviator
      19.06.2016 04:11
      #9662936

      Не совсем понимаю значение, этого флага: если соединение остаётся поднятым сервер должен меньше работы выполнять?
      Когда соединение остаётся открытым? Например если я установлю связь с сервером через websocket?

      Прогнал такой тест: ab -k -c500 -n100000 http://localhost:8100/

      dlang
      Concurrency Level: 500
      Time taken for tests: 1.654 seconds
      Complete requests: 100000
      Failed requests: 0
      Keep-Alive requests: 100000
      Total transferred: 35300000 bytes
      HTML transferred: 18200000 bytes
      Requests per second: 60450.25 [#/sec] (mean)
      Time per request: 8.271 [ms] (mean)
      Time per request: 0.017 [ms] (mean, across all concurrent requests)
      Transfer rate: 20838.81 [Kbytes/sec] received

      Connection Times (ms)
      min mean[+/-sd] median max
      Connect: 0 0 2.1 0 50
      Processing: 0 8 14.0 2 178
      Waiting: 0 8 14.0 2 178
      Total: 0 8 14.6 2 178

      Percentage of the requests served within a certain time (ms)
      50% 2
      66% 8
      75% 14
      80% 15
      90% 19
      95% 22
      98% 32
      99% 92
      100% 178 (longest request)


      1. deviator
        19.06.2016 04:16
        #9662938

        А учитывая загрузку процессора, так совсем впереди


        Слева D, справа Go


        1. Moxa
          19.06.2016 12:04
          #9663104
          +1

          Без кипалайва тестировать не интересно — упираемся в скорость открытия соединения. Используется он почти всегда, это часть стандарта http 1.1, браузер открывает страницу, получается хтмл, а затем, через уже открытый коннекшен, запрашивает картинки, стили, скрипты, следующую страницу… ну и чтобы не упираться в одно соединение, браузер открывает несколько.

          Похоже, пора переходить на wrk и увеличивать количество запросов, ab все равно не выдаст больше ~120к рпс


        1. TrueMaker
          25.06.2016 11:37
          #9674406

          Можете попробовать Go1.7Beta2? В 1.7 используется новый компилятор и очень хорошо оптимизирована внутренняя библиотека в некоторых случаях код работает чуть ли не в 2 раза быстрее. Ну и GC стал оптимальнее. Шустрее алгоритмически, и меньше циклов CPU кушает в некоторых других моментах ожидания.


      1. lexore
        20.06.2016 18:12
        #9665236

        Как вы видимо уже сами поняли, без keepalive это превращается в тест обработчиков соединений.


  1. webmasterx
    19.06.2016 03:18
    #9662924
    +1

    может быть стоило увеличить время выполнения тестов? 4 секунды мне кажется маловато. и к тому же это получается сравнение производительности встроенных веб-серверов


    1. deviator
      19.06.2016 04:22
      #9662942

      4 секунды мало, потому что сборщик мусора не успевает включиться в бой?
      А вторую часть не до конца понял. Веб-сервера не встроены ни в D ни в Go — это библиотечные реализации. В целом я их хотел их сравнить: кто шустрее, меньше памяти ест, процессор грузит. Или вы имели ввиду что ещё можно что-то сравнивать в производительности веб приложений? Я только начинаю этим заниматься, поэтому не знаю, какие ещё могут быть критерии.


      1. webmasterx
        19.06.2016 05:15
        #9662954

        4 секунды мало так как помимо ab у вас работают еще и другие приложения ( как я понимаю, тесты делались на десктопе), и они могли давать дополнительную нагрузку
        а еще самое главное — замеров надо делать несколько и брать среднее от них.

        библиотечные реализации

        Исправлюсь — сравнение производительности библиотечных реализаций. Не знаю, пользуются ли библиотечными реализации веб-серверов Go и D в продакшине


      1. Hello1
        19.06.2016 11:16
        #9663066
        +1

        Веб-сервера не встроены ни в D ни в Go — это библиотечные реализации

        В go пакеты из стандартной библиотеки не всегда самые быстрые и функциональные. К примеру для websocket используют github.com/gorilla/websocket. Про быструю реализацию http уже написал @OlegFX


      1. xabesawiv
        20.06.2016 18:37
        #9665282

        Ну тогда бы стоило смотреть на fasthttp для Go.


        1. TrueMaker
          25.06.2016 11:39
          #9674410

          Ну тогда D будет в полных аутсайдерах, таки разница в производительности чуть ли не в 10 раз.


  1. grossws
    19.06.2016 04:39
    #9662948
    +6

    Извиняюсь, вы сравнивали скорость работы существенно разных шаблонизаторов или что-то ещё?


    1. deviator
      19.06.2016 09:38
      #9663024
      -1

      Мне кажется шаблонизатор тут малую роль играет, там очень мало кода (подставляется лишь 1 переменная в коротком шаблоне). Я всё-таки пытался сравнить именно работу остальной части приложений.


      1. grossws
        19.06.2016 21:07
        #9663770

        При таких "кажется" надо измерять. Ни там, ни там не используется кэширование шаблонов после парсинга, как оно рекомендуется ибо эта стадия обычно довольно дорогая, хотя в случае html/template может быть относительно дешевой относительно шаблонизатора vibe.d, который более-менее сопоставим с jade/slim по функциональности.


  1. OlegFX
    19.06.2016 07:15
    #9662978

    Если вас интересует именно скорость и память — попробуйте FastHTTP: github.com/valyala/fasthttp


  1. gotlium
    19.06.2016 08:06
    #9662984

    Попробуйте вместе с ab использовать так же и wrk. Например: wrk -t100 -c500 -d30s http://127.0.0.1:8000/. С помощью wrk можно задать продолжительность тестирования, а так же написать на lua собственный сценарий.
    В плане Go можно попробовать использовать: https://github.com/valyala/fasthttp, https://github.com/celrenheit/lion, https://github.com/labstack/echo
    Потребление памяти и цпу в связке echo + fasthttp + quicktemplate должно быть ниже. Для REST-а можно заменить encoding/json на ffjson.
    В Go 1.6 планировщик более оптимизирован. Если лень ставить руками, то можно использовать gvm (https://github.com/moovweb/gvm). Таким образом сравнить производительность в разных версиях языка.


  1. vintage
    19.06.2016 08:12
    #9662990
    +3

    Вы бы исходники выложили на гитхаб — я бы вам пулреквестов накидал :-)


    vibe.d по умолчанию тянет с собой кучу мусора (всякие редисы, монги и прочий хлам), поэтому лучше явно указывать конкретные подмодули:


    dependency "vibe-d:core" version="~>0.7.23"
dependency "vibe-d:diet" version="~>0.7.23"

    import vibe.http.server;
import vibe.templ.diet;

    Сравнение получается не совсем честным — реализация на го выдаёт чуть больше текста. Это не должно существенно сказываться на скорости, тем не менее нет смысла вносить лишнюю погрешность.


    Кроме того diet шаблоны компилируются один раз при компиляции приложения. А го шаблоны судя по всему парсятся при каждом запросе — нужно кешировать результат парсинга.


    1. deviator
      19.06.2016 09:18
      #9663014
      -5

      Не думаю, что убрав так называемый «мусор» можно добиться хоть какого-нибудь прироста производительности, так как это влияет только на время компиляции, а не на работу приложения. Но на всякий случай измерил и ощутимой разницы не обнаружил (разница в пределах 5%, от запуска к запуску).

      Насчёт больше/меньше текста: значение Document Length одинаково, оба приложения отдают 182 байта.

      А вот по поводу шаблонов в го ничего сказать не могу. Может быть вы подскажите как реализовать «честное» сравнение?


      1. youlose
        19.06.2016 09:49
        #9663028
        +1

        В вашем примере:
        у D — «Total transferred: 16450000 bytes»
        у Go — «Total transferred: 14950000 bytes»
        может быть Go какие-либо заголовки не передаёт или vibe.d что-то большее передаёт (как я понимаю у него много функционала из коробки, может быть стоит что-то отключить, если есть возможность)


      1. yellow79
        19.06.2016 15:01
        #9663314
        +1

        Вынести парсинг шаблона на GO за пределы обработчика запросов

        func main() {
        t, _ := template.ParseFiles(«index.html»)
        http.HandleFunc("/", func (w http.ResponseWriter, r *http.Request) {
        p := Page{Var:«hello habr»}
        t.Execute(w, p)
        });
        http.ListenAndServe(":8100", nil);
        }


  1. kmikeru
    19.06.2016 09:39
    #9663026
    +4

    Реквестирую замеры при использовании для D компиляторов LDC и GDC.


    1. deviator
      19.06.2016 12:27
      #9663124
      +2

      Результаты сборок с ldc и gdc практически не отличаются скоростью.


      1. deviator
        19.06.2016 21:35
        #9663798
        +1

        за что минус, я не понял. скомпилировал, сравнил, ответил на вопрос…


        1. bfDeveloper
          20.06.2016 19:37
          #9665394

          Вам не верят те, кто тоже компилировал свои проекты и сравнивал. Для веба действительно не так заметно, там больше libevent работает, но имеет смысл проводить более чистый эксперимент. В реальном коде будет что оптимизировать, и тогда выбор компилятора будет вносить существенный вклад.
          И всё-таки хочется конкретных опций компилятора (inline, O3, nobounds-check вкл или выкл).
          P.S. минус не мой, не подумайте.


          1. deviator
            20.06.2016 20:54
            #9665534

            я не против минусов, только когда я понимаю за что
            по сути вы правы, надо было приводить все параметры
            все 3 варианта собирались с помощью dub --build=release

            ps: а насчёт libevent я добавил в текст статьи ещё когда проверял сборки с ldc и gdc


  1. AterCattus
    19.06.2016 14:50
    #9663288

    Странно, что так отличается от довольно популярной тестилки
    https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=fortune&l=cnc


    1. deviator
      19.06.2016 17:41
      #9663508

      Вот что я искал, перед тем как писать эту статью…


    1. deviator
      21.06.2016 19:18
      #9667612

      Нашёл один момент
      vibe 0.7.28 вышел 27 февраля (hot fix версия), а этот тест производился 25 февраля
      возможно эти 2 бага сильно влияли на производительность


      1. mwizard
        21.06.2016 19:20
        #9667616

        Баги влияли на производительность в положительную сторону?


      1. youlose
        21.06.2016 19:37
        #9667654

        https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/frameworks/D/vibed

        The tests were run with:

        Vibe.D v0.7.19

        P.S. а в самих файлах в зависимостях 0.7.28


        1. deviator
          21.06.2016 20:34
          #9667736

          для тестов использовалась 27 версия, история


  1. alemiks
    19.06.2016 15:44
    #9663366

    для Go, как я понял, не используются фреймворки

    в смысле не используются? Martini, gin-gonic, revel, beego это что?


    1. vitalybaev
      19.06.2016 16:00
      #9663388

      Martini умер


      1. xabesawiv
        20.06.2016 18:40
        #9665294

        Он прост как пробка. Там нечего развивать.


    1. deviator
      19.06.2016 17:32
      #9663498
      -1

      тут первый комментарий, второй пункт, хотя, возможно, чисто субъективное мнение отвечающего, я подумал, что так и обстоят дела


    1. xabesawiv
      20.06.2016 18:40
      #9665292

      Ваша информация устарела лет на пять.

      gizmo, go-micro, gocircuit, h2, Kite, Beego, Gin, Goji, Gorilla, Martini, Negroni, Revel, echo


  1. vitalvas
    19.06.2016 17:34
    #9663500
    -5

    Ваш тест, как минимум не корректный.

    Собрать Ваш код на D не удалось. (та и время тратить не хотел)

    Проведя тест(test1.go) на среднестатистическом сервере, у меня получилось ~16970.795 rps

    Первое что бросается в глаза — отсутствие url роутера.
    Без роутера(test2.go) получаем +~88.51 rps.

    Во время сборки кода на D, заметил интересную строку: Compiling diet template 'index.dt'…
    Будем считать, что D загружает шаблон в память.
    Третей тест (test3.go) показывает ~55588.8625 rps, что дает ~+38618 rps

    Исходя из Ваших тестов, возьмем среднепальцеве число производительности кода D в 17000 rps.
    Если этот код на D загружает все в память, то этот тест показывает, на сколько в хлам GO разбивает производительность D. Это выглядит как 17000 vs 55000 rps

    Сам код: github.com/vitalvas/go-benchmark


    1. deviator
      19.06.2016 17:39
      #9663506
      +2

      Правильно ли я понял, что Вы сейчас прооперировали среднепальцевыми значениями, даже не запустив код (ни мой, ни тот, корректный, который Вы написали)?


      1. vitalvas
        19.06.2016 17:45
        #9663520
        -3

        Не правильно. Не запускал только код на D.
        На Go запускал как и Ваш, так и свой. Результаты тестов в репозиторию

        Хотя теоретически D — должен работать быстрее GO.
        В go пожертвовали некоторою производительностью для простоты.


        1. deviator
          19.06.2016 18:41
          #9663594

          Прошу заметить, что я не пытался сделать максимально производительный или правильный код, а пытался сделать эквивалентный (в силу своих познаний) код на двух разных языках.

          Хотя теоретически D — должен работать быстрее GO.

          мне хотелось поднять вопрос не «кто быстрее в целом» (который я для других языков уже пытался поднять), а именно для веб… и тут, по всей видимости, компилятор и язык не будут играть большой роли, а будут играть: подход к сборке мусора, архитектура библиотеки (в vibe радуют compile-time шаблоны страниц), алгоритмы роутинга и тд

          Хотелось проверить всё в целом, в сумме (кроме работы с базой данных). На самом деле я думал D проиграет в веб значительно, просто было интересно во сколько раз, но оказалось не всё так просто.


    1. vintage
      19.06.2016 22:35
      #9663870
      +2

      Для тех, кто всё же захочет собрать код на D, последовательность действий такова:


      1. Создаём проект на VibeD: dub init go-vs-d vibe.d
      2. Для студии можем сгенерить солюшен: dub generate visuald
      3. Исходники помещаем в source/app.d
      4. Шаблоны в views/
      5. Билдим и запускаем: dub --build=release


  1. geekmetwice
    19.06.2016 21:46
    #9663822
    -1

    Когда речь идёт о сравнении языков по скорости работы, это напоминает сравнение машин по глубине протектора — ну хорошо, у кого-то на 2см длиннее, что это даёт?? (кроме чувства «я пишу на лучшем языке») На мой взгляд, сравнение должно идти в совсем других плоскостях:
    1. Начинаем сравнивать только когда выявлены реально важные критерии. Например, где-то важно потребление памяти, где-то — поддерживаемость или «интуитивная понятность» (напр. у VBScript). Критерии «от балды» — не интересны, особенно когда сравнивают МИКРОсекунды в вебе, где страницу можно ждать секундами! К чему там скорость??
    2. До сих пор один из важных критериев языков — поддерживаемость, которая вытекает из простоты и выразительная мощность, которая должна соблюдать баланс с простотой. Писать на очень простом языке — нудно (спросите джабистов), на оч выразительном — мозг вывихнешь (любители Хаскеля не поняли вопроса :) ). Мне кажется, у D в этом плане хороший баланс — море простых конструкций, одновременно с мощной библиотекой.

    Поэтому «для веба» я бы сразу взял Ди и критерием была бы быстрота написания и понятность кода. Веб — это не место для экономии микросекунд или, ещё смешнее, экономия килобайт в ГИГАБАЙТОВЫХ серверах. Есть нагрузка — почти всегда дешевле «оптимизировать вширь железом», чем насиловать программиста «ну ещё пару мегабайт!». Особенно зная, что есть не так много разных способов написания алгоритма или использования библиотеки (т.е. не всегда есть возможность что-то вообще выжать).


    1. barsulka
      20.06.2016 08:05
      #9664288
      +6

      Веб — это не место для экономии микросекунд

      Вы хоть одно нагруженное приложение в жизни писали?


      1. geekmetwice
        20.06.2016 15:34
        #9664948
        -2

        А давайте вы перейдёте от подростковых переходов на личности сразу к аргументам? Расскажите мне о нагрузках типичного форума (а-ля RSDN) и удивите какой-нибудь 50-блэйдовой фермой на ксеонах!


        1. barsulka
          20.06.2016 17:25
          #9665154
          +4

          Неспособность ответить на прямо поставленный короткий вопрос как раз и выдает подростковое мышление.

          Я не могу рассказывать о нагрузках типичного форума а-ля rsdn, потому что не имею отношения к разработке типичных форумов а-ля rdsn. Зато имею отношение к разработке нескольких продуктов с нагрузками в тысячи и десятки тысяч запросов в секунду. И не по наслышке знаю, как сэкономленные где-нибудь в дальнем углу кода 10-20 миллисекунд могут сэкономить десяток тысяч долларов в месяц на железе.

          Поскольку мне было интересно, откуда взялось ваше утверждение, я задал простой вопрос — «Вы хоть одно нагруженное приложение в жизни писали?». Он короткий и не несёт в себе никаких эмоций.

          Как я могу предположить теперь — нет, не писали. А если я прав (если я прав) — получается, в предмете вы ни черта не понимаете, о чём говорите — не знаете, но Веское Мнение имеете.

          П — Профессионализм.


          1. xabesawiv
            20.06.2016 18:37
            #9665288

            Ну я писал приложения где нужно экономить каждый такт.
            И должен вам сказать — это такая страшная редкость.
            И если уж тестировать Go на возможность написания именно таких приложений, то тестировать грамотно — используя fasthttp.


          1. geekmetwice
            21.06.2016 01:43
            #9665834
            -1

            Посмотрите лучше на Ж — пиЖонство. Каким-то чудом вы попали в один-на-миллион высоконагруженный проект и уже готовы лопнуть от тщеславия, тыкая всем какие они «непросвещённые». Ну хорошо, оставайтесь при своём высокомерии, экономьте микросекунды и упивайтесь ассемблером — говорить с вами как с человеком нет никакого желания.


            1. barsulka
              21.06.2016 23:11
              #9667986
              +4

              Жаль, ведь вы были прекрасным собеседником. Умудряетесь в буквах видеть эмоции — подростковые выпады, высокомерие, пижонство, — я в восторге.

              Я иной раз думаю всякое. Вот как так получается, что Microsoft Word, который в 1999 году работал на 486м процессоре, влезая в 16 мегабайт памяти, сейчас отжирает половину ресурсов и еле ворочается на восьмиядерном ксеоне? Что за индус мог написать калькулятор для убунты, который для своей работы тянет сотню пакетов ради красивой отрисовки кнопочек? Какая такая волшебная сила превращает танчики, которые работали на денди, в многомегабайтного монстра, за полчаса высасывающего батарейку на топовом смартфоне? Что за мировой заговор новостных сайтов, которые состоят из текста и картинок и при этом отжирают по гигабайту в браузере?

              И периодически убеждаюсь, что нет ни чудес, ни волшебства, ни индусов, ни масонского заговора. Есть лишь Правильные программисты, которые презирают всяких пижонов, заботящихся о производительности своих продуктов. Правильным программистам не нужны бенчмарки. Им не надо знать, что быстрее в конкретной задаче — D, Go, плюсы или вообще пхп. Это всё вторично.

              Скорость работы везде и особенно в вебе — для пижонов. Ведь если вы пишете не один-на-миллион поисковик/соцсеть/биллинг, а сайт «Сады и парки Норильска», то можно это делать спустя рукава и как-нибудь. А когда всё начинает тупить — так это не кодер неподходящий инструмент выбрал, это хостер кривой. Голову включать не надо, надо масштабироваться железом.

              Аминь.


  1. evocatus
    20.06.2016 16:38
    #9665092
    +3

    Этот глупый вопрос я задаю в каждом посте про любые бенчмарки:

    Вы убедились, что частота процессора не менялась на протяжении всех тестов?


  1. pftbest
    20.06.2016 17:31
    #9665160
    +1

    непонятно почему 

    t, _ := template.ParseFiles("index.html")
    пересоздается на каждый запрос. Разве вы так будете писать в реальном проекте? А если нет, то зачем такое мерять?


  1. blind_oracle
    20.06.2016 19:10
    #9665346
    -2

    В Go на FastHTTP я получал около 170к запросов в секунду на Xeon E5620 при практически 100% загрузке всех ядер. А данный бенчмарк считаю некорректным по многим причинам, часть которых озвучена выше — абсолютно неинформативно.


  1. ik62
    23.06.2016 23:48
    #9672554

    По поводу памяти… не знаю как vibe-d ею управляет(вполне возможно что там полностью своё упроавление) но стандартный GC может быть ограничен в своих аппетитах. Детали тут:
    https://dlang.org/spec/garbage.html


  1. erlyvideo
    26.06.2016 08:17
    #9675060
    +1

    «планировщик заданий в Go устроен лучше — сразу распределяет нагрузку на ядра поровну»

    Это неверное утверждение. Вопрос раскидывания файберов по ядрам очень сложный и на сегодняшний день я скорее считаю, что правильнее, когда планировщик загружает ядра ближе к 85%, оставляя свободные ядра.

    Это дает возможность линуксу запустить что-то ещё на сервере.