Почему Javascript входит в топ-2 Techempower?

Недавно на github был задан этот вопрос, вызванный появлением новой платформы javascript, близкой к вершине промежуточного рейтинга Techempower. Эта платформа Just(js) является тем, над чем я работаю в качестве пет-проекта уже некоторое время. Здесь я попытаюсь дать краткий ответ на вопрос, а в ближайшие недели дам дополнительные подробности об этом и о самой платформе.

Если вы обнаружите, читая это, что вам становится жарко, пожалуйста, ознакомьтесь с предостережениями ниже, прежде чем двигаться дальше.

Что такое рейтинг Techempower?

Рейтинги Techempower проводятся с 2013 года и стали очень полезным инструментом по ряду причин.

• Это отличное место, чтобы получить хороший обзор различных фреймворков, доступных на разных языках и на разных платформах.

• Он охватывает довольно хороший спектр основных задач, которые должен выполнять любой веб-сервис. Определенно есть большие пробелы, но у людей из Techempower есть планы по их дальнейшему развитию.

• Он дает некоторую полезную информацию о том, в чем заключаются относительные сильные и слабые стороны различных платформ и языков.

• Он оказывает влияние на выявление слабых сторон и направляет усилия во многих из этих сред для повышения производительности. Он показывает постоянное улучшение средней производительности конкурирующих фреймворков. Хотя все такие соревнования следует воспринимать с большим недоверием, они действительно влияют на эффективность вождения. Совокупный балл пяти лучших фреймворков улучшился на 62% с 24 тыс. в 16-м раунде до 39 тыс. в 19-м раунде, и в настоящее время он составляет 48 тыс. в последнем промежуточном раунде.

Что такое Just(js)?

Just(js) — это небольшой, простой и, надеюсь, эффективный серверный javascript-фреймворк, построенный поверх движка javascript google v8. В настоящее время он поддерживает только Linux x86_64. Он всё ещё довольно далёк от стабильной бета-версии, но я не ожидаю каких-либо больших изменений в функциональности, а кодовая база очень мала (примерно 5 тысяч строк C++ и javascript), поэтому не должно быть огромного объёма работы, чтобы довести его до какого-то стабильного состояния.

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

• иметь небольшую кодовую базу и как можно меньше исходных файлов (т. е. уменьшить когнитивную нагрузку)

• отдавать предпочтение вызовам функций в стиле C, а не сложным объектно-ориентированным структурам

• быть эффективным при выполнении и использовании памяти

• быть только на одной платформе, что означает, что код легче понять без множества макросов и вездесущих #ifdef-ов

• быть простым для понимания и модификации для любого, у кого есть базовые знания C / C ++ и системного API Linux.

• быть полезной платформой для получения дополнительной информации о движке v8 и системного API Linux.

• быть легко расширяемым и настраиваемым для встраивания

• продемонстрировать, что javascript может быть правильным выбором для создания высокопроизводительного программного обеспечения системного уровня и сетевых серверов.

Просто покажите мне уже результаты!

Хорошо, хорошо! Вот 10 лучших фреймворков из последнего промежуточного запуска Techempower. Пожалуйста, прочитайте предостережения, чтобы понять, почему эти результаты следует воспринимать с небольшим скептицизмом.

Вы можете посмотреть полные результаты здесь.

Есть несколько вещей, которые мы можем отметить:

• Как и следовало ожидать, в верхних строчках рейтинга преобладают фреймворки C++ и Rust.

• Just(js) отстает от самой производительной среды C++, набрав 95 % общего балла и на 4 % опережая следующую по производительности среду C++.

• Just(js) на 10% и 13% лучше, чем самые производительные фреймворки Rust.

• По сравнению с другими языками «высокого уровня» оценка Just(js) на 32% выше, чем у самых эффективных фреймворков C#/.Net и Java.

• Just(js) оценивается на 40% выше, чем самый эффективный фреймворк Go.

При сравнении с другими средами Javascript разница становится довольно существенной.

• Just(js) оценивается в 2 раза выше, чем следующая по производительности платформа Javascript, es4x, основанная на Vert.x и JVM.

• Его оценка в 5-6 раз выше, чем у лучших фреймворков Javascript на основе Node.js.

Как Just(js) достигает этих результатов?

Ну, это было много тяжелой работы. Мои первоначальные попытки, которые я сравнивал на своем ноутбуке с лучшими фреймворками C++, Rust и Javascript, были так себе.

