Кэш временных листов для Mapserver

Я искал в Google и StackOverflow, чтобы узнать, есть ли у кого-нибудь решение моей проблемы, но не нашел никого с такими же проблемами.

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

Он полностью динамический, я имею в виду, что пользователь может включить / отключить любой из слоев или щелкнуть внутри многоугольника (выбрать несколько точек на карте), он раскрасит выделение (сгенерировать новый файл карты на основе выбора и повторно сгенерировать плитки).

Таким образом, выполнение всего этого кода от выбора некоторой области до окраски выбранных элементов иногда занимает слишком много времени для хорошего взаимодействия с пользователем.

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

P.S. Я уже сделал все оптимизации из документации Mapserver.

Спасибо за любую помощь.


person user2473933    schedule 19.06.2015    source источник
comment
Пожалуйста, опубликуйте свой файл карты. Какую базу данных вы используете? Это медленный поиск в базе данных, рендеринг или и то, и другое? Как вы это измерили?   -  person Hal Mueller    schedule 06.07.2015
comment
Привет, самый простой пример карты, который я использую, содержит DOF и два слоя из базы данных PG, а файл карты выглядит так: pastebin.com/ 0qb87Wgs.   -  person user2473933    schedule 08.07.2015
comment
Я думаю, что наиболее трудоемкими задачами являются обработка файла DOF и перепроецирование данных, потому что все данные, которые я использую, сохраняются в нашей локальной проекции Гаусса-Крюгера, но затем воспроизводятся в проекции Google 3857, в которой карта отображается пользователю. Я измерил генерацию файла карты с параметром DEBUG в файле карты, установленным на 5, и поиск процессов в Linux. Я не знаю, как проверить производительность всего процесса от создания файла карты до отображения плиток на экране.   -  person user2473933    schedule 08.07.2015


Ответы (1)


Мне кажется, что кеширование на стороне сервера не поможет решить вашу проблему. Если все плитки зависят от выбора пользователя, вы будете генерировать кучу новых плиток каждый раз, когда происходит взаимодействие.

Я использую MapCache для решения аналогичной проблемы, когда в ответ визуализирую набор фрагментов. на запрос пользователя. Но я разбил свои плитки на несколько логических слоев, и я делаю композицию на стороне браузера. Это позволяет мне кэшировать на стороне сервера плитки для различных запросов и значительно повысить производительность. Я засеял кеш до уровня масштабирования 12, и мне нужно было использовать тип кеша BerkeleyDB, чтобы не закончились inode.

Я использую Leaflet.js для рендеринга на стороне браузера, но вам также следует рассмотреть возможность использования OpenLayers.


Посмотрев исходный код, у меня появились другие идеи.

Похоже, вы каждый раз рисуете каждый слой одинаково. Это правильно? То есть стиль и предикат конкретного слоя никогда не меняются. Каждый пользователь видит изображение для этого слоя одинаково, если они выбрали этот слой. Но меняется ли комбинация слоев, которые вы показываете, в зависимости от элемента управления OpenLayers? В этом случае вам не нужно кэширование для каждого пользователя на сервере. Вместо этого используйте кэширование по уровням и позвольте браузеру пользователя определять кэширование на стороне клиента.

Быстрый способ найти медленные слои - отключить их все. Затем включите их по очереди, чтобы найти виновника. Вызовите Mapserver из командной строки и рассчитайте время выполнения для большей точности, чем вы получите, запустив его с веб-сервера.

Вы упомянули, что передаете изображения в Google 3857, а слои - в Gauss-Kruger / EPSG 3912. Перепроецирование этого на лету стоит дорого. Перепроецирование растров на лету очень дорого. Если вы можете, вы должны перепроецировать их заранее и сохранить в 3857 (добавить дополнительный столбец геометрии).

Я не знаю, что такое файл DOF - может быть, файл цифровых препятствий? Возможно, предварительно загрузите файл DOF и в PostGIS? Это устранило бы две части, которые, по вашему мнению, являются проблематичными.

Взгляните на SQL-запросы, которые выполняет PostGIS, и убедитесь, что они используют индексы.

В любом случае, на мой взгляд, эти отдельные слои должны быть помещены в MapCache. Вот видео с сентябрьского выступления 2014 года проекта MapCache лидер.

person Hal Mueller    schedule 20.06.2015
comment
Спасибо за ваш ответ. В отличие от вашего случая, почти все слои являются динамическими, но растровые слои статичны, поэтому может быть некоторое пространство для предварительного кэширования. О нескольких слоях - сколько слоев мне нужно, чтобы не столкнуться с проблемами производительности из-за большого количества изображений, используемых в процессе отображения карты в браузере? - person user2473933; 06.07.2015
comment
Предположение, что стили не меняются, неверно, потому что стили слоя меняются, когда пользователь нажимает на графику (т.е. когда пользователь использует инструмент выбора и щелкает внутри многоугольника, новое выражение добавляется в файл карты для раскраски выбранного многоугольника). Я добавлю дополнительный столбец геометрии с той же проекцией, что и внутри OpenLayers, чтобы увидеть эффект, и я проверю видео, чтобы увидеть, может ли MapCache быть полезным для меня - в настоящее время я считаю его полезным для уже упомянутых слоев DOF (Digital Ortophoto). По поводу отладки - я думаю, что мне нужно измерить весь процесс от щелчков пользователя до рендеринга. - person user2473933; 09.07.2015
comment
Отладка / профилирование: конец веб-сервера добавляет изменчивость (загрузка сервера, задержка), которая не имеет отношения к вашей проблеме запроса / рендеринга. Вот почему я предлагаю не учитывать это. Это просто шум. Динамический файл карты: поможет, если вы покажете нам больше кода. Какие именно изменения вносятся в файл карты / карты при изменении вводимых пользователем данных? Измерение: какие слои медленные? - person Hal Mueller; 09.07.2015
comment
Хорошо, чтобы быть более понятным о создании файла карты - определения слоев сохраняются в базе данных MySQL. Когда пользователь хочет раскрасить многоугольник внутри одного слоя картографического сервера, PHP-код получает соответствующий gid (на основе щелчка) и использует его внутри выражения для определения стиля слоя для файла карты. Затем на основе видимых слоев и заголовка PHP-код генерирует полный файл карты из определений слоев в MySQL db. Для раскрашивания отдельного элемента внутри слоя добавлен этот код: pastebin.com/ZGAp5r7c Согласно моим тестам с DEBUG Mapserver функции, самые медленные слои - растровые (Ортофото). - person user2473933; 09.07.2015
comment
Похоже, вы это сделали. Кэшируйте ортофотопланы с помощью MapCache. Или для быстрой проверки отключите слой ортофотопланов и решите, приемлемо ли качество изображения. - person Hal Mueller; 09.07.2015