PD
Почему? Там очень многое хорошо кэшируется, а ldap хорошо кэшируется.
Size: a a a
2020 July 09
MB
Почему? Там очень многое хорошо кэшируется, а ldap хорошо кэшируется.
Я про клиентскую задержку, не серверную
VK
Видимо и BI такой же
PD
А тут тоже нет разницы с внешним inmem кэшем. Т.е. все равно все в сеть упирается.
PD
Но я не разбираюсь в сетях на такие нагрузки.
PD
Т.е. я бы, наверно, задачу решал бы не через ldap. И скорее всего нагрузка на отдельный компонент была бы меньше, но совершенно не уверен, что при этом общая стоимость проекта была бы ниже.
PD
Просто я не привык к железу, которое переваривает 1 млн. ops и обычно думаю про решения другими способами.
MB
Просто я не привык к железу, которое переваривает 1 млн. ops и обычно думаю про решения другими способами.
Так вроде любое современное железо может стока отдать
VK
Так вроде любое современное железо может стока отдать
Если архитектурно софт позволит :)
PD
Ну, вот PG не сможешь отдать 1mln rps с узла. И большая часть веб-серверов не сможет отдать 1mln rps, даже с hello world.
VK
Но да, я тоже не вижу проблем с миллионом в секунду
VK
Ну, вот PG не сможешь отдать 1mln rps с узла. И большая часть веб-серверов не сможет отдать 1mln rps, даже с hello world.
А зачем с узла? Много узлов надо :)
AS
Ну, вот PG не сможешь отдать 1mln rps с узла. И большая часть веб-серверов не сможет отдать 1mln rps, даже с hello world.
Почему нет? В 500 потоков по 2000rps на поток - это и есть 1М. Если просить SELECT CURRENT_TIMESTAMP - успеет
PD
Ну, с много узлов - там уже дело больше в архитектуре, нежели в железе.
VK
И не постгрес
AS
Если 1М с подключениями, то Постгрес не успеет, конечно.
MB
А зачем с узла? Много узлов надо :)
Если тебе надо сотни миллионов rps то тебе нужны будут и так сотни машин
ЮВ
Почему нет? В 500 потоков по 2000rps на поток - это и есть 1М. Если просить SELECT CURRENT_TIMESTAMP - успеет
ядро на сетевом слое порвется, мне кажется
ЮВ
уткнется в контекст свич
PD
Ну, в таком виде - да. Хотя 2000 rps на поток - это еще не факт, что сможет.