Я видел только 50% от лучшей производительности с особенно плохими оценками в тестах с несколькими запросами, обновлениями и фортуной, которые являются наиболее соответствующими реальным сценариям.

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

Постгрес API

Моя первоначальная попытка заключалась в использовании модуля C++, взаимодействующего с официальным C API libpq. Я много раз тестировал и анализировал трафик и столкнулся с узкими местами, которые не мог объяснить, поэтому решил отказаться от этого и вместо этого попытаться написать библиотеку Javascript для взаимодействия с Postgres. Позже я обнаружил (изучив исходный код других фреймворков), что существует набор исправлений для libpq, который решает эти проблемы, поэтому в будущем я могу вернуться к привязке C++.

После нескольких дней изучения документации и тестирования postgres я был доволен удивительно хорошими результатами, которые я увидел в коде Javascript, который я собрал. Мне пришлось усердно работать, чтобы обеспечить как можно меньше выделений из кучи, и внедрить множество оптимизаций, таких как возможность предварительной компиляции запросов в ArrayBuffers и использование подготовленных операторов в Postgres, что намного быстрее, чем выполнение необработанных запросов Sql.

Вот небольшой фрагмент того, как работают предварительно скомпилированные запросы:

sock.allFortunes = await compile(sock, {
  formats: [],
  sql: 'select * from Fortune',
  fields: [{ format: 1, oid: INT4OID }, { format: 0, oid: VARCHAROID }],
  name: 's2',
  portal: '',
  maxRows: 0,
  htmlEscape: true,
  params: []
})

и как это вызывается:

const { allFortunes } = sock
allFortunes.call(() => {
  const html = getHTML(insertionSort([extra, ...allFortunes.getRows()]))
  sock.writeString(`${rHTML}${utf8Length(html)}${END}${html}`)
})

Микрооптимизация

Я также добавил некоторые дополнительные оптимизации, которые позволили мне выжать еще несколько падений производительности:

• Использование picohttpparser, который использует инструкции SSE4 для молниеносного синтаксического анализа http.

• Использование slow-json-stringify вместо нативного JSON.stringify дало небольшую, но заметную разницу по всем направлениям.

• Выполнение экранирования HTML одновременно с чтением строк из ArrayBuffers, возвращаемых из Postgres, имело большое значение в тесте Fortunes. Строки размещаются в куче v8, и если они недолговечны, их приходится собирать мусор, что сильно снижает производительность. Я признаю, что экранирование строки на уровне драйвера базы данных - это небольшой обман, поэтому я, вероятно, вернусь к этому, когда у меня будет время.

• Я заметил, что другие фреймворки используют одиночные запросы для выполнения обновлений, а не запрос для каждого обновления, и также принял этот подход. Вы можете увидеть, как это выглядит здесь.

• Мне не удалось найти достаточно быструю библиотеку HTML-шаблонов для теста Fortunes, поэтому мне нужно проделать дополнительную работу, чтобы найти для этого оптимальное решение. На данный момент html создается вручную, что опять-таки немного обманывает, но я уверен, что смогу найти что-то, что работает и обеспечивает эквивалентную производительность.

• Поскольку наборы результатов для теста Fortunes невелики, я обнаружил, что простая сортировка вставками работает быстрее, чем стандартная Array.sort в Javascript/v8.

Окружающая среда Techempower

Компания Techempower запускает тесты на 3 серверах Dell R440, каждый из которых оснащён процессором Intel Xeon Gold 5120 с 28 потоками и выделенным сетевым адаптером Cisco 10 Гбит/с.

Тестируемый фреймворк работает на одной машине, база данных — на другой, а инструмент бенчмаркинга (использующий wrk) — на третьей. Всё работает внутри докера с использованием сети хоста, поэтому накладные расходы от этого должны быть минимальными.

Первоначальная результат

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

Я отправил свой пул-реквест, он был рассмотрен и принят, а затем с нетерпением ждал, пока серверы techempower будут проходить тесты. Общий запуск занимает около 5 дней каждый раз, поэтому я был очень разочарован, когда моя первоначальная заявка не удалась во время производственного запуска. Это было связано с тем, что DNS в производственной среде работал иначе, чем в локальной системе techempower, и мой код не обрабатывал это правильно.

Я внес некоторые изменения в код DNS, чтобы использовать /etc/resolv.conf и /etc/hosts для определения IP-адреса базы данных, как только я понял, что производственная среда использует параметр докера --add-host для ввода IP-адреса базы данных в файл контейнера /etc/hosts.

