Наконец то запустил из под виртуалки с нуля.
Начальная синхронизация длилась порядка 20 минут. И оценок и пользователей под 70 тыс.
Это ведь "стабильная" инфомация, может грузить ее с прогой как ХМЛ и просто делать импорт в базу?
И трафик уменьшим и время.

Кстати еще заметил, что если еще ни на что не подписался (новая база) при каждой синхронизации забирается по 1000 сообщений "в пустоту"

Здравствуйте, AlexNek, Вы писали:

AN>Начальная синхронизация длилась порядка 20 минут. И оценок и пользователей под 70 тыс.

Ага, кирдык. Когда-то порциями затягивалась, но с отображением частично скачанных данных не захотели заморачиваться, суррогаты подставлять.

Полагаю, лучше предупредить пользователя с возможностью отмены действия, и затянуть всё за 20+ минут, чем.

AN>Это ведь "стабильная" инфомация, может грузить ее с прогой как ХМЛ и просто делать импорт в базу?

Это не "стабильная" информация, она может меняться. Оценки удаляют, пользователи меняют отображаемые имена.

AN>И трафик уменьшим и время.

И кого он сейчас интересует? Янус — приложение не для мобильных телефонов или планшетов.
(И да, когда-то я упорно боролся за уменьшение трафика, сжатие делал с индикацией, каждый байт считал.)

AN>Кстати еще заметил, что если еще ни на что не подписался (новая база) при каждой синхронизации забирается по 1000 сообщений "в пустоту"

Ишь ты. Странный глюк. Тут надо *RowVersion из vars проверить, и снифером посмотреть, что же на самом деле идёт и зачем.
То ли достраивается что, то ли это синхронизация уже, а пустота в списках по др. причинам, а в базу всё идёт пучком.

Здравствуйте, akasoft, Вы писали:

A>Ага, кирдык. Когда-то порциями затягивалась

Начальные оценки — никогда.

Здравствуйте, AlexNek, Вы писали:

AN>Наконец то запустил из под виртуалки с нуля.
AN>Начальная синхронизация длилась порядка 20 минут. И оценок и пользователей под 70 тыс.
AN>Это ведь "стабильная" инфомация, может грузить ее с прогой как ХМЛ и просто делать импорт в базу?
AN>И трафик уменьшим и время.

AN>Кстати еще заметил, что если еще ни на что не подписался (новая база) при каждой синхронизации забирается по 1000 сообщений "в пустоту"

Это все форумы мусора

Здравствуйте, AndrewVK, Вы писали:

AVK>Начальные оценки — никогда.

Посмотрел свои старые сообщения — да, ты прав. Попутал с пользователями.

Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, AlexNek, Вы писали:

AN>>Начальная синхронизация длилась порядка 20 минут. И оценок и пользователей под 70 тыс.

A>Ага, кирдык. Когда-то порциями затягивалась, но с отображением частично скачанных данных не захотели заморачиваться, суррогаты подставлять.

A>Полагаю, лучше предупредить пользователя с возможностью отмены действия, и затянуть всё за 20+ минут, чем.
А чем это будет лучше? Отменить закачку, для пользователей, конечно можно, но 70 тыс нужно все равно когда то взять.

AN>>Это ведь "стабильная" инфомация, может грузить ее с прогой как ХМЛ и просто делать импорт в базу?

A>Это не "стабильная" информация, она может меняться. Оценки удаляют, пользователи меняют отображаемые имена.
Предположим, я закачал базу 1 января, немного поработал и затем снова решил работать уже через Х дней. Исправится ли в этом случае база, согласно новым оценкам и пользователям? Мне кажется что да. То бишь информация будет стабильной на момент закачки для всех пользователей и затем она может просто корректироваться. Хочется, чтобы можно было сразу работать не ожидая относительно долгое время. Да и разработчики, не показываются если их нет в базе.
По крайней мере, я не вижу пока ни одного довода отчего так не следует делать. (Предоставлять уже наполненную базу)

AN>>И трафик уменьшим и время.

A>И кого он сейчас интересует? Янус — приложение не для мобильных телефонов или планшетов.
A>(И да, когда-то я упорно боролся за уменьшение трафика, сжатие делал с индикацией, каждый байт считал.)
Трафик вроде сервер интересует, хотя действительно при нынешнем количестве установок это не проблема.
А вот время гораздо более важно, мне кажется.

