выдал 1.5k ответов в секунду

Ящитаю очень шустро. Но без описания методики тестирования и сырцов эти цифры ничего не стоят.

Не надоело сравнивать зеленое с горьким?

Щото я не верю в круды с 30k rps на одном хосте :)

Всем насрать, Python прекрасен и несёт разумное, доброе, вечное.

Я сюда не свет истины нести принес, у меня тут уютный бложик.

Кратко: стенд состоит из нескольких одинаковых машин, сцеплены вместе гигабитным свитчом, на одной машине гоняется сервис, на остальных tsung с maxusers~1000 на каждом. Сессия цунга в цикле крутит 10^5 раз один и тот же запрос с варьирующимися параметрами (маленькая процидурка на эрланге для генерации).

Логики крайне мало и она идентична в обоих сервисах - это было тестирование не нашей логики, а именно что инструментария, логика синтетическая. В качестве бэкенда в одном из синтетических тестов - riak (тормозное гуано, кстати), в другом - постгрес с выкрученными в ноль гарантиями надежности.

А еще запускается по несколько секунд, ага.

Ящитаю очень шустро.

Неа, не шустро. Контора требует пресловутый мульен в секунду. Вот мы и корячимся, лол.

С PyPy попробуйте.

Ну, это синтетика. А так - чуть ранее у меня как раз CRD было (без U) на одном хосте (core i5-750, 16 GB RAM плюс более мощная машинка под постгрес). Было честные 15к не в синтетике, упирались в постгрес.

Контора требует пресловутый мульен в секунду

Тогда что одному с полтора килозапросами, что другому с тридатью — как до Австралии раком на пердячем ходу.

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

Тогда что одному с полтора килозапросами, что другому с тридатью — как до Австралии раком на пердячем ходу.

Неправильно мыслишь. Сервис масштабируется линейно, но одно дело вляпать тыщу нод, а другое - тридцать-сорок.

А у вас реальне CPU bound задача? Что-нить асинхронное не катет?

https://github.com/yyuu/pyenv спешит на помощь, но пупу не настолько более быстрее CPython.

Да какое там cpu-bound, прости бже, обычная унылая энтерпрайзинка. Асинхронное бы, кстати, вполне себе прокатило, но нам навязали технологический стек. Хотя мы вопили, что не надо пихать пыдон в «хайлод», лол.

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

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

Дак, осинхронности от гила ни холодно ни жарко. Знай поднимай отдельные истансы по количеству процов (как в прости г-ди нодежс). Я бы попробовал побенчить твистед или торнадо.

А твистед разве пул потоков не стартует? А разве этот пул не встает веселым раком под вопли «хава на-гил-а!»?

Я не особо мастер продакшн твистеда, вроде по дефолту один поток, но есть штуки для спавнинга задач в отдельные процессы с асинхронным интерфейсом. Есть еще multiprocessing модуль, который делает полноценные процессы с [медленным] IPC, но без гилопроблем, но таким макаром ЕМНИП сокет не пошариш.

Про мультипроцессинг рассказывать не стоит, сам в курсе. Нащот дристеда - посмотрим, может побенчим завтра.

Контора требует пресловутый мульен в секунду

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

Далее. Разные ЯП это разные инструменты, разные либы, даже разные технологии. И сравнивать всё это только по скорости работы джанги на отдаче пустых страничек это очень поверхностный подход.

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

Ну и задачу желательно озвучить. А мы тебе скажем что и как делать :)

одно дело вляпать тыщу нод, а другое - тридцать-сорок.

а ты думал почему twitter с ruby на scala перешел?

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

Тогда что одному с полтора килозапросами, что другому с тридатью — как до Австралии раком на пердячем ходу.

ну нет, тех что 30k выдают надо 30 сервачков (или кучек сервачков). и всё будет пучком.

а тех что выдают 1,5k надо порядка 700, а это уже совсем другая цифра.

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