К счастью, после некоторого беспокойного ожидания тесты в следующий раз прошли успешно, но я был немного разочарован, увидев, что Just(js) занял лишь 5-е место в общем зачёте, набрав примерно 70% от производительности лучших фреймворков.

После моего первоначального разочарования я решил, что это на самом деле довольно респектабельный результат, поскольку только фреймворки более низкого уровня Rust и C++ получают более высокие баллы, поэтому я сделал перерыв на несколько дней и обдумал, что может быть причиной несоответствия между моими локальными тестами и тестами в производственной среде.

После перерыва, я решил арендовать некоторое время на сервере с аналогичными характеристиками от Packet.com (теперь Equinix Metal), чтобы посмотреть, смогу ли я воспроизвести проблему в аналогичной среде. После долгих исследований производительности и стратегии я заметил, что существует огромное количество накладных расходов на системные вызовы. При этом преобладали вызовы pthread_mutex_lock и pthread_mutex_unlock, поэтому я решил покопаться в коде v8, чтобы посмотреть, что может быть причиной этого.

В конце концов я отследил проблему до этого кода. Кажется, что каждый раз, когда мы вызываем ArrayBuffer->GetBackingStore(), v8 использует мьютекс, чтобы избежать гонок при чтении резервной памяти. Я предполагаю, что это связано с тем, что сборщик мусора работает в отдельном потоке, но это нужно исследовать дальше. Я создал тикет в группе v8-users google и надеюсь, что смогу составить воспроизводимый отчёт о проблеме для просмотра командой v8.

В этот момент я действительно ломал голову над тем, что я мог бы сделать, но во время тестирования на сервере пакетов я заметил, что проблема усугублялась по мере того, как я использовал больше потоков. Первоначальная отправка порождала поток для каждого экземпляра сервера, поэтому я решил попробовать использовать процессы вместо потоков.

Это оказалось прорывом, на который я надеялся, и я увидел огромное улучшение на сервере пакетов по сравнению с многопоточным подходом. Я до сих пор не совсем уверен, почему это так, но я предполагаю, что куча v8 и/или GC распределяются между потоками при использовании потока для каждого изолята v8, что означает много конфликтов при чтении этих мьютексов из ArrayBuffers.

После внесения моих изменений следующий запуск Techempower показал огромное улучшение. Just(js) теперь занимает 2-е место в общем зачете и находится в пределах 5% от самой производительной среды и сохраняет свою позицию в последующих запусках.

Вы можете увидеть огромное сокращение накладных расходов на системные вызовы на этих двух графиках для теста с несколькими запросами:

Это показывает падение общего времени ЦП на 80% только из-за переключения с потоков на процессы. Надеюсь, я смогу понять, почему эта проблема возникает при использовании многопоточного подхода, поскольку он потребляет намного меньше памяти, чем отдельный процесс для каждого изолятора.

Индивидуальный тестовый анализ

Теперь давайте более подробно рассмотрим отдельные тесты и то, как Just(js) сравнивается с другими фреймворками на них. Я использовал этот действительно хороший инструмент, который позволяет нам увидеть больше деталей, чем веб-сайт techempower. Я также внёс некоторые изменения в него локально, чтобы видеть количество запросов в секунду на поток, что даёт нам лучшее представление об относительной производительности, чем необработанные числа RPS.

Я выбрал подмножество фреймворков для сравнения здесь:

• Два самых эффективных фреймворка C++ — lithium и drogon

• Два самых эффективных фреймворка Rust — ntex и may-minihttp

• Два самых эффективных фреймворка Go — fiber и fasthttp

• Два самых эффективных Java-фреймворка — jooby и wizardo-http

• Самая производительная среда C#/.Net — aspcore

• Самый эффективный PHP-фреймворк — php-ngx

• Пять самых эффективных фреймворков Javascript — Just(js), es4x, polkadot, nodejs и fastify.

Ниже я обсуждаю только необработанную пропускную способность и использование ЦП. Я надеюсь, что смогу более подробно рассказать о результатах памяти и задержки в следующем посте.

Подробнее о требованиях к тесту можно прочитать здесь.

Простой текст

Тест простого текста является самым простым и, вероятно, наименее полезным, но он даёт нам некоторое представление о производительности парсера HTTP, цикла обработки событий и сетевого API. Результаты для этого также приходят с большой оговоркой, что все самые производительные фреймворки оцениваются примерно одинаково. Это связано с тем, что сеть 10 Гбит/с насыщена 7 миллионами запросов в секунду.

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

