Телеграмм чат группы HighLoadTalks страница 1169

parrot.ru

Рейтинг популярных групп и каналов

В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Чат конференции HighLoad++

2706 membersпожаловаться на группу

2019 November 10

Y

Yuran in Чат конференции HighLoad++

А зачем открывать сотни коррекций в секунду? Это просто неправильный метод работы с любой базой.

Ну если речь про PHP, то тут всего 2 опции — либо держать постоянные соединения из каждого воркера (даже на одной машине воркеров может быть несколько сотен, а машин зачастую тоже сотни или тысячи), что быстро приводит к очень большому количеству соединений (сотни тысяч), либо постоянно открывать/закрывать соединения. Второй способ вполне нормально работает с MySQL, например, хотя и тоже не лишен недостатков.

источник

17:34пожаловаться #1

KD

Kirill D in Чат конференции HighLoad++

обратное я могу сделать на ходу. radix да, но писать сам не буду

Ты не понял мысль. Radix по reversed строке

*.google.com

m -> o -> c -> . -> e - > l - > g -> o -> o -> g -> . -> *

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

источник

17:39пожаловаться #2

PD

Phil Delgyado in Чат конференции HighLoad++

Ну если речь про PHP, то тут всего 2 опции — либо держать постоянные соединения из каждого воркера (даже на одной машине воркеров может быть несколько сотен, а машин зачастую тоже сотни или тысячи), что быстро приводит к очень большому количеству соединений (сотни тысяч), либо постоянно открывать/закрывать соединения. Второй способ вполне нормально работает с MySQL, например, хотя и тоже не лишен недостатков.

Да просто TLS открывать столько раз - уже плохо. И тогда локальный pgbouncer как раз оптимальное решение. Ну или выкинуть php

источник

17:49пожаловаться #3

p

pragus in Чат конференции HighLoad++

Да просто TLS открывать столько раз - уже плохо. И тогда локальный pgbouncer как раз оптимальное решение. Ну или выкинуть php

А если у нас просто много клиентов к бд?

источник

17:54пожаловаться #4

PD

Phil Delgyado in Чат конференции HighLoad++

А если у нас просто много клиентов к бд?

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

источник

18:00пожаловаться #5

p

pragus in Чат конференции HighLoad++

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

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

источник

18:07пожаловаться #6

PD

Phil Delgyado in Чат конференции HighLoad++

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

Там, конечно, ставится блокировка. Но при skip locked сериализации не происходит, берется следующая свободная.
У меня на дешевом железе получалось до 2000 TPS по 10ms.
Количество коннекций важно и если обработка события долгая и в транзакции (а ради транзакции это и имеет смысл городить), то постгрессу плохо. Но заметим, что даже 100 процессов по 10ms - это 10K tps

источник

18:08пожаловаться #7

p

pragus in Чат конференции HighLoad++

В рамках разогрева: https://www.percona.com/blog/2019/02/25/mysql-challenge-100k-connections/

Percona Database Performance Blog

MySQL Challenge: 100k Connections - Percona Database Performance Blog

It's not beyond possibility to set up MySQL to achieve 100,000 concurrent connections if you balance network config and use thread pools. By Vadim Tkachenko

источник

18:08пожаловаться #8

PD

Phil Delgyado in Чат конференции HighLoad++

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

А зачем 100 соединений с хоста? Длинные транзакции?
Существенно число одновременных операций, а оно всяко будет меньше.

источник

18:09пожаловаться #9

p

pragus in Чат конференции HighLoad++

Там, конечно, ставится блокировка. Но при skip locked сериализации не происходит, берется следующая свободная.
У меня на дешевом железе получалось до 2000 TPS по 10ms.
Количество коннекций важно и если обработка события долгая и в транзакции (а ради транзакции это и имеет смысл городить), то постгрессу плохо. Но заметим, что даже 100 процессов по 10ms - это 10K tps

10ms - это server time или же учитывает roundtrip до клиента?

источник

18:10пожаловаться #10

PD

Phil Delgyado in Чат конференции HighLoad++

Это чистая задержка на клиенте от взятия задачи внутри транзакции до коммита. т.е. чистое время полезной работы на клиенте. Для внутреннего http call и простой логики более чем.

источник

18:11пожаловаться #11

PD

Phil Delgyado in Чат конференции HighLoad++

Мне хватало 1000 в пике по ТЗ, так что двукратный запас был норм. Можно уменьшать время операций за счёт увеличения числа событий. Тогда будет 5000, но по 4ms...

источник

18:12пожаловаться #12

PD

Phil Delgyado in Чат конференции HighLoad++

Если событий нужно больше, то лучше думать о других сценариях, конечно. Со своими tradeoff

источник

18:13пожаловаться #13

EK

Eldar Karazhas in Чат конференции HighLoad++

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

источник

18:22пожаловаться #14

PD

Phil Delgyado in Чат конференции HighLoad++

В рамках разогрева: https://www.percona.com/blog/2019/02/25/mysql-challenge-100k-connections/

Percona Database Performance Blog

MySQL Challenge: 100k Connections - Percona Database Performance Blog

It's not beyond possibility to set up MySQL to achieve 100,000 concurrent connections if you balance network config and use thread pools. By Vadim Tkachenko

Так это тоже специальный плагин для тредпула. Pgbouncer просто гибче (можно ставить независимо и даже бывают сценарии, когда это имеет смысл. Я видел доклады с цепочкой из pgbouncer.... Обычно, конечно, ставят прямо на машину с pg).

источник

18:25пожаловаться #15

p

pragus in Чат конференции HighLoad++

Так это тоже специальный плагин для тредпула. Pgbouncer просто гибче (можно ставить независимо и даже бывают сценарии, когда это имеет смысл. Я видел доклады с цепочкой из pgbouncer.... Обычно, конечно, ставят прямо на машину с pg).

Оно из коробки

источник

18:41пожаловаться #16

p

pragus in Чат конференции HighLoad++

Там, конечно, ставится блокировка. Но при skip locked сериализации не происходит, берется следующая свободная.
У меня на дешевом железе получалось до 2000 TPS по 10ms.
Количество коннекций важно и если обработка события долгая и в транзакции (а ради транзакции это и имеет смысл городить), то постгрессу плохо. Но заметим, что даже 100 процессов по 10ms - это 10K tps

Интереснее кейсы вроде 1-2m tps, потому что современное железо вполне позволяет по iops

источник

18:44пожаловаться #17

PD

Phil Delgyado in Чат конференции HighLoad++

Оно из коробки

Так pgbouncer тоже из коробки )

источник

18:55пожаловаться #18

PD

Phil Delgyado in Чат конференции HighLoad++

Интереснее кейсы вроде 1-2m tps, потому что современное железо вполне позволяет по iops

А тут я даже не знаю, кто такое с поддержкой трнзакций может. Подозреваю, что никто.

источник

18:56пожаловаться #19

PD

Phil Delgyado in Чат конференции HighLoad++

Мне интересны сценарии, когда взять событие, изменить данные, отправить события и закончить обработку - в одной транзакции. И тут я не знаю решений, где и 100k TPS можно, вне зависимости от железа.

источник

18:58пожаловаться #20