Воронежский АИС-архив

На сайте ВГД собираются люди, увлеченные генеалогией, историей, геральдикой и т.д. Здесь вы найдете собеседников, экспертов, умелых помощников в поисках предков и родственников. Вам подскажут где искать документы о павших в боях и пропавших без вести, в какой архив обратиться при исследовании родословной своей семьи, помогут определить по старой фотографии принадлежность к воинским частям, ведомствам и чину. ВГД - поиск людей в прошлом, настоящем и будущем!

В системе нужна регистрация, для полноценного просмотра документов

1. Воронежский АИС - архив
2. Государственный архив общественно-политической истории Воронежской области(ГАОПИ)
3. Государственный архив Воронежской области документов по личному составу

Источник:
http://gavo.arsvo.ru:8082/Default.aspx?ReturnUrl=/
Вход в государственную информационную систему Воронежской области «Информационно – поисковая система цифрового фонда пользования на документы Архивного фонда Воронежской области» (далее – ГИС ВО «ИПС ЦФП АФ ВО») казенного учреждения Воронежской области «Государственный архив Воронежской области» (п.1), казенного учреждения Воронежской области «Государственный архив общественно – политической истории Воронежской области» (п.2), казенного учреждения Воронежской области «Государственный архив Воронежской области документов по личному составу» (п.3) осуществляется по единому входу ГИС ВО «ИПС ЦФП АФ ВО». (источник информации - https://arsvo.ru/vhod-v-gis/ )

Инструкция. Как заказать дела в АИС

Нажмите на "скрытый текст"

Нажмите на ссылку:
Памятка пользователям АИС для получения доступа к электронным копиям

Техническая поддержка

Если учётная запись заблокирована, или не получается зарегистрироваться в АИС,
или возникают другие вопросы, то пишите по эл.адресам

Актуальные почты по техническим вопросам АИС:
vsbrodova@govvrn.ru - Сбродова Виктория Евгеньевна;
teratkina@govvrn.ru - Ераткина Татьяна Сергеевна.

ВАЖНО!!! Жмите на ссылку:

Обратите внимание на сообщение

ПОЛЕЗНАЯ ИНФОРМАЦИЯ (жмите на ссылки):

1-я

2-я

Инструкция. Как узнать об электронной версии дел

Нажмите на "скрытый текст"

посмотрел, вот скриншот приложу даже, что сделал это на самом деле:
80 порта я не нашел, как и загрузок js лишних,

нужные картинки отдает вот этот хандлер по GET запросу, типа вот такому:
http://gavo.arsvo.ru:8082/Page...amp;Zoom=1
можете попробовать в адресной строке ввести, в авторизованной сессии он по идее будет отдавать лист из моего дела
(сомневаюсь что там есть проверки доступа к этому листу для конкретного пользователя).
Бросилось в глаза несколько запросов с разным параметрами в начале просмотра листа, они подгружают уменьшенные изображения для работы на клиенте. Они как бы не нужны, но зачем-то их с сервера берут:

[Full request URI: http://gavo.arsvo.ru:8082/Page...archtext=]
[Full request URI: http://gavo.arsvo.ru:8082/Page...archtext=]
[Full request URI: http://gavo.arsvo.ru:8082/Page...archtext=]
[Full request URI: http://gavo.arsvo.ru:8082/Page...archtext=]

здесь отличия только в параметре level, если обратите внимание

дальше по механике того что происходит и как работает этот HTTP Handler:
по такой вот ссылке он берет из ссылки идентификатор id, далее он по этому id найдет где физически забрать файл, какой-то путь к файловому хранилищу. Он должен прочитать исходное содержимое файла и потом применить инструкции, которые он тоже берет из запроса, level такой-то, x такой-то, y такой и т.д. Смысл некоторых параметров в этом запросе мне не очень понятен, например, координаты XY, зачем они? но это там уже внутри логика. tileOverlap это водяные знаки скорее всего - да/нет.
Результат он выдаст браузеру пользователя и поместит его в серверный кэш, если такие настройки есть, а они есть. Вот то что он выдал, доходит до браузера и попадает уже в на ваш экран где вы должны его видеть (почему не видно, второй вопрос), и кэш браузера в где вы его потом находите.

Что я отчетливо вижу, что главная задержка возникает именно на первом этапе подъема файла из хранилища (откуда там он грузится я не знаю, это может быть файловая система или БД), при первом обращении по такой ссылке.
как только файл загрузился в серверный кэш, повторные загрузки идут быстро, не мгновенно, канал все-таки узкий, но быстро.
А вот первая - нет. И даже не всегда успешно.

там на картинке есть 80 порт,
но там по нему в запросе ссылка
[Full request URI: http://init-p01md.apple.com/bag?ix=2]
это что-то непонятное, но к ГАВО точно отношения не имеет

AleksandrVL написал:

[q]
какие выводы в итоге ,в чем проблема
[/q]

я думаю, что проблема не в канале, в этом ImageFilePart.ashx,
То что мне ЭЛАР сказал по телефону, что они ГАВО помочь не могут, не значит вообще ничего.
Я там никого не знаю, зашел с улицы, но предполагаю, что они хвостом не пошевелят, чтобы что-то бесплатно делать, договора нет.
Закалены уже многолетней работой с госзаказом.

сотрудники ГАВО, вы читаете??

yab написал:

[q]
я думаю, что проблема не в канале, в этом ImageFilePart.ashx,
[/q]

но и канал тоже надо расширять обязательно, это с повестки не снимается.

yab написал:

[q]
я думаю, что проблема не в канале, в этом ImageFilePart.ashx
[/q]

Интересно, можно ли его совсем убрать из цепочки обработки вывода изображений? Победить проблему "малой кровью".
По мне, такого рода "красивости" вообще ни к чему. А уж тем более, когда они весь функционал рушат на корню.

По-поводу же места хранения файлов - это (уверен практически на 100%) файловая система. Не база данных. В базе - только индексная (поисковая) информация. Сама методика такого рода работ по оцифровке данных ЭЛАРом это предполагает.

a-KaDeMi-k написал:

[q]
Интересно, можно ли его совсем убрать из цепочки обработки вывода изображений? Победить проблему "малой кровью".
[/q]

неет, убрать его нельзя, да и не зачем, он же выполняет важную часть работы, от которой не избавиться, и это не красивость,
почему Вы говорите, а часть общей системы, там все верно, я бы так же делал. Просто он сейчас не работает как должно.
Теоретический спор, где лучше хранить изображения в БД или в файловой системе в то время, когда я к этому имел отношение, велся, и это был вопрос предпочтений и проекта. Я за БД, там больше возможностей. Но сейчас же вообще технологии другие. Облака и пр.
Если бы хранилось в БД вряд-ли бы наблюдались такие задержки. Бывали случаи, когда какое-нибудь обновление виндовс влияло на схему с файловым хранением.

Файлы в базах никто не хранит, только метаданные.
Этот хэндлер работает прекрасно, отдает картинку с такой скоростью с какой может, но без сбоев. Я писал выше что до НГ картинка отдавалась полностью в 1 случае из 20-50 запросов, это была полная

Сейчас - стабильный результат.

Раз уж мы начали лезть во влажные технические подробности... С год назад картинка отдавалась по частям - для этого параметры x,y и нужны - координаты верхнего левого угла. Полная картина в тот момент не передавалась. Затем, видимо, начали искать где выкроить немноженько полосы пропускания в условиях дефицита - полагаю что решили сразу отдавать полную картинку без этого многократного мельтешения по частям. Но вот промежуточные уровни детализации толи специально отставили толи не получилось вырезать, не знаю. Это мои домыслы.

По поводу сессии, которая длится ровно 1 час и сбрасывается в 00 минут - я такого поведения не наблюдаю, сессии держатся часами.

Самое актуальное что нужно пофиксить - это "потерю" порта 8082. Эта проблема может проявится через 100 запросов, а может - на втором. Есть, как говорится, два путЯ - 1) найти ошибку и исправить (маловероятно без помощи ЭЛАР) 2) пойти по пути наименьшего сопротивления и перенести сайт на порт 80, на на 8082 поставить безусловное перенаправление на порт 80. Если у вас нет админов, способных на сей подвиг - можете привлечь да хоть меня, денег брать не буду. (надеюсь у вас перед IIS стоит nginx, тогда будет тривиально. Если нет - печалька, IIS я не умею, но быстро разберусь).

Кстати, ГАВО, если бы разрешили докачивать картинки - было бы супер. Сейчас это не сильно актуально, но вот до НГ это бы ооочень сильно помогло и вам и нам - файл, скачавшийся на 89% начинает качаться заново...

>> Ответ на сообщение пользователя DikiyObraz от 12 февраля 2021 21:39

а ну вот, специалисты начинают выходить из тени.

DikiyObraz написал:

[q]
отдает картинку с такой скоростью с какой может, но без сбоев
[/q]

вот я Вам описал, как я увидел, а увидел я ровно следующее, что повторные загрузки проходят знааачительно лучше чем первая

DikiyObraz написал:

[q]
Файлы в базах никто не хранит, только метаданные.
[/q]

хранят-хранят, не в архивах может быть

DikiyObraz написал:

[q]
для этого параметры x,y и нужны
[/q]

- соглашусь, логично, не знаю

DikiyObraz написал:

[q]
это "потерю" порта 8082
[/q]

- а что Вы имеете в виду? что значит потеря порта?

DikiyObraz написал:

[q]
если бы разрешили докачивать картинки
[/q]

- там, насколько я помню и понимаю, в любом случае надо будет передать в запросе с какого байта продолжать и собрать части на клиенте. Это получается, клиент должен сообщить эту цифру. Браузер так делает сейчас, не знаю? В работе с изображениями, ну по крайней мере в IIS я такого не припомню. докачка binary по HTTP была вроде

yab написал:

[q]

вот я Вам описал, как я увидел, а увидел я ровно следующее, что повторные загрузки проходят знааачительно лучше чем первая
[/q]

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

yab написал:

[q]
- а что Вы имеете в виду? что значит потеря порта?
[/q]

Очередной переход происходит по адресу http://gavo.arsvo.ru/Pages/... а не http://gavo.arsvo.ru:8082/Pages/..., я же писал

yab написал:

[q]
Браузер так делает сейчас, не знаю?
[/q]

Они МОГУТ передавать byte-range, не уверен что делают. Но это точно делал бы я, например. Я вернулся к делам архивным ближе к зиме и скачал пару десятков дел - а трафику потратил, наверное, на пару сотен. Была бы возможна докачка - этого бы не произошло.

Фонды он-лайн