Just(js) неожиданно оказался лучшим в этом тесте, опередив lithium (C++) на 3% по количеству запросов в секунду на поток. Он превосходит самую производительную среду Rust на 17 %, C# на 27 %, Java на 38 %, Go на 50 %, Javascript/Vert.x на 84 % и Javascript/Node.js на 93 %.

Вы можете видеть, что 5 лучших фреймворков на этом графике не используют максимальную нагрузку на ЦП. Это связано с тем, что сеть является узким местом в этом тесте. Надеемся, что в какой-то момент techempower сможет запустить тесты в более быстрой сети или перепроектировать тесты, чтобы устранить этот недостаток.

Just(js) использует только 50% доступного ЦП (65% пользователей, 35% системы) для обслуживания 7 млн запросов / передачи 10 Гб данных в секунду, что указывает на то, что теоретически он может достичь около 14 млн запросов в секунду или 20 Гб/с если 28 ядра будут использоваться полностью. Это довольно удивительные цифры для языка, который, как правило, получает много критики за то, что он не соответствует стандартам производительности, по крайней мере, на стороне сервера.

Я удивлен, что Go и Java получили такие низкие оценки в этом тесте, поэтому, возможно, есть место для улучшения реализации тестов для этих языков. Я также полагаю, что в реализации Node.js и PHP могут быть внесены некоторые оптимизации.

JSON

Тест JSON немного более реалистичен, чем простой текст, и даёт нам некоторое представление об относительной производительности сериализации JSON в тестируемых фреймворках.

В этом тесте Just(js) занимает второе место в RPS/Thread, на 9% отставая от самой производительной среды Lithium/C++. Мы также видим, что ЦП не исчерпан для Just (js) и Lithium, а Lithium использует только 85% доступного ЦП. Вполне вероятно, что в этом случае клиент бенчмаркинга максимально загружает ЦП, но techempower в настоящее время не предоставляет данные для клиента или сервера Postgres. Было бы неплохо, если бы мы могли включить эти цифры в наборы данных techempower в какой-то момент в будущем.

Для RPS/Thread оценка Just(js) на 9% ниже, чем у лучшего фреймворка C++, на 2% выше, чем у лучшего фреймворка Rust, на 5% выше, чем у лучшего фреймворка Java, на 20% выше, чем у лучших фреймворков Go и PHP, на 25% выше, чем у лучшего фреймворка C#, на 41 % выше, чем у Javascript/Vert.x, и на 64 % выше, чем у Node.js.

Одиночный запрос

Этот тест является первым, включающим базу данных, и запускает один запрос на запрос, сериализуя результаты в JSON.

В этом тесте Just(js) уступает Lithium с большим отрывом — 27%. Я не совсем понял, почему он так сильно отстаёт, поскольку он превосходит Lithium в тестах Multi-Query и Update, поэтому мне придётся провести дополнительное исследование, чтобы увидеть, смогу ли я немного улучшить результаты здесь.

Just(js) на 27% ниже лучшей среды C++, на 9% выше лучшей среды Rust, на 11% выше Java, на 21% выше Javascript/Vert.x, на 23% выше PHP, на 30% выше Go, на 32% выше C# и На 60% выше Node.js.

Вы также можете заметить, что многие фреймворки, включая Just(js), здесь не используют максимальную нагрузку на ЦП. У лучших исполнителей это, вероятно, связано с тем, что база данных заполнена до максимума, но опять же это невозможно определить, поскольку мы не получаем эти данные из наборов данных techempower. Для фреймворков с более низкой оценкой это, вероятно, связано с задержкой, вызванной драйверами libpq, используемыми для связи с Postgres.

Fortunes

Тест Fortunes, вероятно, является наиболее реалистичным и включает в себя выбор ряда строк из базы данных, динамическую вставку новой строки в набор результатов, а затем сортировку и HTML-экранирование результатов перед сериализацией в JSON.

Это тест, в котором мы видим худшую производительность Just(js) по сравнению с лучшими фреймворками C++ и Rust. Мне пришлось изрядно потрудиться, чтобы получить хорошую производительность в этом тесте, и я не уверен, что его можно еще оптимизировать. Самым большим узким местом для Just (js) здесь является необходимость экранировать каждое поле в наборе результатов по отдельности, что означает создание большого количества строк, выделенных в куче v8, которые должны быть потом очищены. Я всё ещё надеюсь, что смогу придумать лучший подход, который позволил бы экранировать все строки за один вызов в среде выполнения C++.