Ты сравниваешь интерпретатор с jit-компиляторм в бинарныйкод. Так и должно быть. Каждый слой интерпретации уменьшает скорость в 10 раз.

Гавно получится. Причем unmantainable

Единственный раз соглашусь с пони-ю

Фуфло ваши цифры. Возьмите yaws и прямые руки, glassfish лосуснет тунца.

Педон не тормозит.

(На EJB я проекты уже лет восемь не разрабатывал. Все как-то Spring + Hibernate. На жизнь мне хватает.)

Впиливай. У нас бидон везде - сервера нагибаются. Но начальство хочет бидон, аргументы в сторону слива бидоном по скорости не проходят.

Пользуем торнаду если че.

Ну я хотел, честно, но даже виртуаленв так и не научился с пыпы работать.

УМВР. С чего бы...

Я так понимаю Сишечку в веб Ынтырпрайзе всъерез не воспринимают?

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

Про PyPy уже спрашивали?

А поподробнее? Почему unmaintainable?

тестирование uwsgi+django под вторым бидоном

бидон уперся в cpu хоста и выдал 1.5k

А джанга стоковая? Жанговские темлейты на жинжу не заменялись? ОРМ на raw-запросы не переводились?

стеклорыбу заменить на голый томкат, и будет шустрее, если отказаться от javaweb профиля т.е. на нестандартном api делать, то можно шустрее

Разные вещи сравниваете. Java - язык компилируемый(хоть и в JIT). Да и в его развитие столько денег инвестировали, что было бы удивительно, если бы он был медленным. Естественно, что результаты разные. Нагрузка интерпретируемого ЯП на CPU всегда будет немного неадекватной. Просто для разных задач нужны разные технологии. Вы бы ещё PHP и Java сравнивали.

uwsgi+django под вторым бидоном (в т.ч. со всеми новомодными фишечками uwsgi 1.9)

Попробуй другую связку, а именно nginx+gunicorn. Думаю получишь прирост.

Вместо Django надо было брать Flask.

Почему unmaintainable?

Потому, что количество специалистов.

>аргументы в сторону слива по скорости не проходят

И это правильно. С т.з. начальства «купить лишние сервера» - проблема почти нулевой сложности; при мегаопсах они окупятся раньше, чем утилизируются коробки, в которых они приехали. Нужны другие аргументы - то, что *они* считают сложным/ценным. Чего ради они выбирают питона? Я могу допустить 3 вероятных причины:

1. они собираются очень часто это переписывать. ваши шансы близки к 0, но можно рассказывать про бОльшую стабильность за счёт статической типизации (если вы в это ещё верите - иначе это будет ложь, а обманывать клиента не хорошо), и +п.2.

2. они собираются использовать для кастомизации низкоквалифицированную рабсилу; тогда говорите о том, что ява-кодеров как грязи и цена соответствующая (опять, если это правда).

3. они уже знают об отличиях питона и явы и не желают грузить будущих сотрудников последней; тут можно пытаться предложить приемлемый DSL или использовать не-яву на жвм-е, скалы там всякие, или житоны (:но это должно быть не интересно вам:).

Я вообще не пойму в чем проблема. Клиент хочет питон, согласен платить за дополнительные сервера, ваше дело исполнять.

или житоны

не пойдет, jython это тоже интерпретатор

Почему-то мне кажется, что это сравнение Django и Glassfish, а не Python и Java.

Почему-то мне кажется, что это сравнение Django и Glassfish, а не Python и Java.

разумеется
при чем тут питон ?
у джанги со стандартными настройками есть узкое горлышко
у гласфиша оно ширше

glassfish он асинхронный что ли ? Тогда сравнивать надо с python tornado например

Кстати же, неплохо было бы опубликовать сам код, который такую статистику дает.

Серверный, я имею в виду.

А то, знаешь, когда я слышу «второй бидон» — я чувствую предубеждение. И у меня самого возникает предубеждение, что тестирование проводилось по методу «засунем обычную газету в концентрированную серную кислоту, а журнал ТВ-Парк — в дистилированную воду».