Когда я "последний раз" искал что-то для фоновых заданий — брать большие комплексы типа Hangfire не хотелось из-за требования БД, а изощренные (извращенные) расписания для запуска типа "каждый понедельник в 8 утра, во вторник каждые 10 минут" с одной стороны были слишком заумными и нереальными, с другой стороны сразу же возникают опасения "что если при 10 минутном запуске задача будет выполнять 12 минут — запустится ли вторая не дожидаясь конца первой".
В итоге сделал свой велосипед RecurrentTasks — обычный Task просыпается, делает что надо и снова засыпает на заданный интервал. При этом для "сложных" задач, которые должны работать лишь "трижды в день" — все равно где-то в бизнес-требованиях есть "дата последнего запуска" той или иной функции — в итоге удобно оказалось сделать что таск стартует раз в 20-30 минут, считывает дату из реальной базы и "делает дело" только если надо. Заодно этим решается проблема "если приложение было выключено в заданное время" — при следующем запуске все отработает. Периодом можно управлять прямо внутри основного метод: если очередь пустая то следующий раз читать ее "через минуту", если еще что-то есть — "через 10 секунд".
Вью разные бывают и пусть и не 100500, но таблицу из 800 строк без пейджинга (не потому что лень а потому что так надо) отображать приходится.
Плюс не каждый вью пользователю на экран выводится — генерацию экспортных файлов часто удобнее через RazorEngine завернуть.
Так что размер экономии в каждом случае оценивается отдельно.
Что касается «граблей» — я не считаю граблями возможность пораньше диспозить ресурсы или необходимость вдумчивао относиться к открытым ридерам. Да и с отладкой — не припомню случая когда мне надо было подсмотреть выборку «целиком» именно в режиме отладки — она ж следом мне на экран выведется, там все и видно. А если с каким отдельным объектом «проблемы» — ну так внутри цикла я именно на него и попаду при ошибке.
А вы в Dispose у контроллера вызываете Dispose у DbContext-а?
Конечно, все в лучших традициях msdn-а.
Если его вовремя не диспозить, то у вас под нагрузкой могут полезть проблемы в связи с исчерпанием доступных соединений к базе и веб-приложение встанет раком.
Не, эти грабли уже давно собраны.
К сожалению рака в повальном выживании Gen0 придется искать дальше :(
Нагрузка копеечная и даже меньше. Однако за 23часа при GC.CollectionCount(0) = 2200 имею CollectionCount(1) = 1800 вместо «нормального» соотношения 10-к-1… (gen2 «нормально» — 179).
Я рассчитывал что раз Controller реализует IDisposable то этим кто-то пользуется и не проверял… Разве нет?
А о каком количестве объектов тогда идет речь? Считанные из БД объекты будут нужны до конца запроса в любом случае — они нужны view. Создание проксей и lazy load можно отключить (не уверен что отключаю везде, но по максимуму старался) настройками DbContext. Остается сам коннект и его «дерево» вспомогательных объектов? Вряд ли там объектов сравнимо с количеством объектов считанных данных и всей остальной инфраструктуры mvc…
Было, и здесь стоит «двойная защита». Во-первых здесь «внешний» список все же считываю сразу в память и уже бегу по нему. Во вторых в продакшне включил MultipleRecordset или как-то так (позволяет более одного ридера одновременно в ms sql). Соответственно на девелопе/тесте «должно свалиться» если где-то оставляю два ридера, а продакшн отработает если проглядел при тестировании.
Ой, а я специально в mvc4 во вью отдаю IEnumerable полученный из EF без конвертации в лист/массив, чтобы не плодить в памяти сразу 100500 объектов, а дать шанс сборщику мусора убивать «пройденные». DbContext создается в конструкторе и закрывается в Dispose.
Упс, ниже прочитал что не встроен. Хотя та часть бара, которая «полезна пользователю» — будет встроена, просто пользователю об этом не обязательно говорить и уметь отключать кнопками.
В 1С конечно надо вносить кучу всяких улучшений, но показанное на картинке, извините, фигня полная.
Во-первых, все-таки решите, от имени кого все пишется. Ибо "Желатете..." и "Я ... предпочту" навевает на мысли, что где-то пользователь должен угадывать мысли разработчика.
Во-вторых, одинаковые поназначению кнопки должны называться по-разному. "Начать сначала" и "Ощутить заново" это ведь очистка списка?
В целом для правильного формулирования надписей может помочь MS Vista User Experience Guidelines ( http://msdn2.microsoft.com/en-us/library/aa511440.aspx ) - может конечно и не идеал, но кое-что полезное точно найдется.
Касательно тональности текстов в целом - сначала прикольно, потом пользователи уже не будут читать большинство из них, а будут тыкать на автомате, считывая "в фоне". А если ваша обработка в таком стиле только одна - они будут тормозиться при фоновом считывании просто не увидев привычного "Добавить" (мозг кинет Исключение, его надо будет обработать).
Теперь перейдем непосредственно к 1С (увы, был небольшой опыт).
Надеюсь вы сделаете все параметры запоминаемыми? Без того утомительного нажимания на "Сохранить настройки" только ради того чтобы там поставить галочку "Загружать по умолчанию" (или как она там в 7-ке)? Автоматически должны запоминаться последние настройки без даже единичных действий со стороны юзера.
Обязательно надо уделить внимание выбору дат - кнопка с тремя точками ведь "Выбор периода" открывает? Вот если пользователь там выберет "Весь год", то при следующем открытии там должно стоять именно "Весь год", а не фиксированные даты с 01.01.200* по 31.12.200*.
Или вот списки контагентов/номенклатуры - можно например из экселя скопировать и сюда вставить? Допустим что написание совпадает (взяли из другого отчета по той же базе).
Только не спрашивайте КАК все это сделать - понятия не имею. Подозреваю даже что невозможно. Но именно в этом проблема 1С, а не в скучных надписях :(
Обычна дата - влезет, но откаты то никто не отменял 😄
Начиная с ASP.Net Core 2.1 где появился
IHostedService— дернется cancellation token, а дальше уж смотря как написан "полезный" код таска.Когда я "последний раз" искал что-то для фоновых заданий — брать большие комплексы типа Hangfire не хотелось из-за требования БД, а изощренные (извращенные) расписания для запуска типа "каждый понедельник в 8 утра, во вторник каждые 10 минут" с одной стороны были слишком заумными и нереальными, с другой стороны сразу же возникают опасения "что если при 10 минутном запуске задача будет выполнять 12 минут — запустится ли вторая не дожидаясь конца первой".
В итоге сделал свой велосипед RecurrentTasks — обычный Task просыпается, делает что надо и снова засыпает на заданный интервал. При этом для "сложных" задач, которые должны работать лишь "трижды в день" — все равно где-то в бизнес-требованиях есть "дата последнего запуска" той или иной функции — в итоге удобно оказалось сделать что таск стартует раз в 20-30 минут, считывает дату из реальной базы и "делает дело" только если надо. Заодно этим решается проблема "если приложение было выключено в заданное время" — при следующем запуске все отработает. Периодом можно управлять прямо внутри основного метод: если очередь пустая то следующий раз читать ее "через минуту", если еще что-то есть — "через 10 секунд".
Вью разные бывают и пусть и не 100500, но таблицу из 800 строк без пейджинга (не потому что лень а потому что так надо) отображать приходится.
Плюс не каждый вью пользователю на экран выводится — генерацию экспортных файлов часто удобнее через RazorEngine завернуть.
Так что размер экономии в каждом случае оценивается отдельно.
Что касается «граблей» — я не считаю граблями возможность пораньше диспозить ресурсы или необходимость вдумчивао относиться к открытым ридерам. Да и с отладкой — не припомню случая когда мне надо было подсмотреть выборку «целиком» именно в режиме отладки — она ж следом мне на экран выведется, там все и видно. А если с каким отдельным объектом «проблемы» — ну так внутри цикла я именно на него и попаду при ошибке.
Конечно, все в лучших традициях msdn-а.
Не, эти грабли уже давно собраны.
К сожалению рака в повальном выживании Gen0 придется искать дальше :(
Я рассчитывал что раз Controller реализует IDisposable то этим кто-то пользуется и не проверял… Разве нет?
А о каком количестве объектов тогда идет речь? Считанные из БД объекты будут нужны до конца запроса в любом случае — они нужны view. Создание проксей и lazy load можно отключить (не уверен что отключаю везде, но по максимуму старался) настройками DbContext. Остается сам коннект и его «дерево» вспомогательных объектов? Вряд ли там объектов сравнимо с количеством объектов считанных данных и всей остальной инфраструктуры mvc…
Работает, су** уже год. Что я делаю не так?
Если отметить чекбоксы у нескольких сообщений и кликнуть на Ответить - что будет? Массовая рассылка? :)
"Одинаковые по назначению кнопки НЕ должны называться по-разному"
Во-первых, все-таки решите, от имени кого все пишется. Ибо "Желатете..." и "Я ... предпочту" навевает на мысли, что где-то пользователь должен угадывать мысли разработчика.
Во-вторых, одинаковые поназначению кнопки должны называться по-разному. "Начать сначала" и "Ощутить заново" это ведь очистка списка?
В целом для правильного формулирования надписей может помочь MS Vista User Experience Guidelines ( http://msdn2.microsoft.com/en-us/library/aa511440.aspx ) - может конечно и не идеал, но кое-что полезное точно найдется.
Касательно тональности текстов в целом - сначала прикольно, потом пользователи уже не будут читать большинство из них, а будут тыкать на автомате, считывая "в фоне". А если ваша обработка в таком стиле только одна - они будут тормозиться при фоновом считывании просто не увидев привычного "Добавить" (мозг кинет Исключение, его надо будет обработать).
Теперь перейдем непосредственно к 1С (увы, был небольшой опыт).
Надеюсь вы сделаете все параметры запоминаемыми? Без того утомительного нажимания на "Сохранить настройки" только ради того чтобы там поставить галочку "Загружать по умолчанию" (или как она там в 7-ке)? Автоматически должны запоминаться последние настройки без даже единичных действий со стороны юзера.
Обязательно надо уделить внимание выбору дат - кнопка с тремя точками ведь "Выбор периода" открывает? Вот если пользователь там выберет "Весь год", то при следующем открытии там должно стоять именно "Весь год", а не фиксированные даты с 01.01.200* по 31.12.200*.
Или вот списки контагентов/номенклатуры - можно например из экселя скопировать и сюда вставить? Допустим что написание совпадает (взяли из другого отчета по той же базе).
Только не спрашивайте КАК все это сделать - понятия не имею. Подозреваю даже что невозможно. Но именно в этом проблема 1С, а не в скучных надписях :(
если я сейчас правильно нашел параметр, то это ag[format]:
> rar a -agYYYYMMDD test.rar *.*
Creating archive test20071224.rar...