AN>>Кстати еще заметил, что если еще ни на что не подписался (новая база) при каждой синхронизации забирается по 1000 сообщений "в пустоту"

A>Ишь ты. Странный глюк. Тут надо *RowVersion из vars проверить, и снифером посмотреть, что же на самом деле идёт и зачем.
A>То ли достраивается что, то ли это синхронизация уже, а пустота в списках по др. причинам, а в базу всё идёт пучком.
Я еще не разбирался совсем

Здравствуйте, _Raz_, Вы писали:

_R_>Здравствуйте, AlexNek, Вы писали:

AN>>Наконец то запустил из под виртуалки с нуля.
AN>>Начальная синхронизация длилась порядка 20 минут. И оценок и пользователей под 70 тыс.
AN>>Это ведь "стабильная" инфомация, может грузить ее с прогой как ХМЛ и просто делать импорт в базу?
AN>>И трафик уменьшим и время.

AN>>Кстати еще заметил, что если еще ни на что не подписался (новая база) при каждой синхронизации забирается по 1000 сообщений "в пустоту"

_R_>Это все форумы мусора
Спасибки за наводку, бум иметь в виду

Здравствуйте, AlexNek, Вы писали:

AN>А чем это будет лучше? Отменить закачку, для пользователей, конечно можно, но 70 тыс нужно все равно когда то взять.

Нет, отменять в процессе не надо. Просто вывести предупреждение при первом запуске, что надо скачать N элементов списка пользователей, что займёт M минут времени и прочее бла-бла-бла. И продолжить-отменить.

Лучше хранения тем, что не храним в инсталляторе персональную информацию (да, там нет имён, адресов и паспортных данных, хотя нет, имена иногда есть), не нужно её обновлять раз в N месяцев (никто этого не будет делать, разве что скрипт ночных сборок из БД RSDN), не будет рассинхронизации с БД сервера (информация в xml устареет сразу по созданию файла), не будет показана заведомо ложная и вводящая в заблуждение информация (удалённые оценки, др. имена пользователей, сообщения/оценки от пользователей, которых ещё нет в ЛБД), etc

AN>По крайней мере, я не вижу пока ни одного довода отчего так не следует делать. (Предоставлять уже наполненную базу)

Выше написал.
Плюс установка — редкая одноразовая операция по отношению к периодической синхронизации.

AN>А вот время гораздо более важно, мне кажется.

Думаю, что один раз можно подождать.
Наверное, сервер ограничивает скорость отдачи на соединение. Надо у AVK спросить, есть ли ограничения. Иначе будет забираться со скоростью канала конкретного пользователя Януса.

Здравствуйте, akasoft, Вы писали:

a> AN>А чем это будет лучше? Отменить закачку, для пользователей, конечно можно, но 70 тыс нужно все равно когда то взять.

a> Нет, отменять в процессе не надо. Просто вывести предупреждение при первом запуске, что надо скачать N элементов списка пользователей, что займёт M минут времени и прочее бла-бла-бла. И продолжить-отменить.
Может тогда уж лучше спросить закачать все по новому или обновить?

a> Лучше хранения тем, что не храним в инсталляторе персональную информацию (да, там нет имён, адресов и паспортных данных, хотя нет, имена иногда есть),
А чем проблема когда эти данные все равно прийдут на комп.
a> не нужно её обновлять раз в N месяцев (никто этого не будет делать, разве что скрипт ночных сборок из БД RSDN),
А для чего ее обновлять вообще? После первой синхронизации и обновится, главное основной массив будет кже на клиенте.
a> не будет рассинхронизации с БД сервера (информация в xml устареет сразу по созданию файла), не будет показана заведомо ложная и вводящая в заблуждение информация (удалённые оценки, др. имена пользователей, сообщения/оценки от пользователей, которых ещё нет в ЛБД), etc
Ну тогда нельзя пользоваться любым офлайн бровсером, потому как сразу после синхронизации все устаревает. А что может быть вообще видно без синхронизации, когда нет ни одной темы. Разве что окно с разработчиками.

a> Плюс установка — редкая одноразовая операция по отношению к периодической синхронизации.
Да но она самая первая, когда хочется сразу все попробовать, а тут жди...

a> AN>А вот время гораздо более важно, мне кажется.

a> Думаю, что один раз можно подождать.
Ну кому как

Здравствуйте, AlexNek, Вы писали:

Если я правильно помню, есть четыре обновляемые сущности: Forum, Moder, Rating и User.
Для каждой есть своя метка синхронизации: LastXXXRowVersion.

