Медленная производительность от MapServer

Question

Я использую maperver для создания карты, которая будет отображаться с помощью google map api. Я сталкиваюсь с проблемами выступлений.

Мои карты все в формате шейп-файла.

Выполняю тесты, чтобы получить время для отображения карт.

При визуализации карты с помощью инструмента shp2img, с помощью командной строки

shp2img -i gif -m C:\myfolder\mymapfile.map -o C:\myfolder\test.gif -all_debug 5 -map_debug 5 

я получаю следующие показатели из лог-файлов:

[Thu Apr 30 13:50:19 2009].148000 msLoadMap(): 0.000s 
[Thu Apr 30 13:50:19 2009].180000 msDrawMap(): Layer 0 (PWorld2), 0.032s 
[Thu Apr 30 13:50:19 2009].180000 msDrawMap(): Drawing Label Cache, 0.000s 
[Thu Apr 30 13:50:19 2009].180000 msDrawMap() total time: 0.032s 
[Thu Apr 30 13:50:19 2009].195000 msSaveImage() total time: 0.015s 
[Thu Apr 30 13:50:19 2009].195000 msFreeMap(): freeing map at 01595E18. 
[Thu Apr 30 13:50:19 2009].195000 freeLayer(): freeing layer at 0159CD00. 
[Thu Apr 30 13:50:19 2009].195000 shp2img total time: 0.047s 

При рендеринге ту же карту через MapServer, используя

http://localhost/cgi-bin/mapserv.exe?mymapfile.map&layers=&mode=tile&tilemode=gmap&tile=1+1+2 

Файл журнала дает следующее:

[Thu Apr 30 13:51:50 2009].664000 CGI Request 1 on process 3520 
[Thu Apr 30 13:51:50 2009].664000 msTileSetExtent (-10013744.792915, 8348.961808) (-5009.377085, 10010405.208192) 
[Thu Apr 30 13:51:51 2009].23000 msDrawMap(): Layer 0 (PWorld2), 0.359s 
[Thu Apr 30 13:51:51 2009].23000 msDrawMap(): Drawing Label Cache, 0.000s 
[Thu Apr 30 13:51:51 2009].23000 msDrawMap() total time: 0.359s 
[Thu Apr 30 13:51:51 2009].23000 msSaveImage() total time: 0.000s 
[Thu Apr 30 13:51:51 2009].23000 mapserv request processing time (loadmap not incl.): 0.359s 
[Thu Apr 30 13:51:51 2009].23000 msFreeMap(): freeing map at 01598690. 

Для этой же карты инструмент shp2img отображает карту в 10 раз быстрее, чем карты сервера. При добавлении большего количества слоев и использовании режима тайлирования для карты google может составлять до 10 секунд.

Неужели кто-то знает, почему maperver делает это медленным? Есть ли обходной путь?

Answer 1

Есть несколько различий между shp2img и запросом mapserv:

1) shp2img создает единый образ, ваш запрос mapserv генерирует плитку. Это означает, что он может отображать 9 фрагментов для ограничивающего блока samen вместо 1. Это создает накладные расходы. Попробуйте выполнить рендеринг без опции плитки и повторите тест.

2) У вас есть небольшая накладная плата для запроса cgi в mapserv 3) Mapserv нажимает изображение поверх http, а shp2img записывает непосредственно на диск. 4) Вы не указали слой в запросе maperv, что означает, что maperv ищет слои.

Answer 2

У меня есть несколько предложений, но нет твердых ответов, я не сделал много конфигураций maperver, но я работал с людьми, которые имеют.

1. Существует много оптимизаций, которые вы можете сделать для Mapserver, я бы проверил список рассылки.
2. Сделайте файл карты как можно меньше, так как открытие и синтаксический анализ файла карты может занять много времени для сервера карт.
3. Создайте все плитки загодя и просто используйте mapserver, чтобы получить файлы. Плитка на лету не очень быстро.

Answer 3

Вы можете прочитать: http://mapserver.org/optimization/index.html

• Одним из наиболее важным моментом является то, чтобы удалить неиспользуемые проекции в файле EPSG. Например. под RedHat 6/usr/share/proj/epsg У меня есть 3 проекции.
• Удалить неиспользуемые шрифты
• файле проекта анализатор читает файл сверху вниз, поэтому поместить наиболее часто используемые слои в верхней части файла (EPSG анализатор работает таким же образом)

Конфигураци файлы "должны иметь" ту же самую проекцию вызывающего абонента, в противном случае Mapserver должен перепрограммировать их на лету.

E.G. Из моего OpenLayers кода (900913):

var options = { 
    projection: new OpenLayers.Projection('EPSG:900913'), //aka EPSG:3785 
    displayProjection: new OpenLayers.Projection('EPSG:4326'), //geographic 

Все мои файлы формы являются 900913 проекция на основе.