Pull to refresh

Comments 30

Всё это очень круто, только event-loop написан на C (libuv) и парсер http тоже сишный (picohttpparser). Хотя наверное просто дернуть callback в питоне миллион раз в секунду — уже круто (я сам фанат питона, просто не люблю желтые заголовки).

Ну строго говоря CPython тоже на си написан, так можно много до чего договориться. Тут наверно можно поставить вопрос так: а можно ли бизнес-логику на python обернуть производительным асинхронным http-движком с наименьшей долей накладных расходов? Понятно что для hello world доля накладных расходов в 99% это нормально, но для чего-то более сложного хотелось бы иметь пространство для оптимизации своего кода, а не чужого.

Сможет ли Питон прожевать миллион запросов в секунду?

и
Japronto практически полностью написан на Си. Парсер, протокол, connection reaper, маршрутизатор, request- и response-объекты реализованы в виде расширений на Си.


как-то не коррелируют между собой.
Это же перевод статьи «A million requests per second with Python»
«Это же перевод» — это такая универсальная отмазка которая оправдывает размещение на сайте любой фигни?
Здорово, что разработчики смогли заставить работать «Hello world» сервер с такой производительностью. Только Я бы сравнил реализации какого-нибудь реального REST-сервиса, реализованного на разных языках программирования.
Вспоминается история проекта Pyston. Разработчики из Dropbox делали свою реализацию Python с JIT-компиляцией. На синтетических тестах Pyston на 95% быстрее чем стандартный CPython. Но на реальном web-сервере прирост составляет всего на 10%. Из-за этого Dropbox больше не финансирует этот проект (к моему величайшему сожалению).
какого-нибудь реального REST-сервиса

На реальном REST-сервисе можно проверит скорость работы БД, никак не языка.

На реальном REST-сервисе можно проверит скорость работы БД, никак не языка.

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

UFO just landed and posted this here
Затея-то интересная, но добавьте к тесту конкатенацию строки из питона (не просто вывести hello world, а прибавить что-то) и количество обрабатываемых запросов сразу упадёт процентов на 15. Что говорит о том что передача ответа, скорее всего вряд ли может являться «бутылочным горлышком», сайты и сервисы же делают не для того чтобы статичные строки передавать, а выполнять какую-то логику.

Я бы предложил запрос в БД сделать и сериализовать ответ в json.

сайты и сервисы же делают не для того чтобы статичные строки передавать, а выполнять какую-то логику.

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

Обычно эту задачу выполняет CDN или обратный прокси. Зачем делать то же самое уже на языке Python?

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

Ну, в nginx есть модуль для инвалидации кэша по запросу.

Ну, в nginx есть модуль для инвалидации кэша по запросу.

Он сможет убрать из кэша всех сотрудников одного отдела, если отделу администратор поменял название в веб админке, при этом не трогая кэши всех остальных сотрудников? Ну или предположим что мы строим сложную HTML страницу, собирая данные из десятков таблиц (да ещё и разных хранилищь/баз данных), и знаем что нам нужно обновить только одну сущность из базы, а остальные можно взять из кэша. Можно ли это сделать на уровне прокси?


Я не спорю, что-то можно сделать на уровне проксей и т.п., но далеко не все что можно сделать с помощью кэшей на беке.

Я верно что понял HTTP Pipelining отключен, например в хроме, фаерфоксе и ее не рекомендуют использовать?
https://www.chromium.org/developers/design-documents/network-stack/http-pipelining
http://kb.mozillazine.org/Network.http.pipelining
В связи с этим — интересно было бы увидеть более приближенные к реальности результаты тестов, без Pipelining.
Ну тут как бы это, надо проводить какие-то честные сравнения чтоль. А то питон бафнули, библиотеку на сях написали (почти целиком), а потом скоростью меряемся.

Код примера
package main

import . "fmt"
import "github.com/valyala/fasthttp"

func HandleFastHTTP(ctx *fasthttp.RequestCtx) {
  Fprintf(ctx, "Hello, world! Requested path is %q.", ctx.Path())
}

func main() {
  fasthttp.ListenAndServe(":8000", HandleFastHTTP)
}


В примере еще и с какой-то там дефолтной подстановкой строки.

Результат на том же тесте, что и у автора статьи
image
Есть еще гошный фреймворк Iris, судя по бенчмаркам шустрее fasthttp.
В переводных статьях эта ссылка даётся самим автором и видна под рейтингом поста, справа от зелёных стрелочек.
Вообще, можно устроить мощный такой холивар, описав ТЗ некоего относительно простого веб-приложения, и предлагая разработчикам разных «религий» написать его на своем языке программирования. Ну и, к нему несколько объективных тестов, соответственно.

Какой же это будет холивар, если есть объективные критерии сравнения? :-)

Будет холивар о том, насколько корректно измерять производительность именно этими тестами.
Будет холивар о том, является ли это холиваром.
Было бы круто, только если бы HTTP Pipelining поддерживался современными браузерами…
Взято с Википедии:
Браузеры Mozilla ( Mozilla Firefox, SeaMonkey and Camino) поддерживают pipelining, но эта функция выключена по умолчанию.
Google Chrome убрал поддержку pipelining из-за багов и проблем с «плохими» серверами.
Internet Explorer 11 не поддерживает pipelining

Так что как мне кажется, это будет полезно только для очень нагруженных микросервисов (где разработчики сами могут включить pipelining)
Если я правильно понял назначение Pipelining, то могу сказать, что сейчас вместо него все используют Вебсокеты.

Нет, вместо него сейчас используют HTTP/2

Sign up to leave a comment.