Е
То есть к этой таблице по идее должен иметь доступ некий огнраниченный круг процессов.
Size: a a a
2020 December 19
Е
Наверное создам таблицу в модуле супервизора соответствующего блока приложения. Норм будет?
AM
Мы тебя не осудим
Е
в моём понимании ets/dets - это для конкретных процессов внутри, а если надо что-то глобальное иметь с множественным доступом - mnesia или какие-нибудь внешние инструменты уже
Ну мнезия это все таки скорее про транзакции и распределенность, а мне достаточно внутринодовой доступности
Е
Мы тебя не осудим
Я очень рад :)
ŹR
То есть к этой таблице по идее должен иметь доступ некий огнраниченный круг процессов.
А будут все равно все
ŹR
Ну и нахуя тогда извращаться
Е
Ну и нахуя тогда извращаться
Мне просто показалось, что процесс приложения довольно неожиданное место для создания таблицы, использование которой по дизайну ограничено определенными модулями.
Е
В общем я понял. Какого-то феншуя не существует, все делают по-ситуации.
Можно считать вопрос закрытым. Всем спасибо.
Можно считать вопрос закрытым. Всем спасибо.
ML
Такой вот вопрос, товарищи.
Мне нужна публичная таблица ets. То есть все могут как читать, так и писать. Но насколько я понял даже в таком случае все равно нужен процесс-владелец.
Что в таком случае делать по феншую? Создать пустой генсервер, который будет все время дрыхнуть в ожидании сообщений, которые никогда не придут?
Мне нужна публичная таблица ets. То есть все могут как читать, так и писать. Но насколько я понял даже в таком случае все равно нужен процесс-владелец.
Что в таком случае делать по феншую? Создать пустой генсервер, который будет все время дрыхнуть в ожидании сообщений, которые никогда не придут?
Это можно сделать и через 2 года отладки ты вернешься по меньшей мере к процессу, через которого ты пишешь :)
ML
В этом собсно и смысл, чтобы увеличить пропускную способность. Если все гнать через генсервер, то этот может стать бутылочным горлышком.
Это очень ошибочное мнение.
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
ML
Те чтение из публичной ets прижилось. Запись в публичную ets нет.
10 лет развития продукта, до 4,5 млн прокачиваемых записей в секунду через один сервер, чтобы дать ориентир по перфомансу
10 лет развития продукта, до 4,5 млн прокачиваемых записей в секунду через один сервер, чтобы дать ориентир по перфомансу
Е
Это очень ошибочное мнение.
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
Думаю, сильно зависит от количества пишущих процессов.
Е
У вас что только один процесс пишет?
Е
Ну и что насчет параллельного чтения?
Е
Это очень ошибочное мнение.
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
Ты гипотетически без единой цифры предположил, что запись через публичную таблицу «быстрее» чем через процесс.
Проблемы две:
1. Define “быстрее». Это очень сложное явление
2. Ты не мерял.
Забегу вперед: мы отказались от публичной записи в ets и сделали все через процессы:
Вот тут вроде померяли:
https://dockyard.com/blog/2017/05/19/optimizing-elixir-and-phoenix-with-ets
https://dockyard.com/blog/2017/05/19/optimizing-elixir-and-phoenix-with-ets
ML
У вас что только один процесс пишет?
Пишут тысячи процессов. При таком режиме их конкурентный доступ к ets неконтролируемо встает колом и вы без анализа локов не сможете понять, почему ваша программа перестала грузить cpu и обслуживать
ML
Ну и что насчет параллельного чтения?
Параллельное чтение норм.
Одна ets спокойно не создавая проблем выдает несколько десятков тысяч чтений на все ядра.
Но запись на практике лучше через один процесс
Одна ets спокойно не создавая проблем выдает несколько десятков тысяч чтений на все ядра.
Но запись на практике лучше через один процесс
Е
Пишут тысячи процессов. При таком режиме их конкурентный доступ к ets неконтролируемо встает колом и вы без анализа локов не сможете понять, почему ваша программа перестала грузить cpu и обслуживать
Вот именно. У вас достаточно нестандартная ситуация, по моему скромному. В моем случае писать будет в худшем случае менее десятка процессов и довольно редко, а читать будут вероятно сотни и постоянно.
ML
Вот именно. У вас достаточно нестандартная ситуация, по моему скромному. В моем случае писать будет в худшем случае менее десятка процессов и довольно редко, а читать будут вероятно сотни и постоянно.
Успехов :)