В пустой базе она null или 0, не помню. Суть в том, когда на службу придёт запрос от януса по сущности с указанием 0 — будет считаться, что это новый клиент и ему будет отдана сущность по её правилам. Для сообщений — сегодняшние порциями по 1000. Для пользователей и пр. идут все.
Протоколом предусмотрено получение комплекта данных и новой метки синхронизации. Соответственно, если Янус следующий запрос сделает с полученной меткой, служба отдаст ему следующую порцию и новую метку. Если запрос будет со старой меткой, будет дуб, орех или мочало.

Наверное, если сделать три xml с данными для Moder, Rating и User и с метками синхронизации, то твоя идея сработает, а выкачиваться будут только новые данные. Но вот кто их будет делать и как обновлять для подготовки инталлятора? Думаю, из существующей БД такие данные брать неверно, может повлиять индивидуальная подписка на форумы и хвосты N лет работы, надо обнулить БД и закачать заново, затем экспортировать. Есть ещё особенность, связанная с членством в команде RSDN, им видны ещё форумы не для всех. А там тоже оценки и пр. Соответственно, там метка синхронизации, что годится обычному пользователю, может быть неверное для тимера. Это аргумент, почему лучше скачать, сем хранить.
Другой аргумент, про хранение персональных данных, я уже приводил. Данные по User — какие-никакие, а персональные.
Ну и третий, а кто это всё будет делать на регулярной основе — экспортировать xml с метками синхронизации с нуля и собирать инсталлятор? Если же качать, то каждый получит своё и актуальное, но надо подождать.

Здравствуйте, akasoft, Вы писали:

A>Для сообщений — сегодняшние порциями по 1000. Для пользователей и пр. идут все.

Для пользователей тоже разовый пакет ограничен 1000 штук.

Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, AlexNek, Вы писали:

A>Если я правильно помню, есть четыре обновляемые сущности: Forum, Moder, Rating и User.
A>Для каждой есть своя метка синхронизации: LastXXXRowVersion.
по описанию я нашел следующие упоминания о RowVersion, так что их действительно 4

ratingRowVersion
messageRowVersion
moderateRowVersion

lastRatingRowVersion
lastForumRowVersion
lastModerateRowVersion
forumsRowVersion

A>В пустой базе она null или 0, не помню. Суть в том, когда на службу придёт запрос от януса по сущности с указанием 0 — будет считаться, что это новый клиент и ему будет отдана сущность по её правилам. Для сообщений — сегодняшние порциями по 1000.
A>Для пользователей и пр. идут все.
пользователи точно идут по 1000, так как я специально это для себя правил.
A>Протоколом предусмотрено получение комплекта данных и новой метки синхронизации. Соответственно, если Янус следующий запрос сделает с полученной меткой, служба отдаст ему следующую порцию и новую метку. Если запрос будет со старой меткой, будет дуб, орех или мочало.

A>Наверное, если сделать три xml с данными для Moder, Rating и User и с метками синхронизации, то твоя идея сработает, а выкачиваться будут только новые данные.
досточно будет просто копии базы с заполненными Rating и User, так как про модерирование никаких сообщений при синхронизации не получал еще ни разу, но можно будет проверить, может их просто нет.
A>Но вот кто их будет делать и как обновлять для подготовки инталлятора?
Можно будет раз в год делать просто делать синхронизацию в новую базу без всякой подписки. А может будет достаточно и реже.
A>Думаю, из существующей БД такие данные брать неверно, может повлиять индивидуальная подписка на форумы и хвосты N лет работы, надо обнулить БД и закачать заново, затем экспортировать.
A>Есть ещё особенность, связанная с членством в команде RSDN, им видны ещё форумы не для всех. А там тоже оценки и пр. Соответственно, там метка синхронизации, что годится обычному пользователю, может быть неверное для тимера. Это аргумент, почему лучше скачать, сем хранить.
Об этом я просто не знал, но так как таковых довольно мало и они по идее уже все себе выбрали для работы я бы их просто исключил из рассмотрения. При желании ничего не помешает им создать новую базу с нуля или можно просто сделать опцию при установке — "копировать базу по умолчанию".
A>Другой аргумент, про хранение персональных данных, я уже приводил. Данные по User — какие-никакие, а персональные.
Это аргумент до меня никак не доходит. Ведь эти данные открытые и любой желающий их и так может скачать.
A>Ну и третий, а кто это всё будет делать на регулярной основе — экспортировать xml с метками синхронизации с нуля и собирать инсталлятор? Если же качать, то каждый получит своё и актуальное, но надо подождать.
Тогда можно спросить, а будет ли кто сетап делать на регулярной основе? Может поэтому от сетапа и отказались? По крайней мере пока, одной копии будет достаточно, в любом случае, будет экономия за годы от старта.

