Решил зафиксировать текущую версию программы и выпустить в целом стабильную сборку.
Список изменений:
+ Опция: Проверять корректность трека
+ Опция: Обозначить трек красным при ошибке одного из сервисов
+ Новое поле в окне св-в события: Считать дни с этого события
* Парсер сайтов: небольшие доработки
* Импорт из обменного xml-файла: теперь возможен в корень структуры
* Доработан импорт из обменного xml файла, созданного версией программы для iOS
* Ограничения на вызов обновления треков для снижения нагрузки на сервисы от нетерпеливых пользователей
* Сервисы: v098
- Исправлен ряд ошибок
Не сочтите за репрессии, но вынужден ввести ограничения, которые скажутся лишь на нетерпеливых пользователях программы.
Минимальный интервал между запусками обновления всех треков увеличен до получаса.
Так же вызвать обновление выделенных треков можно не чаще 1 раза в минуту.
Прошу понять меня правильно, поддержать и поставить период автоматической проверки треков не менее 3 часов.
Пытаюсь поставить галку Отключить сплеш-скрин при старте. Она ставится, выводится Алерт "Спасибо за оказанную поддержку" и при нажатии на окошке ОК, снова убирает галку.
Насколько я понял, теперь нельзя обновлять несколько выделенных треков. Это не совсем удобно.
Есть более удобный и результативный способ существенно снизить нагрузку на все сервисы.
Для этого нужно сделать, чтобы программа запоминала время, когда обновился каждый трек с каждого отдельного сервиса. Но она должна запоминать только те обновления, которые прошли с положительным результатом (без ошибки). Далее нужно сделать запрет на повторное обновление трека с сервисов, с которых недавно удачно прошло обновление, в течение 1 часа(например). Само собой, обновления с сервисов, которые прошли с ошибкой, должны остаться разрешенными до получения положительного результата (отсутствия ошибки). При запуске повторного обновления трека до истечения этого часа, должны посылаться запросы, только на сервисы выбранного трека(ов), которые более часа не обновлялись удачно (без ошибки), остальные сервисы трека блокируются.
Трек, у которого прошел защитный период хотя бы у одного из сервисов, можно отмечать зеленым цветом. Это будет означать, что он частично или полностью готов к новому обновлению. Треки же, у которых были ошибки при прошлом обновлении, как и раньше должны оставаться красными до повторного обновления. Если у трека все сервисы блокированы, т.е. они все удачно (без ошибки) обновились менее часа назад, то его можно отметить серым цветом, как неактивный, до истечения защитного промежутка времени (в данном случае 1 час).
Таким образом, каждый сервис будет эксплуатироваться не более 1*[общее количество посылок] раз в час. При этом у пользователя не будет ощущения дискомфорта. А главное, будет возможность, которой так не хватает сейчас, а именно повторное обновление трека с сервисов, обновление с которых ранее прошло с ошибкой, без нагрузки на другие сервисы.
Если честно, мучает совесть, что приходится дергать все сервисы, когда идет сбой только у одного (ПР), постоянно обновляя информацию о треке. А отключать и потом включать сервисы обратно, неудобно. А в новой версии еще и приходится ждать.
guru писал(а): когда идет сбой только у одного (ПР), постоянно обновляя информацию о треке
Вот скажите, ЗАЧЕМ постоянно обновлять трек из-за сбоя на ПР?
т.е. "АГА! сервер ПР лежит! дай ка я еще раз жмакну обновить, авось проскочу!" ?
Думаете от того, что сразу после получения ошибки от ПР жать обновление, будет лучше? Сервер тут же заработает?
MetalFan писал(а):Вот скажите, ЗАЧЕМ постоянно обновлять трек из-за сбоя на ПР?
Само собой, я не дергаю обновление, когда вижу, что ПР совсем мертва. Какой смысл?
Повторные обновления нужны, если на сайте ПР проверка работает, но со сбоями, не с первого раза.
Вчера днем, например, программа получала от ПР данные при повторных обновлениях. Обновления проходили в соотношении примерно 1:3(удачно:ошибка) на каждом треке. Только вечером-ночью ситуация ухудшилась и ПР совсем поломалась.
Последний раз редактировалось guru Вт дек 11, 2012 7:56 am, всего редактировалось 1 раз.
Программа ведь может не получить события потому, что, например, сайт обновили (пресловутый ParseError). И как быть в этом случае? Разрешить "задалбливать" сервис? Всё-равно ведь результата не будет.
Мы в любом случае задалбливаем сервис. Но в случае с временной блокировкой после удачного запроса, мы хотя бы защитим исправно работающие сервисы от ненужных повторных запросов.
В конце концов, можно добавить защиту и при ParseError. Например при 3-х подряд ParseError блокировать сервис на 1 час.
Неудобно стало что треки чекаются все вместе, либо по одному но только один раз. Здесь уже вроде писали по этому поводу. Что типа нагрузка на сервер. Но я вот немного "торможу" бывает и хочется сделать чек еще раз, приходится программу перезапускать - неудобно.. На старых версиях такого не было. Но все равно Спасибо за все.
guru писал(а):ни с того ни с сего заработал ГдеПосылка, спустя 3 недели простоя)
ну они же обещали заработать)
mot писал(а):Но я вот немного "торможу" бывает и хочется сделать чек еще раз
Хм, не тормози - сникерсни) не понял, при чем тут программа.
Согласен, немного неудобно... но надеюсь хоть немного снизит нагрузку на чуть-живые сервера сами знаете кого.
mot писал(а):Неудобно стало что треки чекаются все вместе, либо по одному но только один раз. Здесь уже вроде писали по этому поводу. Что типа нагрузка на сервер. Но я вот немного "торможу" бывает и хочется сделать чек еще раз, приходится программу перезапускать - неудобно.. На старых версиях такого не было. Но все равно Спасибо за все.
Вот, видите, MetalFan? Я про это и говорю. Защиту нужно довести до ума. Просто принудительная пауза после обновления трека (назависимо от результата), это неудобно и нерезультативно. Нужно придумать более технологичное и удобное при использовании решение.
guru, Ваше предложение, что мол блокировать обновление только тех сервисов, которые отработали норм, тоже не жизнеспособно и бессмысленно.
Ибо смысл блокировки от частого вызова обновлений как раз в том, чтобы снизить нагрузку на "тормозящие" сервисы типа ПР.
А разрешать "долбить" сервис, который вернул ошибку при предыдущем обновлении - верх безумства.
Если сервер сервиса "тормозит", то такой "долбеж" сделает еще хуже. Если страница сервиса или формат выдаваемой информации поменялся - то тем более "долбежом" тут не поможешь, т.к. необходимо оперативное вмешательство, анализ того, что там поменялось и правка описания сервиса в программе.
Так что запрет на любое частое обновление треков видится мне самым оптимальным решением на данный момент.
Может быть разрешить программе обращаться к вашему серверу, чтобы он регламентировал разрешение обращений к сервисам.
То есть у себя где-то поставили галку - отключить сервис Почты России (например в связи с тем что они сменили формат) и все программы перестали ломиться туда, получив эту информацию.
А вообще я придерживаюсь всё того же мнения... что ерунда это а не нагрузка, по крайней мере для нормального сервиса должно быть так. Иначе бы все постовые службы мира так же изгалялись и загибались.
MetalFan писал(а):Так что запрет на любое частое обновление треков видится мне самым оптимальным решением на данный момент.
Ну, Вам виднее) Я просто предложил вариант, который мне показался приемлемым.
На ГдеПосылка, например, обновление треков возможно не чаще раза в 4 часа. Их пользователи точно не перегружают сервисы)
guru писал(а):Теперь hkpost что-то чудит: hkpost: 12.12.2012 13:46:40 ParseError
Так на всех.
У кого-нибудь работает?
У меня без проблем проверяет…
Это тело всегда находит отдохновение в праздности. Кто может обременить нас почётом или позором, приобретениями или утратами?
Это сердце всегда находит удовольствие в покое. Кто может смутить нас истиной или ложью, выгодой или ущербом?
Хун Цзычен.
