Быстродействие в веб-приложениях

[amnesiac]

Добрый день!

Прошу совета у тех, кто встречался с конструированием веб-приложений во вьюерах. Сделала приложение с помощью Viewer for Flex, пока было мало слоев, все работало нормально, когда добавила туда больше сервисов, стало сильно тормозить. Кэширование помогает слабо.
Подскажите, пожалуйста, что влияет на быстродействие приложений на flex? и как его увеличить?
Имеет ли значение, где находится БД (у меня - на сетевом диске), из которой сервисы берут данные, а также тип БД (у меня обычная файловая, и вроде бы на ней должно работать быстрее, чем на ArcSDE)?

[Vaska72]

Больше всего на быстродействие влияет оформление и кол-во объектов. Чем сложнее условное обозначение, чем больше объектов на карте отображается одновременно, чем больше надписей, тем меньше быстродействие. Нужно попробовать оптимизировать карту: задать масштабы отображения для слоев и для подписей, по возможности упростить условные обозначения.
Есть хороший инструмент Mxdperfstat. С его помощью можно посмотреть какие слои и почему долго отрисовываются в ArcMap. Они же будут медленно работать и в веб-сервисах.

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

[Andrey Zhukov]

А сколько слоев в приложении используются?

[amnesiac]

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

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

А сколько слоев в приложении используются?

9 составных слоев, в которых от 1 до 6 дочерних. Но тормозить начало только сегодня, когда я добавила очередной составной слой (на рисунке)

[jerry-maori]

Для начала посмотреть по монитору ресурсов, кто крыса... в смысле есть ли прям явный затык (типа кол-ва операций чтения-записи на винт, скачкообразный рост потребления оперативы в какой то момент)...
Если, например, БД лежит на RAID5, то могут быть затыки при большом кол-ве запросов (5-ка не любит на себе БД).

[amnesiac]

Для начала посмотреть по монитору ресурсов, кто крыса... в смысле есть ли прям явный затык (типа кол-ва операций чтения-записи на винт, скачкообразный рост потребления оперативы в какой то момент)...
Если, например, БД лежит на RAID5, то могут быть затыки при большом кол-ве запросов (5-ка не любит на себе БД).

спасибо, посмотрю!
а стоит попробовать низкую изоляцию процессов для сервисов или не может быть в этом дело? я думала, что у нас довольно мощный сервер, и поставила высокую

[jerry-maori]

Окай, каков конфиг сервера:
1. Процессор
2. Оператиная память
3. Как организована дисковая подсистема
4. Что ещё крутится на нём, кроме ArcGIS Server

[Vaska72]

Но тормозить начало только сегодня, когда я добавила очередной составной слой (на рисунке)

Значит надо попробовать убрать все остальные сервисы из приложения и посмотреть будет тормозить или нет. Тогда будет понятно дело в этом сервисе или в чем-то другом.

Масштабируется карта только в тех масштабах, которые заданы кэшированной подложке. Или сервисам все равно надо прописывать те же фиксированные масштабы?

Я имел ввиду попробовать по возможности ограничить масштабы для некоторых слоев и подписей. Например, показывать реки начиная с масштаба 1:1 000 000, а подписи рек с 1:500 000. Так и количество объектов на карте уменьшится, и читаемость карты повысится.

Еще к предыдущему вдогонку. Если сервис и данные в разных системах координат, то это снижает быстродействие, иногда сильно. Сложность геометрии объектов (кол-во точек в линии или полигоне) тоже может заметно замедлять работу. Если используется выборка, то можно проверить насколько оптимально запрос написан.

[amnesiac]

Окай, каков конфиг сервера:
1. Процессор
2. Оператиная память
3. Как организована дисковая подсистема
4. Что ещё крутится на нём, кроме ArcGIS Server

1. Intel Xeon x5690, 2 штуки
2. 192 Гб
3. 8 жестких дисков в RAID5 (выше вы писали, что дело в том, что БД на RAID5 не оч хорошо, может в этом дело?)
4. Кроме ArcGIS Server на нем установлены программы, выполняющие объемные процедурные и графические вычисления, но сейчас, когда проверяли приложение, ничего задействовано из этого не было - все равно тормозит

Системный монитор скачков памяти никаких не выдает

[jerry-maori]

ну железки толстые, не должно тупить...
А можно запустить ваше приложение и параллельно запустить монитор ресурсов... И начать приложение дёргать до того момента, как оно тормозить начинает... И посмотреть, что с ресурсопотреблением в этот момент случается?
В частности -- нагрузка на проц, скорость чтения/записи в винта ну и скорость сетевого обмена...