Здравствуйте, AlexNek, Вы писали:

A>>Наверное, если сделать три xml с данными для Moder, Rating и User и с метками синхронизации, то твоя идея сработает, а выкачиваться будут только новые данные.
AN>досточно будет просто копии базы с заполненными Rating и User, так как про модерирование никаких сообщений при синхронизации не получал еще ни разу, но можно будет проверить, может их просто нет.
A>>Но вот кто их будет делать и как обновлять для подготовки инталлятора?
AN>Можно будет раз в год делать просто делать синхронизацию в новую базу без всякой подписки. А может будет достаточно и реже.
A>>Думаю, из существующей БД такие данные брать неверно, может повлиять индивидуальная подписка на форумы и хвосты N лет работы, надо обнулить БД и закачать заново, затем экспортировать.
A>>Есть ещё особенность, связанная с членством в команде RSDN, им видны ещё форумы не для всех. А там тоже оценки и пр. Соответственно, там метка синхронизации, что годится обычному пользователю, может быть неверное для тимера. Это аргумент, почему лучше скачать, сем хранить.
AN>Об этом я просто не знал, но так как таковых довольно мало и они по идее уже все себе выбрали для работы я бы их просто исключил из рассмотрения. При желании ничего не помешает им создать новую базу с нуля или можно просто сделать опцию при установке — "копировать базу по умолчанию".

Я не пойму, вы все еще про первый запуск? Если да, то почему вы считаете текущее поведение януса верным? Там же баг. Зачем пользователю при первой синхронизации форумы и пользователи мусора (к тому же, я так подозреваю, что полностью).

MessagesSyncTask.GetSubscribedForums:

            yield return new RequestForumInfo { forumId = 0, isFirstRequest = false }; // trash 1
            yield return new RequestForumInfo { forumId = 58, isFirstRequest = false }; // trash 2

Попробуйте заминить на isFirstRequest = true и удивитесь результату

Здравствуйте, _Raz_, Вы писали:

_R_>Здравствуйте, AlexNek, Вы писали:

A>>>Наверное, если сделать три xml с данными для Moder, Rating и User и с метками синхронизации, то твоя идея сработает, а выкачиваться будут только новые данные.
AN>>досточно будет просто копии базы с заполненными Rating и User, так как про модерирование никаких сообщений при синхронизации не получал еще ни разу, но можно будет проверить, может их просто нет.
A>>>Но вот кто их будет делать и как обновлять для подготовки инталлятора?
AN>>Можно будет раз в год делать просто делать синхронизацию в новую базу без всякой подписки. А может будет достаточно и реже.
A>>>Думаю, из существующей БД такие данные брать неверно, может повлиять индивидуальная подписка на форумы и хвосты N лет работы, надо обнулить БД и закачать заново, затем экспортировать.
A>>>Есть ещё особенность, связанная с членством в команде RSDN, им видны ещё форумы не для всех. А там тоже оценки и пр. Соответственно, там метка синхронизации, что годится обычному пользователю, может быть неверное для тимера. Это аргумент, почему лучше скачать, сем хранить.
AN>>Об этом я просто не знал, но так как таковых довольно мало и они по идее уже все себе выбрали для работы я бы их просто исключил из рассмотрения. При желании ничего не помешает им создать новую базу с нуля или можно просто сделать опцию при установке — "копировать базу по умолчанию".

_R_>Я не пойму, вы все еще про первый запуск?
Да
_R_>Если да, то почему вы считаете текущее поведение януса верным?
чисто по ожидаемому количеству записей.
_R_>Там же баг. Зачем пользователю при первой синхронизации форумы и пользователи мусора (к тому же, я так подозреваю, что полностью).
Попробую, но как то не уверен что они отъедают основное время. По крайней мере, для 70 тыс пользователей нужно у меня около 10 минут.

_R_>MessagesSyncTask.GetSubscribedForums:
_R_>

_R_>            yield return new RequestForumInfo { forumId = 0, isFirstRequest = false }; // trash 1
_R_>            yield return new RequestForumInfo { forumId = 58, isFirstRequest = false }; // trash 2
_R_>