Just(js) занимает здесь 5-е место, на 26% отставая от самых эффективных фреймворков C++, на 16% отставая от Rust, на 13% выше Java, на 17% выше C#, на 19% выше Go, на 25% выше PHP, на 40% выше Javascript/Vert. .x и на 57% выше Node.js.

Опять же, похоже, что ряд фреймворков здесь (в частности, Lithium и Wizardo-Http) сталкиваются с узким местом. На данный момент невозможно определить, что это такое, но вряд ли это будет база данных и, скорее всего, что-то внутреннее для используемых клиентских библиотек postgres.

Множественные запросы

Тест с несколькими запросами требует, чтобы фреймворки извлекали 20 случайно выбранных строк из базы данных в виде 20 отдельных запросов, объединяли результаты и сериализовали их в JSON.

Это первый тест, в котором Just(js) лидирует. Вероятно, это связано с тем, что он использует собственный клиент postgres, написанный на Javascript, и в полной мере использует конвейерную обработку запросов. Это также позволяет избежать отправки Sync/Commit при каждом запросе. Насколько мне известно, это соответствует правилам, но я буду рад внести изменения для синхронизации при каждом запросе, если это не так.

Мы также можем видеть из этих результатов, что база данных теперь стала узким местом. Just(js) использует только 15% доступного ЦП, что означает, что он тратит 85% своего времени на бездействие, ожидая возврата результатов из базы данных. Было бы неплохо, если бы techempower могла изменить тесты в какой-то момент, чтобы предоставить больше ресурсов серверу базы данных, чтобы мы могли максимально использовать ЦП на сервере инфраструктуры и посмотреть, как тогда будут выглядеть результаты.

В этом тесте Just(js) выполняет 16 тыс. запросов в секунду на поток или 66 тыс. запросов в секунду в целом при 16% доступной вычислительной мощности.

Just(js) занимает здесь первое место, на 23% выше лучшей среды C++, на 84% выше лучшей среды Rust, на 86% выше PHP, на 87% выше Java, на 90% выше Javascript/Vert.x, на 91% выше Go, На 94 % больше, чем C#, и на 96 % больше, чем Node.js.

Это довольно поразительные цифры!

Обновления

Тест обновлений требует извлечения 20 случайно выбранных строк из базы данных в виде 20 отдельных запросов, а затем обновления каждой из этих строк новым случайным значением. Techempower позволяет группировать обновления, но не запросы, и Just(js) использует это преимущество.

Опять же, в этом тесте Just(js) имеет большое преимущество, и это, вероятно, связано с возможностью конвейерной обработки пользовательской клиентской библиотеки postgres.

Мы снова видим, что узким местом здесь является база данных, даже в большей степени, чем тест Multi-Query. Это имеет смысл, поскольку база данных должна выполнять гораздо больше работы при обновлении строк, чем при выборе, и я наблюдал в своих собственных тестах значительную нагрузку на процесс очистки Postgres.

В этом тесте Just(js) обрабатывает 14 тыс. запросов в секунду на поток или 36 тыс. запросов в секунду в целом при 9,4% доступной вычислительной мощности.

Just(js) занимает здесь первое место, на 42% выше лучшей среды C++, на 80% выше Rust, на 82% выше Java, на 85% выше Javascript/Vert.x, на 90% выше Go, на 91% выше PHP и на 98% выше Node.js.

Основные моменты и выводы

Подводя итоги, мы видим, что:

• Just(js) занимает 1-е место в простом тексте, 2-е место в JSON, 2-е место в одиночном запросе, 5-е место в рейтинге Fortunes, 1-е место в мультизапросе и 1-е место в обновлениях для запросов в секунду на поток.

• По общему составному баллу techempower он занимает 2-е место, ноздря в ноздрю с лучшими низкоуровневыми фреймворками C++ и Rust.

• Он на 6% ниже самой производительной среды C++ в целом.

• Он на 11% выше, чем самый эффективный фреймворк Rust в целом.

• По сводным оценкам он опережает все другие языковые фреймворки более высокого уровня, в 1,5 раза превосходит Java и C#, в 1,7 раза превосходит Go, в 2 раза превышает Javascript/Vert.x и PHP и более чем в 5 раз превосходит Node.js.

• По сравнению с другими высокоуровневыми языковыми фреймворками он более чем в 5 раз превосходит (Java) по обновлениям и более чем в 5 раз по множественным запросам.

