В условиях какой нагрузки разумно пользоваться optimistic concurrency? Скажем, 100 воркеров могут одновременно в один партишн лезть — нормально, а если 1000 — то все, клинч, надо городить специальную очередь и воркера к ней.
v6>В условиях какой нагрузки разумно пользоваться optimistic concurrency? Скажем, 100 воркеров могут одновременно в один партишн лезть — нормально, а если 1000 — то все, клинч, надо городить специальную очередь и воркера к ней.
Вопросы некорретные — смешали вопросы в ядрёный коктейль в теме. На них нет ответа.
Самая большая нестыковка — это что бы засунуть синхронный обработчик действий пользователя в асинхронных worker через очередь. Такой финт обычно требует сильной переделки UI.
Ну и optimistic concurrency не спасёт производительность если все начнут писать в один hash key.
v6>>В условиях какой нагрузки разумно пользоваться optimistic concurrency? Скажем, 100 воркеров могут одновременно в один партишн лезть — нормально, а если 1000 — то все, клинч, надо городить специальную очередь и воркера к ней.
VC>Вопросы некорретные — смешали вопросы в ядрёный коктейль в теме. На них нет ответа.
VC>Самая большая нестыковка — это что бы засунуть синхронный обработчик действий пользователя в асинхронных worker через очередь. Такой финт обычно требует сильной переделки UI.
VC>Ну и optimistic concurrency не спасёт производительность если все начнут писать в один hash key.
Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз.
Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет.
Здравствуйте, v6, Вы писали:
v6>Здравствуйте, VladCore, Вы писали:
v6>>>В условиях какой нагрузки разумно пользоваться optimistic concurrency? Скажем, 100 воркеров могут одновременно в один партишн лезть — нормально, а если 1000 — то все, клинч, надо городить специальную очередь и воркера к ней.
VC>>Вопросы некорретные — смешали вопросы в ядрёный коктейль в теме. На них нет ответа.
VC>>Самая большая нестыковка — это что бы засунуть синхронный обработчик действий пользователя в асинхронных worker через очередь. Такой финт обычно требует сильной переделки UI.
VC>>Ну и optimistic concurrency не спасёт производительность если все начнут писать в один hash key.
v6>Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз. v6>Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет.
Ну ты правильно написал. Только если архитектура и UI позволяет и все воркеры пишут разные hash keys.
optimistic concurrency может нужна а может и нет. она тут ортогональная.
Здравствуйте, VladCore, Вы писали:
VC> v6>>Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз. v6>>Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет. VC>
VC>Ну ты правильно написал. Только если архитектура и UI позволяет и все воркеры пишут разные hash keys.
VC>optimistic concurrency может нужна а может и нет. она тут ортогональная.
Я, наверно, плохо описал ситуацию. Упрощенно такой пример: есть множество воркеров, каждый инкрементит общий счетчик, допустим, выполненных заданий. Счетчик в Azure table. Чтобы заинкрементить читаем и пишем обратно. Если отвалились с ошибкой "уже изменено", то пробуем еще раз, прикручиваем exponential backoff. Вопрос: насколько этот подход масштабируем в условиях azure. Может сразу очередь с заданиями на инкремент счетчика делать?
Здравствуйте, v6, Вы писали:
v6>Здравствуйте, VladCore, Вы писали:
VC>> v6>>>Почему некорректные? Есть пул воркеров, которые могут обновлять запись в одном партишене. Самый примитивный и просто вариант разрулить — это optimistic concurrency: если случилась ошибка, попробовать еще раз. v6>>>Если интенсивность запросов невысокая, то нормально будет работать. Если запросы слишком частые, то будут мешать друг другу, надо синхронизировать через очередь тасок. Мой вопрос в том, где примерно можно провести границу между этими двумя случаями. Т.е. асколько может масштабироваться optimistic concurrency. Про UI тут вообще ничего нет. VC>>
VC>>Ну ты правильно написал. Только если архитектура и UI позволяет и все воркеры пишут разные hash keys.
VC>>optimistic concurrency может нужна а может и нет. она тут ортогональная.
v6>Я, наверно, плохо описал ситуацию. Упрощенно такой пример: есть множество воркеров, каждый инкрементит общий счетчик, допустим, выполненных заданий. Счетчик в Azure table. Чтобы заинкрементить читаем и пишем обратно. Если отвалились с ошибкой "уже изменено", то пробуем еще раз, прикручиваем exponential backoff. Вопрос: насколько этот подход масштабируем в условиях azure. Может сразу очередь с заданиями на инкремент счетчика делать?
Аааа. Ну так бы стразу и описал. Да. Но из очереди можно вычитывать за раз атомарно по моему всего 10 сообщений.
И если "уже изменено" по моему не нужен exponential backoff
Если по 10 инкрементов обновлять — мало. Можно обойтись без очереди.
Попробуйте все инкременты заданного ID разбить на 100-1000-10000 строчек во временный, но масштабируемый Table продублировав ID в RowKey и PartitionKey. Там до 1К лимит размера каждого поля. Приклеивайте к ID GetHashCode(IP адрес или логин клиента)/N. Если взять N=4 миллиона, то все инкременты для заданного ID будут размазаны по 1000-м строк.
Тогда сможете инкрементировать не по 10 инкрементов за цикл воркера, а по 100-1000-10000 инкрементов.
Понадобится Web Job, который раз в N минут будет из временной таблицы инкрементов сливать сумму в чистовой Table инкрементов.
Немного изврат, но не нужны никакие BigData
При чем здесь Azure? Это вопрос на арифметику в первом приближении и на теорвер во втором. Сколько апдейтов в секунду ожидается (X)? Сколько времени занимает один апдейт (Y)? (нужно учесть rtt) В первом приближении если X << 1/Y, то все будет летать с оптимистик лок. В вашем сценарии (read-modify-write) 1/Y вообще является теор максимумом скорости обновлений, concurrency у вас быть не может.
