Max Payne, по простому - если ваш тест сейчас отрабатваает за 30 сек, то при запсуке в 2 процесса, он будет отрабатывать за 15 сек и т.д. (пока не упрется в cpu/io/базу).
Max Payne, ну как я и написал изначально "ни asyncio ни aiohttp тут не причем."
если у вас нагруженная бизнес логика, тогда возмите не асинхронный фреймворк например flask/bottle (что-нибудь на uwsgi) и запускайте в 16* процессов. пока не упретесь в CPU или базу - это будет максимальгная производительность для данного кода/сервера, дальше надо будет оптимизировать код/запросы/баланснг...
и это будет работать гораздо быстрее чем с asyncio, асинхронные фреймворки вообще созданы не для таких задач.
Max Payne, Я вам в ответе сделал пример, у меня он выдает: 123krps, и max latency 6.74ms
используйте wrk, возможно ваша тулза тормозная...
Если для вас httptools сильно низкоуровневый, то можете взять sanic который на нем основан.
Roman Kitaev, а за го это делает "ассемблер"/машинный код, и что ты тут споришь? это не важно, в результате питон обгонит на не которых задачах.
это глупый вопрос, на любом фреймворке можно сделать +- тоже самое, поэтому к тебе и вопрос - почему ты хочешь "пересадить" автора вопроса с ботла на фласк, у него ботл уже в деле, какие аргументы?
Roman Kitaev, пфф
есть некоторые вещи которые питон делает не медленее (быстрее) чем го,
ну и обратный вопрос: "Есть что-то конкретное, в чем фласк помогает, а ботл не умеет?"
Roman Kitaev, ботл техничнее написан, он более легковесен в плане кода, поэтому он и работает быстрее и переехал на py3 гораздо раньше (за несколько лет) фласка, "один файл" - хотя тут и плюс и минус,
а фласк - абстракции над абстракциями над "верцегом", ну да - он хайповее.
Сергей Горностаев, > Грубо говоря, не стоит в плюсах использовать printf и malloc. В этом ваш собеседник прав.
почему нет? дело ведь не в том что используешь, а как.
Есть даже "направление" где берут С++, выкидывают монструозные шаблонные конструкции и т.п. и кодят чистый код С + С++, типа С с плюшками от С++ (классы, исключения и пр.)...
ktulhu, так же в тесте монгу нагрузили всего на 70%, когда посгрес на все 100%, т.е. у монги был ещё не слабый запас, видимо иначе посгре бы не выиграл в этом тесте
ktulhu, замечательный доклад,
вообщем чтобы постгрес "выиграл", в посгресе нужно выключить синхронизацию (т.е. значительно понизить надежность) и оперировать мелкими записями, т.к. после 2кб посгрес "складывается" и работает в разы медленее монги - это ответ почему хранение таблицами - устаревшый подход (не имеет отношение к sql/rdbms, чисто способ хранения). Ну и дополнительно замедлить монгу ключами w=1, j=1...
Надо будет перетестить, возможно в посгрес писали "в одну сессию"... (что дает ускорение в разы, но по сути используется только в тестах, а не в реальных приложениях).
И если взять например такой тест где 5% записей нужна синхронизация, а в 95% нет, то (судя по графикам) монга выдаст 50к, а посгрес 5к. Потому что посгрес не может менять режим на лету... а если ещё и тоаст учесть, то посгрес вообще будет в дауне - в 20-50 раз медленее могни.
Вообщем на средний проект и реальное использование - посгрес будет значительно медленее монги.
CityCat4, Поэтому я и спросил про trace в первом сообщении, это нормально и нет никакой магии, это делается простой настройкой роутингов, чем и занимается каждый провайдер.
Вопрос в том - чего вы переживаете?
sim3x, по лекции - автор сказал что их монга устраивает и он рекомендует её в 8 из 10 случаев, у них по сути проблема была только с шардингом (вполне вероятно что за 5 лет это уже исправлено).
Лекция очень старая - монга 2.х, сейчас монга значительно продвинулась, те же пункты как транзакции и глобальный лок - давно решены.
Итого 5 лет назад уже подходило для "8 из 10 случаев", а сейчас ещё лучше.
webe, ну это не тот случай, лучше сделать так же как и в mysql, только parent_id сделать список где будет находится id всех родителей, тогда все дочерние можно будет легко достать простым запросом. (посути метод аналогичный psql ltree)
если в кратце - вложенные данные могут быть удобны если на них не нужно ссылаться из других документов, либо для оптимизации
