гыгыгы

Неполиткоректненько...

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

чтобы предметно сравнить за пределами локалхоста

5.7.21

Щас попробую

ну и там не 4 сек, а в реальности где то 2.5 мсек

Во-первых, а зачем Вы измеряете погоду на Марсе (просто любопытно)? Я к тому, что (с виду) этот "benchmark" не имеет ничего общего с какой-либо реальной нагрузкой. Во-вторых, какая Вам разница, 2 или 3 миллисекунды выполняется какой-то запрос, в принципе?

ох, одни и те же разговоры всегда по кругу. стандартный вопрос №123, стандартный ответ №321

Во-первых, а зачем Вы измеряете погоду на Марсе (просто любопытно)? Я к тому, что (с виду) этот "benchmark" не имеет ничего общего с какой-либо реальной нагрузкой. Во-вторых, какая Вам разница, 2 или 3 миллисекунды выполняется какой-то запрос, в принципе?

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

это если у вас вся база в памяти помещается и диски совсем не использует. Иначе эти миллисекунды - погода на марсе.

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

Нет, ничего такого по этому "бенчмарку" не выходит. И да, это бесполезный мусор, а не информация, извините.

это если у вас вся база в памяти помещается и диски совсем не использует. Иначе эти миллисекунды - погода на марсе.

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

просто в этом конкретном сценарии непонятно, почему не положить всю эту базу в статичную json-ку и не фильтровать у клиента в браузере, раз это настолько нагруженный эндпоинт апи, что 500 rps vs 400 rps критичная разница

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

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

достаточно посмотреть на количество статей как пг с джонб уделывает монгу по скорости

мы предлагаем тебе ускориться с 500rps в 50000rps выкидыванием из логики работы CPU вообще

и деланием DMA из диска в сетевуху через sendfile

мы предлагаем тебе ускориться с 500rps в 50000rps выкидыванием из логики работы CPU вообще

но это не имеет отношения к пг вс мыскл

достаточно посмотреть на количество статей как пг с джонб уделывает монгу по скорости

политрук лжёт!

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

Да, Вам это не нужно. Если Вы не троллите, Вам нужно научиться измерять и делать выводы, серьёзно.

политрук лжёт!

умалчивает же ведь)

Да, Вам это не нужно. Если Вы не троллите, Вам нужно научиться измерять и делать выводы, серьёзно.

нда...

а есть хороший курс по метрологии где-нибудь на курсэре?

умалчивает же ведь)

вот про то, как уделывает монгу в json — прямо таки лжёт

и когда ловят за руку, начинает умалчивать

Да троллит он. "решение сводится к "добавьте памяти"" - это ж вообще огонь. Выкидываем все эти мудреные флешсистемы, покупаем стойку серверов с терабайтами оперативной памяти, и все проблемы решены!

нда...

Что "нда"? У Вас _реальная нагрузка_ 100% идентична вот этому, простите за выражение, benchmark-у? ;)

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

Что "нда"? У Вас _реальная нагрузка_ 100% идентична вот этому, простите за выражение, benchmark-у? ;)

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

а есть хороший курс по метрологии где-нибудь на курсэре?

Да, я вот не отказался бы вспомнить то, что не знаю, и узнать то, что забыл. :( А то у нас метрология была... Просто была. Отложилось в мозге ничего, кроме названия. :(

и нет, это вообще не про метрологию

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

так может оригинальный бенчмарк в студию? :)

есть оригинальная база, есть дамп адаптированной к пг, есть запрос. что ещё надо?

финансирование

логично...

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

Мир добрее станет немного если такую замену сделать. Тк не всегда получается квадратным инструментом делать круглые отверстия.

купить коньяка и забыть о разговорах тут

если тебе критичны эти 20% на этом запросе, ты найдёшь денег на патч

если ты не найдёшь денег, то может и не критичны и спор ради троллинга

но можно же на эти деньги оставить мускль и ещё на коньяк останется!

можно

речь о другом. 20% тут, 40% там — мне все микрозапросы бенчмаркать?

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

Эээ... рассказы "инженеров интернет-гигантов" тоже ничего не значат, совсем. Вот (несколько отвлекаясь от темы) мне интересно, почему, если человек работает в какой-то крупной/известной организации, многи тут же начинают свято верить, что он квалифицированный профессионал? ;)

пока сервер загружен меньше 30%, бенчмаркать почти ничего не надо

если латенси не интересует, да

Эээ... рассказы "инженеров интернет-гигантов" тоже ничего не значат, совсем. Вот (несколько отвлекаясь от темы) мне интересно, почему, если человек работает в какой-то крупной/известной организации, многи тут же начинают свято верить, что он квалифицированный профессионал? ;)

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

если латенси не интересует, да