_R_>Попробуйте заменить на isFirstRequest = true и удивитесь результату
Никаких форумов я вообще не грузил, так как подписки не было.

Здравствуйте, AlexNek, Вы писали:

AN>досточно будет просто копии базы с заполненными Rating и User..

Ты хочешь сказать, четырёх разных копий БД под весь поддерживаемый зоопарк?
Не проще ли импортировать?

AN>Тогда можно спросить, а будет ли кто сетап делать на регулярной основе? Может поэтому от сетапа и отказались? По крайней мере пока, одной копии будет достаточно, в любом случае, будет экономия за годы от старта.

Если ты меня спрашиваешь, то я думаю, что лучше всех бы его собирал скрипт на сервере, на регулярной основе. Там у него есть доступ и к SVN, и к эталонной БД, и куда выложить есть.

Здравствуйте, AlexNek, Вы писали:

_R_>>Если да, то почему вы считаете текущее поведение януса верным?
AN>чисто по ожидаемому количеству записей.
За сутки перед первой синхронизацией 70 тыс. пользователей? Зачем мне иметь локальную таблицу мертвых душ?

Здравствуйте, akasoft, Вы писали:

A>Здравствуйте, AlexNek, Вы писали:

AN>>досточно будет просто копии базы с заполненными Rating и User..

A>Ты хочешь сказать, четырёх разных копий БД под весь поддерживаемый зоопарк?
Нет, я думал об этом и решил не делать поддержку зоопарку. Будет одна база по умолчанию которую можно при желании мигрировать в другую. Иначе, кроме написания экспорта и импорта, нужно еще как то решать проблемы обновления структуры базы (если вдруг понадобится). Так же, старая структура обновится автоматом.

A>Не проще ли импортировать?

AN>>Тогда можно спросить, а будет ли кто сетап делать на регулярной основе? Может поэтому от сетапа и отказались? По крайней мере пока, одной копии будет достаточно, в любом случае, будет экономия за годы от старта.

A>Если ты меня спрашиваешь, то я думаю, что лучше всех бы его собирал скрипт на сервере, на регулярной основе.
Данный скрипт нужно кому еще и писать и отлаживать, да и не хочется привязки к серверу. И не думаю, что кто то даст "играться" со скриптом на рабочем сервере.
A>Там у него есть доступ и к SVN, и к эталонной БД, и куда выложить есть.

Здравствуйте, _Raz_, Вы писали:

_R_>Здравствуйте, AlexNek, Вы писали:

_R_>>>Если да, то почему вы считаете текущее поведение януса верным?
AN>>чисто по ожидаемому количеству записей.
_R_>За сутки перед первой синхронизацией 70 тыс. пользователей? Зачем мне иметь локальную таблицу мертвых душ?
В любом случае она будет, просто сейчас, в основной ветке, за 70 синхронизаций, при этом всей возможной информации просто не будет, по "неизвестной причине". Типа кликаешь меню "о разработчиках", а там пусто или один два.

Здравствуйте, AlexNek, Вы писали:

_R_>>За сутки перед первой синхронизацией 70 тыс. пользователей? Зачем мне иметь локальную таблицу мертвых душ?
AN>В любом случае она будет, просто сейчас, в основной ветке, за 70 синхронизаций, при этом всей возможной информации просто не будет, по "неизвестной причине".
Ты же и спрашивал как уйти от 70 синхронизаций — легко, починяя баг.

AN>Типа кликаешь меню "о разработчиках", а там пусто или один два.
Это другой вопрос.

Здравствуйте, _Raz_, Вы писали:

_R_>Здравствуйте, AlexNek, Вы писали:

_R_>>>За сутки перед первой синхронизацией 70 тыс. пользователей? Зачем мне иметь локальную таблицу мертвых душ?
AN>>В любом случае она будет, просто сейчас, в основной ветке, за 70 синхронизаций, при этом всей возможной информации просто не будет, по "неизвестной причине".
_R_>Ты же и спрашивал как уйти от 70 синхронизаций — легко, починяя баг.
То бишь ничего не будет качаться, тогда это не баг

AN>>Типа кликаешь меню "о разработчиках", а там пусто или один два.
_R_>Это другой вопрос.
Вопрос комплексный, нельзя убирая одно убивать другое. "Разработчики", не единственное место, где используется информация о пользователях. Помню еще "Администрация форума"