[SergeyRyzhkov]

1. БД на сетевом диске, не там где арк-сервер ? Это не хорошо...
2. Файловая БД не факт что быстрее, чем работать с БД. Может как раз в этом (в совокупности с п 1) и причина, gbd по размеру большая получилась ?
ArcSDE (я же Вам объяснял - это просто прослойка, она тут вообще не причем)

А так jerry-maori, Вам правильно посоветовал. Только таким путем можно выявить ...

ЗЫ: Все-таки на умершем флексе остались ?

[amnesiac]

А можно запустить ваше приложение и параллельно запустить монитор ресурсов...

Спасибо за совет, попробую! Пока знаю тока, что память на него никак не реагирует

Значит надо попробовать убрать все остальные сервисы из приложения и посмотреть будет тормозить или нет. Тогда будет понятно дело в этом сервисе или в чем-то другом.

убрала все остальное, проблема в этом сервисе, но не пойму, в чем она заключается - может в количестве объектов в одном из слоев - там есть на 47 с лишним тыс. объектов, тогда как остальные - на 2-5-7 тыс.

Из предупреждений - только пути UNC и прозрачность некоторых слоев (но ее хотелось бы сохранить для функциональности). С координатами и выборками все ок. А вот насчет отображения - не могу придумать, что еще можно оптимизировать...подписи все в топооснову зашиты, масштаб - 1:250 000 и крупнее, объекты имеют разные атрибуты, но классифицировать их как-то сложно, если тока искусственную классификацию вводить по площади, например...но хотелось бы не тратить на это время, если можно как-то обойти проблему быстродействия
Можно ли вообще избежать создания составного из большого слоя при таком количестве объектов или не получится?

1. БД на сетевом диске, не там где арк-сервер ? Это не хорошо...
2. Файловая БД не факт что быстрее, чем работать с БД. Может как раз в этом (в совокупности с п 1) и причина, gbd по размеру большая получилась ?
ArcSDE (я же Вам объяснял - это просто прослойка, она тут вообще не причем)

А так jerry-maori, Вам правильно посоветовал. Только таким путем можно выявить ...

ЗЫ: Все-таки на умершем флексе остались ?

1. БД не там же, да. То есть на этом же сервере, но на другом жестком диске RAID массива. Если это может быть причиной, будем переделывать конфигурацию. А как в идеале должно быть?
2. Насчет этого не буду спорить, потому что не очень помню, но мне кажется, где-то в документации аркгисовской читала, что с БГД вроде как быстрее будет, и лучше ее, если не требуется функционал СУБД. По размеру она составляет 666 Мб (я серьезно). Может причина в основном в этом?

На флексе - решение временное, конечно. Решила поступить, как Вы советовали - отдать промежуточную версию на обратную связь пользователю, а в это время прокачать матчасть по leaflet. Но времени катастрофически не хватает

[SergeyRyzhkov]

amnesiac
Вы правильно начали поступать.

1. Локализовать проблемный сервис. У меня такое было, когда слой ЗОРИ подключал, ну очень тормозит он. Плюс его еще и классифицировали.
Хотя тот же слой adres (130 тыщ) или parcel (120 тыщ) намного больше по размеру, но не оказывают влияние на быстродействие.
Я делал (давным давно) генерализацию данного слоя (естественно при вычислениях использовал копию) - немного стало легче.

2. Вы уверены что тормоза именно на сервере? Вы попробуйте в аркмапе тоже тормоза (если поиграться с включением\выключением сервисов) ? Порой же бывает что клиент не может переварить рендеринг (тем более флекс).

3. Насчет файловой и СУБД. Тут очень все относительно. У Вас же винда, а ей трудно порой работать с файлами ,
Положите гбд рядом с серваком, без всяких путей, других дисков и т.д. Посмотрите.

[Andrey Zhukov]

Рендер сервиса с файловой базы геоданных всегда быстрее.

[SergeyRyzhkov]

Рендер сервиса с файловой базы геоданных всегда быстрее.

Не согласен со столь категоричным заявлением.
Много лет назад один всего слой, состоящий из 800 тыщ объектов, пришлось "затащить" в Oracle нормализовать, построить материализованную вьюху, построить индексы и т.д., так как в ФГБД ну очень тормозила, а БД спасла в какой-то мере. Возможно в тот момент что-то не так делал, конечно.

Но спорить не буду, нет уже возможности (и желания) провести эксперимент и аргументировать свое заявление