латенси в 4 мс скрадывается использованием ADSL/3G на пути до кастомера.

да хрен с ними, гигантами. вот, допустим, для формирования индекса.хтмл мне надо выполнить 20 запросов по 3 мсек. это уже + 60 мсек латенси.

да хрен с ними, гигантами. вот, допустим, для формирования индекса.хтмл мне надо выполнить 20 запросов по 3 мсек. это уже + 60 мсек латенси.

распараллелить?

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

Дело в том, что facebook/google —- это совсем другие вещи, т.е. сравнение яблок с апельсинами. У них, например, обычно нет требований ACID, т.е. задачи _совсем_ другие, и эти многие их истории не имеют отношения к СУБД общего назначения.

если это будут не 3 мсек, а 2мсек запросы, то это всего + 40 мсек и это уже заметно лушче

да хрен с ними, гигантами. вот, допустим, для формирования индекса.хтмл мне надо выполнить 20 запросов по 3 мсек. это уже + 60 мсек латенси.

пререндерить блоки? это уже, кажется, все движки умеют

в несколько корутин/горутин ? ну если у вас асинхронщина

распараллелить?

много ты знаешь шаблонизаторов, которые умеют параллелить вызовы?

ну а не надо в шаблонизаторе делать запросы

в шаблонизатор надо уже передать готовый контекст

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

пререндерить блоки? это уже, кажется, все движки умеют

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

а зачем ты везде тащишь pg?

ну интересный вопрос, да. где то и склайта хватило бы...

ну унеси шаблонизатор в хранимку, если так хочется

будет за один запрос всё рендериться

да хрен с ними, гигантами. вот, допустим, для формирования индекса.хтмл мне надо выполнить 20 запросов по 3 мсек. это уже + 60 мсек латенси.

Есть хранимые функции —- очень помогают уменьшению latency.

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

http://ps.tmpc.ru/065bc539 - mysql

7.6ms?

В целом да - 25% выигрыш у пг

Там в секундах

Ой

Кэш?

у тебя же постгрес на той же машине за 1 мс отрабатывал?

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

Нет, Вам рассказывают про то, что Вы измеряете что-то не то (да и работате с базой не самым лучшим образом), и почему-то у Вас кто-то другой в чём-то виноват... ;)

http://ps.tmpc.ru/927f532d

Вот. На том же железе

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

Вот. На том же железе

это первый запрос или второй?

это первый запрос или второй?

т.е. кеш "прогрелся" или нет?

относится к обоим дб

вернее у пг то он судя по хитам уже прогрет

это первый запрос или второй?

Второй

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

Не понял, причём тут это... Я (и не только) о том, что лучший способ уменьшить latency —- использовать stored functions.

Не понял, причём тут это... Я (и не только) о том, что лучший способ уменьшить latency —- использовать stored functions.

это всё вопросы "вокруг", не по теме. тема — как ускорить конкретный запрос, чтобы получить лучше, чем у мыскл скорость.

как ускорить конкретный запрос - профилировать, дописывать, патчить.

это всё вопросы "вокруг", не по теме. тема — как ускорить конкретный запрос, чтобы получить лучше, чем у мыскл скорость.

Нда... то есть Вы не согласны, что производительность этого запроса не имеет никакого отношения к Вашей реальной проблеме (если у Вас она вообще есть)?

у меня имеется дурацкий вопрос. А настройки пг и мускуля "одинаковые" на сколько это возможно? Вдруг ПГ настроен для работы на кофеварке?

у меня имеется дурацкий вопрос. А настройки пг и мускуля "одинаковые" на сколько это возможно? Вдруг ПГ настроен для работы на кофеварке?

я же план показывал. там всё в рам

там есть план с explain analyze verbose buffers, он адекватный

Дело в том, что facebook/google —- это совсем другие вещи, т.е. сравнение яблок с апельсинами. У них, например, обычно нет требований ACID, т.е. задачи _совсем_ другие, и эти многие их истории не имеют отношения к СУБД общего назначения.

простите, а как много вы знаете про инфраструктуру facebook/google? или вот хорошо, это не яблоки, а апельсины. А скажем Booking — это уже апельсины, или ещё яблоки? А Uber? А Twitter? Или вот Github?

как ускорить конкретный запрос - профилировать, дописывать, патчить.

нет ответа про то чтобы "лучше мыскуля"

а ну ок извините пропустил ?

У pg все сток кроме shared_buffers - там 2 GB - взял то что было под рукой. mysql полный сток. Оба на ubuntu 16.04

Нда... то есть Вы не согласны, что производительность этого запроса не имеет никакого отношения к Вашей реальной проблеме (если у Вас она вообще есть)?

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

используйте clickhouse

он ещё быстрее

и гордится этим