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

Tverdi написал:

[q]

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

[/q]

Также призываю к сдержанности. Не нужно "кусаться". Любое мнение/предложение специалистов в данной области будет полезно. Если программисты АИС это читают (а видимо это так), то возможно дискуссия по существу поможет им решить проблему хоть в какой-то степени. Как говорится, одна голова хорошо, а две лучше.

посмотрел, вот скриншот приложу даже, что сделал это на самом деле:
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 это водяные знаки скорее всего - да/нет.
Результат он выдаст браузеру пользователя и поместит его в серверный кэш, если такие настройки есть, а они есть. Вот то что он выдал, доходит до браузера и попадает уже в на ваш экран где вы должны его видеть (почему не видно, второй вопрос), и кэш браузера в где вы его потом находите.

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

AleksandrVL написал:

[q]

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

[/q]

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

yab написал:

[q]

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

[/q]

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

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

[q]

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

[/q]

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