Это довольно впечатляющие цифры, если не сказать больше, и они намного превзошли мои ожидания, когда я начинал это приключение. Даже принимая во внимание множество предостережений, изложенных ниже, и недостатки в текущем процессе сравнительного анализа, я уверен, что Javascript способен выстоять против самых эффективных фреймворков для сценариев, охватываемых этими тестами. Будем надеяться, что люди из techempower смогут продолжить разработку и улучшение своего процесса, и мы увидим, что Javascript продолжит сиять в будущем.

В последние месяцы я проделал огромную работу, но не хочу приписывать себе эти результаты. Невероятная производительность обусловлена потрясающей работой, проделанной командой v8, постоянно расширяющей границы того, что может сделать Javascript.

Я хотел бы сказать большое спасибо людям из Techempower за предоставление этого ресурса сообществу, а также за помощь и поддержку, которые они оказали во время моих расследований.

Надеюсь, вам было интересно читать и выводы были интересны. Если вы хотите обсудить фреймворк Just(js) или принять участие, свяжитесь с DM в Twitter или оставьте комментарий ниже.

Предостережение

Пожалуйста, отнеситесь к этим результатам и моим размышлениям выше со здоровой долей скептицизма. Есть ряд моментов, которые я хочу прояснить, чтобы избежать каких-либо споров:

• В общем, бенчмарки — это что-то вроде минного поля. Каждый эталонный тест будет иметь свои недостатки и погрешности, и помимо пиковой производительности существует целый ряд других факторов, которые необходимо оценивать при выборе платформы или фреймворка для создания веб-сервисов.

• Обсуждаемые здесь результаты techempower получены из промежуточного прогона и не являются официальными. Текущие официальные рейтинги датируются маем 2020 года, и я не уверен, когда запланирован следующий официальный раунд, но я надеюсь, что Just(js) сможет сохранить свои позиции, когда они будут опубликованы.

• В результатах также используется набор весов из 19-го раунда, которые не были скорректированы с учётом последних промежуточных результатов. Я не ожидаю, что это сильно изменит выводы, сделанные здесь.

• Я не утверждаю, что Just-JS «лучше» любой другой платформы. Он всё ещё находится на очень ранних стадиях разработки, и предстоит ещё много работы, чтобы сделать платформу более надёжной и функциональной. Его сравнивают со зрелыми и широко используемыми фреймворками, которые будут гораздо более надежными и будут иметь гораздо более продвинутые функции, чем Just (js).

Рекомендации

1. Just (js) Javascript-платформа: https://github.com/just-js

2. Введение в Techempower: https://www.techempower.com/benchmarks/#section=intro

3. Тестовая среда Techempower: https://www.techempower.com/benchmarks/#section=environment

4. Последние промежуточные результаты Techempower: https://www.techempower.com/benchmarks/#section=test&runid=4389df09-c5d3-47fb-80a3-6ea787a9a895&hw=ph&test=composite&a=2

5. TFBVis — инструмент визуализации Techempower: https://ajdust.github.io/tfbvis/

6. Правда о традиционных тестах Javascript: https://benediktmeurer.de/2016/12/16/the-truth-about-traditional-javascript-benchmarks/

7. Блог разработки V8: https://v8.dev/

8. С++ фреймворк lithium: https://github.com/matt-42/lithium

9. Ntex Rust фреймворк: https://github.com/ntex-rs/ntex

10. Asp.Net: https://github.com/aspnet

11. Jooby Java/Kotlin фреймворк: https://jooby.io/

12. Fiber Go фреймворк: https://github.com/gofiber/fiber

13. Polkadot Node.js фреймворк: https://github.com/lukeed/polkadot

14. ES4X Javascript/Vert.x фреймворк: https://github.com/reactiverse/es4x

15. Fastify Node.js фреймворк: https://www.fastify.io/

16. Патч конвейера Postgres: https://www.postgresql.org/message-id/attachment/112272/v18-0001-libpq-batch-support.patch

17. Форматы сообщений протокола Postgres: https://www.postgresql.org/docs/current/protocol-message-formats.html

18. PicoHTTPParser: https://github.com/h2o/picohttpparser

19. Equinix Metal (ранее Packet): https://www.packet.com/

20. Что нужно и чего нельзя делать при сравнительном анализе стека: http://highscalability.com/blog/2016/4/13/10-stack-benchmarking-dos-and-donts.html