я считаю что возможность управлять лучше чем отсутствие такой возможности. сейчас рычагов управления нет — рынок сам все решит. если рынок решит что моногорода должны умереть — моногорода умрут, независимо от хотелок населения государства и населения этих моногородов.
или обанкротятся и выгонят работников на улицу. и решает это только частный владелец бизнеса. государство может или дать ему денег или кормить его уволенных работников.
убыточное предприятие еще и производит продукцию, которая может быть нужна другим предприятиям. если этой продукции не будет — то может оказаться необходимым платить компенсации еще и работникам предприятий, которые эту продукцию покупают
ну вот например допустим есть такая ситуация: владелец неэффективного частного бизнеса в моногороде видит, что предприятие скорее всего в ближайшие пару лет будет получать еще меньше прибыли чем сейчас и вообще станет убыточным. и глядя на это владелец решает внезапно закрыть предприятие, распилить станки на металлолом и уволить 10-15 тысяч человек и оставить половину населения города без работы (его право, он владелец, да может еще ему местный мэр не понравился ибо не выдал его сыну территорию городского парка под коммерческую застройку).
и что с этим сделать? сменить мэра? заставить владельца оптимизировать собственный бизнес? заставить владельца перестать ставить родственников на управляющие позиции? подарить этому бизнесу госконтракт на дохренилион денег с повышенной нормой прибыли или уменьшить налоги — и по сути подарить деньги владельцу бизнеса? или смотреть как в городе через 3 месяца начнется разгул преступности?
в случае госсобственности вариантов больше — например кормить предприятие деньгами чтобы оно увольняло персонал не сразу, а на протяжении N лет. или сменить руководство и выделить деньги на оптимизацию предприятия — если что, прибыль достанется государству. или целенаправленно перевезти работников в другие города.
ну если судить по примерам — то и государственная и частная собственность одинаково неэффективны. и там и там полно плохих примеров. но у государственной собственности есть плюс в плане управления — государство может _заставить_ государственное предприятие делать то что государству нужно, частное нельзя заставить и оно будет делать то что хочет его владелец независимо от желания населения моногородов и желания государства развивать моногорода.
почему бы вместо этого не начать за счет государства строить жилье рядом с существующими промышленными центрами и не перевезти туда людей из моногородов? может быстрее окупится?
что значит «развивать»? какие-то владельцы капитала должны в здравом уме по собственному желанию вложить деньги в производство в городе, откуда все население стремительно бежит, только из за того что там рядом есть ресурсы (которые можно было бы и импортировать) и пустующие дешевые площади? а квалифицированных кадров откуда завозить и захотят ли они вообще там работать? может ну нафиг, есть окрестности крупных городов же, и земля там тоже дешевая? альтернатива — строить предприятия за счет госсредств, но это как-бы немного не капитализм и ушло вместе с союзом
но разве эти вопросы не является тесно связаными с вопросами «откуда у пролетария имущества на 2 млн для использования в качестве залога по этому кредиту?», «выплатил ли уже пролетарий свою ипотеку?», и «откуда у собственников банка лишние 2 млн в капитале банка, которые в случае невыплаты нужно будет зарезервировать под такой кредит на неопределенное время»?
тут даже наверное и тред с таймером не нужен — можно обрабатывать возможное срабатывание таймера в том месте где запрос пришел (непосредственно в CanExecute). но опять таки, автору это решение как я понимаю не подходит, т.к. например в ситуации ограничения на 1 рпс последовательность «putToken -> sleep(0.9с) -> request -> sleep(0.1с) -> putToken -> sleep(0.1с) -> request» выполнит оба реквеста и между ними интервал будет всего 0.2с, что не вписывается в ограничение по рпс. нужно ли именно такое ограничение на самом деле и стоит ли ради его точного соблюдения тратить лишнюю память на хранение каждого таймстемпа запросов за последнюю секунду — это уже вопрос к автору
Вещественное число, в секундах. Ну если хотите чтобы было целое и в миллисекундах — то счетчик должен будет прирастать за 1000 мс на 10 единиц, т.е. на 0.01 единиц за 1 мс. Формула преобразуется в C_current = C_last-1+(t_current-t_last)*0.01
Дергаете только когда новый запрос приходит. C_current = C_last-1+(t_current-t_last)*10. Достаточно хранить только t_last (таймстемп последнего запроса) и С_last (последний счетчик)
Берете счетчик, устанавливаете его в число rps. Допустим 10 — для 10 rps. Допустим последний запрос был в таймстемп t_last. Счетчик будет пополняться со скоростью 10 единиц в секунду (до максимального значения равного 10).
Когда приходит новый запрос в таймстемп t_current — увеличиваете счетчик на (t_current-t_last) * 10 и уменьшаете на 1. если получилось меньше 0 — значит количество запросов превышено. Если больше — то ок, сохраняете t_last = t_current.
на какой диапазон допустимых значений для «количества операций в секунду» вы ориентировались, разрабатывая этот алгоритм? вы уверены что вам нужно именно точное решение этой задачи и не достаточно приближенного?
я бы порекомендовал посмотреть на TICK stack: telegraf для сбора статистики + influxdb для хранения статистики + kapacitor для ее анализа + chronograf или grafana для визуализации, либо на clickhouse для хранения логов + grafana для визуализации результатов разных хитрых аналитических запросов к этим логам. но и то и другое требует адаптации к конкретно вашему пониманию понятия «поведение» (какие именно аспекты поведения вы хотите анализировать), например могут потребоваться кастомные средства для сбора релевантной для вас статистики по запросам к интересующим вас местам веб-приложения (для последующего хранения в influx'е, если например telegraf тут окажется недостаточно гибким), либо хитро построенные запросы к clickhouse'у. в ряде случаев может потребоваться приделывать дополнительные более удобные кастомные способы визуализации «поведения», нежели просто графики, тут можно посмотреть на d3js
робомобили уже в процессе испытаний, робостоянки появятся сразу как появятся робомобили если будет спрос. а приделать и снять крепление к неподвижному стандартизированному автомобилю — так это обычный промышленный робот справится если спрос на такую услугу будет
и что с этим сделать? сменить мэра? заставить владельца оптимизировать собственный бизнес? заставить владельца перестать ставить родственников на управляющие позиции? подарить этому бизнесу госконтракт на дохренилион денег с повышенной нормой прибыли или уменьшить налоги — и по сути подарить деньги владельцу бизнеса? или смотреть как в городе через 3 месяца начнется разгул преступности?
в случае госсобственности вариантов больше — например кормить предприятие деньгами чтобы оно увольняло персонал не сразу, а на протяжении N лет. или сменить руководство и выделить деньги на оптимизацию предприятия — если что, прибыль достанется государству. или целенаправленно перевезти работников в другие города.
Когда приходит новый запрос в таймстемп t_current — увеличиваете счетчик на (t_current-t_last) * 10 и уменьшаете на 1. если получилось меньше 0 — значит количество запросов превышено. Если больше — то ок, сохраняете t_last = t_current.