MG
Мой ttl будет ровно таким, как и таймер на continue-editing, потому разницы не будет
Size: a a a
2021 January 12
SP
Мой ttl будет ровно таким, как и таймер на continue-editing, потому разницы не будет
проблема что если ttl меньше чем среднее время на выполнение операции, а удерживать ресурс больше положенного нельзя то твой вариант тупо не работает)
SP
у тебя будет какой-то ttl, какой-то интервал хертбита. Этого не избежать. Дальше вопрос можешь ли ты позволить себе этот интервал держать больше чем занимает 90% операций
SP
или риски если кто-то не успел и у него ресурс перехватили, мол что будет для бизнеса
MG
Не успел что?
SP
сделать с ресурсом то что ему нужно
SP
ты прочитал, изменил, сохранил. Это занимает от минуты до полу часа. Пока ты это делаешь никто не должен что-то еще делать с ресурсом.
SP
если делать TTL на пол часа при чтении то есть риск что у первого чела вырубится интернет а второй уже ничего не сможет сделать ближайшие пол часа
MG
Ну так он или шлёт запросы или нет. Тут действительно всё упирается в то, что ttl должен быть выше чем request time execution, но это единственное правило, которое а) вычисляется б) конфигурируется
SP
потому нужны хертбиты
SP
эту роль у человека выполняет continue editing
MG
Хертбиты не обязательны. Если request timeout ~ max 120s, согласно статистике, то в чём проблема поставить ttl в 3-4 минуты?
SP
Хертбиты не обязательны. Если request timeout ~ max 120s, согласно статистике, то в чём проблема поставить ttl в 3-4 минуты?
в моем случае 3-4 лишние минуты это больше счет за операцию (поминутная тарификация) :) и ты как пользователь расстроишься
MG
Ну, всегда можно найти исключения
SP
ну опять же - вот по статистике у тебя 50% за минуту, 90% за 10 минут и 99% за 20 минут распределение (на последний процент тормозов мы можем забить)
MG
За минуту и за 20 минут - это что - редактирование?
SP
20 минут - слишком большой срок блокировки, как и 10 минут. Но 10% людей делают вещи больше 10-ти минут
SP
За минуту и за 20 минут - это что - редактирование?
да, вполне
SP
редактирование разное бывает)
MG
Так лучше же не агрегировать изменения, а слать небольшими порциями как только так и сразу. В разрезе проектирования API у нас нет 2 или 20 минут. Есть запросы. Ты слал 10 запросов на протяжении 10 минут с ttl 120s и спокойно редактировал документ. Через пару минут с ним сможет работать следующий человек с того места где ты закончил