Optimización de un servidor de mapas en Internet

Transcripción

1 Optimización de un servidor de mapas en Internet Geograma S.L Artículo del boletín GeogramaInforma de Noviembre de 2004

2 Optimización de un servidor de mapas en internet... 3 Para optimizar hay que medir... 4 Seguridad... 5 Depuración... 5 Registro... 6 Hardware... 6 Tarjeta gráfica...6 RAM...7 Procesador...8 Programación... 9 Salvapantallas... 9 Ancho de banda Datos Formato de datos...11 Formato de salida...11 Generalizar...13 Visualización por zoom...13 Índices espaciales...14 Proyección...15 Software GIS Escenario real (concurrencia) Y si no mejora Geograma S.L página 2

3 Optimización de un servidor de mapas en internet Este artículo pretende describir las técnicas que se podrían aplicar en el caso de que necesitemos optimizar un servidor geográfico en internet. Un servidor, y especialmente un servidor de mapas, es un sistema complejo que requiere un equipo experimentado multidisciplinar para una correcta implementación. El paso de desarrollo a producción en este tipo de sistemas suele provocar la aparición de una serie de problemas referidos al rendimiento. Estos problemas, algunos previsibles y otros no tanto, pueden llegar a ser tan importantes que hacen plantearse la reprogramación de algunos módulos o la modificación de las funcionalidades previstas inicialmente. El documento menciona una serie de puntos, que aunque algunas veces resultan obvios, no por ello se suelen tener en cuenta todas las ocasiones. Además, cada implantación es diferente, y un mismo punto puede tener efectos distintos en cada una de ellas. Cada uno de los aspectos tratados constituye un punto de partida sobre el cual se abren infinitas posibilidades dependiendo de cada caso. Este documento es un compendio de las diversas experiencias que los consultores, desarrolladores y analistas de Geograma ( han tenido en la implementación de este tipo de sistemas. Aunque depende de la limpieza y metodología con la Ud. haya desarrollado el sistema, es muy probable que en este artículo no encuentre soluciones radicales. Hay matices que pueden afectar más o menos al rendimiento, pero lo cierto es que no hay puntos que tengan una importancia capital. Más bien es una suma de factores, que hace que un solo factor no tenga incidencia, pero que la suma de varios de ellos sí adquiera cierta relevancia. Geograma S.L página 3

4 Para optimizar hay que medir Medir, medir y medir. No nos podremos plantear ningún proceso de optimización, sea en el ámbito que sea, si no tenemos definidos unos indicadores que nos definan claramente qué es lo que queremos mejorar. También, aunque mucho más difícil, hay que definir unos objetivos en base a dichos indicadores. El tener una meta concreta nos puede ayudar más de lo que creemos. La ausencia de objetivos de optimización puede provocar que el coste se dispare. Tiene mucho más éxito un proceso de optimización del tipo hay que conseguir que una transacción tarde 3 segundos como máximo, que del tipo hay que optimizar las transacciones al máximo posible. Durante el proceso de desarrollo, es necesario aplicar unas metodologías que nos permitan medir tiempos, parciales y totales. No nos podemos fiar únicamente de nuestra propia percepción. Como ya comentábamos al principio, las optimizaciones son apenas perceptibles cuando se realizan de una en una. Por ello debemos disponer de mecanismos que nos recojan tiempos de proceso y de respuesta que nos puedan indicar si es más rápido un método u otro, o funciona mejor un hardware determinado u otro, a la hora de desarrollar. Las diferencias pueden ser inapreciables, normalmente inferiores a décimas de segundo, pero en un proceso recursivo una décima se puede convertir fácilmente e uno o varios segundos. No pase al siguiente punto si no tiene resuelto cómo medir y hasta dónde quiere optimizar. Se ahorrará tiempo y dinero. Geograma S.L página 4

5 Seguridad La seguridad consume recursos. Muchos recursos. Debe aplicar la seguridad necesaria a su aplicación, pero hay que valorar qué técnica es la más apropiada. Por ejemplo, el acceso a un servidor web se puede restringir por IP, pero esto tiene un coste elevado comparándolo con otras técnicas. El control de usuario y contraseña de puede aplicar de muchísimas formas diferentes. Otro ejemplo claro es el uso del protocolo seguro HTTPS. Desde luego es un protocolo seguro, pero su rendimiento es a todas luces inferior. Una aplicación lógica de este protocolo es utilizarlo por ejemplo solamente cuando se transmiten datos de especial importancia, y no en la totalidad de las transacciones. Cuando valore la política de seguridad que utilizará su aplicación, tenga en cuenta los rendimientos de cada una de las políticas, puede haber grandes diferencias. Depuración Al hilo del capítulo anterior, además de las rutinas de medición de tiempos a las que hacíamos referencias, es habitual tener habilitadas las opciones de depuración que ofrecen los diferentes entornos de programación. La depuración de aplicaciones cliente-servidor suelen ser procesadas por el propio servidor, con el coste en recursos que esto supone. Una vez desarrollada la aplicación, estas opciones no tienen sentido, y por tanto pueden ser deshabilitadas sin que el usuario note diferencia. Además, las opciones de depuración pueden suponer algún problema en temas de seguridad, por lo tanto, deshabilite todas las opciones de depuración en el lado servidor. Geograma S.L página 5

6 Registro Es común que las aplicaciones generen un registro de los procesos que realizan. La base de datos, el servidor de internet o el servidor que genera los mapas suelen tener sus propios registros. Hay ocasiones en las que dichos registros son imprescindibles, se realiza su seguimiento, se utilizan diariamente, y se explotan sus estadísticas. Es el caso de los registros de los servidores de páginas web, en el que es necesario un seguimiento exhaustivo. Pero no todos los registros son imprescindibles. Hay registros que sólo tienen una finalidad didáctica, de tutorial, otros que no son necesarios, o incluso hay veces que la misma información se registra varias veces. En un caso concreto con un servidor de mapas, la opción de registro de generación de mapas provocaba un retraso de más del 50% en cada mapa. Deshabilite las opciones de registro o log que no sean imprescindibles. Hardware Tarjeta gráfica La tarjeta gráfica del servidor puede ser decisiva en algunos casos particulares. Aunque aparentemente no exista relación, cuando el software servidor de mapas utiliza el API del sistema operativo para generar imágenes de mapas, éste a su vez aprovecha las capacidades de la tarjeta gráfica. Geograma S.L página 6

7 Por tanto, cuanto más potente sea dicha tarjeta, más rápido se generarán los mapas. Además, incluso es posible que la configuración de pantalla influya en la resolución y profundidad de colores de las imágenes de mapa. Compruebe si la tarjeta gráfica del servidor influye en la generación de los mapas. RAM Cuanta más RAM mejor es una máxima de los fabricantes de software. El problema es que el servidor de mapas se encuentra instalado en una máquina concreta, con una RAM determinada. Lo importante en este caso es gestionar la RAM adecuadamente. Es importante detectar cuándo la RAM física se acaba y se comienza a utilizar el disco de paginación o memoria virtual. Es importante que esto no ocurra, pues entonces es cuando el rendimiento desciende de manera espectacular. Puede utilizar el administrador de tareas de windows para obtener una visión rápida del uso de la RAM. Cuando ocurre, descartando la opción de instalar más RAM (la más sencilla), deberemos liberar memoria. Para liberar memoria, hay que valorar si todos los programas que tenemos instalados en el servidor de mapas son imprescindibles. Es posible, además, que el servidor de páginas web o el servidor de correo debamos alojarlo en otra máquina para liberar RAM. Otro de los grandes usuarios de la RAM es la memoria caché. La utilización de caché es buena, pero un uso indebido puede provocar que la memoria se sature, obteniendo resultados contraproducentes. Vigile la memoria, si ésta se acaba y se comienza a utilizar el fichero de paginación, valore la posibilidad de desinstalar aplicaciones Geograma S.L página 7

8 residentes y compruebe el buen uso de la memoria caché en su código. Procesador El procesador suele ser el primer comodín al que recurrimos. Cuando se intentan resolver problemas de rendimiento con velocidad de procesador, en lugar de resolverlo lo estaremos tapando. Evidentemente, cuanto más rápido, mejor; pero si el cuello de botella no es el procesador, el rendimiento mejorará poco y además el problema seguirá existiendo. Compruebe la utilización de procesador. El tiempo de uso del procesador se puede reducir aumentando la velocidad u optimizando el código. Cada avance optimizando recursos será equivalente a comprar un procesador más rápido. Respecto a la utilización de varios procesadores, éstos no aumentan la velocidad de proceso. Es más rápido un procesador de Mhz que dos de Mhz. Una configuración multiprocesador está dirigida a mejorar la respuesta ante varios usuarios, pero no a aumentar la velocidad. Vigile la utilización de los procesadores, porque se dan casos en los que la utilización del segundo procesador es nula, con lo que será un gasto inútil. Consulte la documentación de su aplicación servidora de mapas para conocer su comportamiento en entornos multiprocesador. Aumente la velocidad del procesador sólo cuando haya acabado de optimizar su aplicación en el resto de frentes, y cuando detecte que éste es un cuello de botella. Geograma S.L página 8

9 Programación Sería imposible recoger todos los detalles que pueden optimizar una aplicación servidora de mapas. Depende de muchísimos factores, de las herramientas y/o entornos utilizados, etc. No es objeto de este artículo ya que no es un problema específico de los servidores geográficos. Simplemente resaltar que cada entorno tiene sus trucos, están documentados, y se deben utilizar. Algún ejemplo general puede ser la utilización de procedimientos almacenados en los sistemas gestores de bases de datos, una buena utilización de memoria caché, o la correcta utilización de los tipos de variables, y la destrucción de los objetos no necesarios. Busque y utilice la documentación sobre buenas prácticas de código y mejoras de rendimiento específicas para su entorno de programación. Salvapantallas Los salvapantallas pueden llegar a consumir recursos muy importantes. Además, al utilizar capacidades gráficas, influyen aún más en el caso particular de generación de mapas. Precisamente los salvapantallas se utilizan mucho en servidores, y suelen estar activos gran parte del tiempo. Utilice la opción que apaga la pantalla para ahorrar energía y uso del monitor, es la que menos recursos utiliza. Si quiere aprovechar todos los recursos de su ordenador, no utilice salvapantallas. Geograma S.L página 9

10 Ancho de banda El servidor geográfico debe estar conectado a Internet con un ancho de banda adecuado a la demanda de mapas que debe servir. Éste no suele ser un problema, ya que los diferentes proveedores ofrecen diferentes anchos de banda con varias posibilidades, fácilmente escalables, incluso anchos de banda ilimitados cuyo coste se cuantifica por el volumen transferido. Lo que sí es más crítico es el ancho de banda con el que se conectan los usuarios. Hasta la implantación del ADSL, la velocidad de las conexiones era uno de los cuellos de botella del sistema. Evalúe el ancho de banda que dispondrán los potenciales usuarios, y realice pruebas reales de rendimiento. Si es necesario disminuya capacidades como el tamaño o resolución de los mapas. No se trata sólo de que el servidor sea rápido, sino que además se perciba como tal. Desde luego el caso real no es acceder a los mapas desde el propio servidor. No sólo el ancho de banda influye en la velocidad de una red. La correcta utilización y configuración de tarjetas, hubs, switches, cortafuegos, etc tiene influencia directa en el rendimiento. Lo que para procesos más corrientes puede no tener influencia, cobra especial importancia en el caso de servidores de mapas. Consulte al administrador de la red el nivel de optimización de la misma. Datos Los datos son uno de los temas que más influyen en el rendimiento. Una correcta estructuración, planificación y tratamiento de los mismos es la mejor apuesta para conseguir un servidor web geográfico de calidad. Geograma S.L página 10

11 En los siguientes párrafos se irán tocando algunos de los puntos más relevantes sobre este aspecto. Formato de datos La mayoría de fabricantes de software publicitan sus productos en la línea de que pueden utilizar la mayoría de formatos GIS utilizados habitualmente. A veces incluyen la coletilla nativos o sin traducción lo que quiere indicar que trabajan directamente con los datos en tal o cual formato. La utilización de los formatos no nativos del software GIS suele traducirse en un rendimiento muy pobre. Un formato determinado está optimizado normalmente para el software que lo creó. Además de las pérdidas de información en la traducción que se suelen dar, no todos los formatos son de lectura/escritura. En definitiva, sólo con los datos nativos del fabricante se obtienen los mejores resultados. Valore la posibilidad de generar los datos en el formato nativo del software GIS; o realice las pruebas y comparaciones necesarias para asegurarse de que con el formato que pretende utilizar no se perjudica el rendimiento. Formato de salida El formato de salida puede causar que la información que se envía a través de la red sea excesiva. Un mapa en formato bmp puede tener un tamaño hasta 50 veces mayor que la misma imagen en formato gif, por ejemplo. Un formato jpg mal aplicado puede ser 3 ó 4 veces mayor que su equivalente en png. Cada caso tiene sus particularidades, pero en general el formato jpg es adecuado Geograma S.L página 11

12 para presentar imágenes aéreas, ortofotos, o combinación de éstas con información vectorial, y los formatos gif y png son más adecuados para los planos con un marcado carácter lineal. La profundidad del color de las imágenes también puede afectar seriamente al tamaño de los ficheros y por tanto al rendimiento. Hay que valorar si la profundidad de color de las imágenes que envía son es la adecuada o está sobredimensionada. Un ejemplo extremo sería enviar imágenes en color para un dispositivo móvil que sólo representa escala de grises. Respecto a enviar información vectorial, se puede decir que aún no existen formatos relativamente estándares y utilizados para este tipo de información. Aunque a priori este tipo de formatos vectoriales para mapas por Internet son más adecuados, lo cierto es que la necesidad de plug-in propietarios hace que hoy por hoy sea más adecuada, abierta e interoperable la difusión de mapas en formatos de imagen que las soluciones basadas en vectores. Además, los formatos que parece que se van consolidando son los formatos vectoriales basados en XML, que no deja de ser un formato de texto, mucho menos óptimo que el formato binario. Desde luego las técnicas de compresión/descompresión están avanzando, y es muy probable que no en mucho tiempo estos formatos puedan ser una buena opción. Elija el formato más óptimo para su caso concreto. Es posible que deba utilizar varios formatos en función de cada necesidad. Configure adecuadamente la profundidad del color en imágenes raster. Valore si el formato raster es más o menos óptimo que el formato vectorial para la funcionalidad que necesita. Geograma S.L página 12

13 Generalizar Cuando se generan mapas para Internet, la escala de visualización puede ser muy variada. Si utiliza información de escalas grandes para generar mapas de escala pequeña, estará derrochando recursos. Generalice la cartografía para que se adecue a la escala de visualización que va a utilizar. Si es necesario, genere varias colecciones de cartografía para utilizar cada una según la necesidad. Es posible en para ciertos casos sea más engorroso, pero la diferencia de rendimiento puede ser decisiva. Además, a nivel visual, el resultado puede ser mucho mejor cuando se genera una cartografía ex profeso para una escala determinada. Es lógico que no sea lo más adecuado, ni en recursos ni en simbolización, presentar unos elementos de 1/500 tal cual cuando la estamos visualizando a escalas 1/ o 1/ Existen multitud de ejemplos en Internet con mapas ilegibles y lentos en su inicio, que no se vuelven legibles y ágiles hasta acercarse lo suficiente. Visualización por zoom Además de que la información que utilice y presente el servidor de mapas debe ser adecuada a su escala como se ha explicado en el punto anterior, los niveles de información que se presenten en un mapa deben ser los adecuados. Si no existe un nivel de detalle suficiente, la presentación de ciertos niveles de información en un mapa es irrelevante y el coste en recursos innecesario. Por ejemplo, las curvas de nivel con equidistancia 1 metro pueden no ser necesarias para escalas inferiores a 1/ El presentar dichas curvas, generalizadas o no, supone un alto consumo de recursos del que el usuario no se aprovecha. Geograma S.L página 13

14 Genere rangos de escalas y presente la información que verdaderamente sea útil a cada uno de los rangos. El usuario suele preferir un mapa algo más vacío, si con ello aumenta el rendimiento del servidor. Índices espaciales El tamaño de los datos a los que accede el servidor suele ser un aspecto directamente proporcional a la velocidad de acceso a los mismos. Evidentemente no tiene la misma velocidad de acceso un nivel de información con todos los árboles (por poner un ejemplo) de una provincia, que un nivel con los árboles de una población. Normalmente la diferencia no suele ser relevante, pero en algunos casos extremos podría llegar a serlo. Otras veces sencillamente resulta engorroso manejar una base de datos con millones de registros, y es más práctico, rápido y organizado segmentar las bases de datos por algún criterio. Cuando este criterio es espacial (hojas, cuadrícula, zonas), se necesitan los índices espaciales para acceder a la parte de información que nos interesa. Aunque parezca extraño, no es habitual que las herramientas de software posean este tipo de índice. Ello no impide que nuestra aplicación los contemple, y hay casos en los que es más que recomendable. Algo similar, que sí suele estar contemplado en las herramientas de software servidor de mapas, son los mosaicos de imágenes. En el caso particular del formato ráster, una colección de imágenes georeferenciadas se indexan de tal manera que el sistema accede a las imágenes necesarias en función del área geográfica seleccionada. De esta forma, no es necesario tener una Geograma S.L página 14

15 macroimagen, difícil de administrar y mantener, sino que se pueden tener varias imágenes e incluso pueden llegar a solaparse entre ellas. Este concepto de mosaico es el que, aplicado a formatos vectoriales, es lo que llamamos índice espacial. En el caso de grandes volúmenes de datos, considere que su aplicación utilice índices espaciales que accedan a diversos datos en función del área geográfica requerida. Proyección Habitualmente los datos geográficos utilizan algún tipo de proyección. El paso de una proyección a otra, o el paso de coordenadas sin proyectar a una determinada proyección consiste en una serie de complicadas operaciones con un alto componente de cálculo. La diferencia entre proyectar un mapa on the fly o tenerlo ya proyectado puede suponer diferencias de más del 100% en el rendimiento. Si es posible, almacene los datos en la proyección que va a utilizar Software GIS No todas las herramientas servidoras de mapas son igual de rápidas. Hay muchas, muy variadas, algunas muy potentes y no tan potentes. Por ejemplo, hay herramientas que permiten análisis GIS avanzado y otras que únicamente permiten visualizar geoinformación. Ud. deberá evaluar qué es lo que necesita y probar las diferentes opciones. Es lógico pensar que si una herramienta GIS permite realizar mapas temáticos dinámicos, sea más lenta en generar los mapas que una que utiliza Geograma S.L página 15

16 unos mapas con una simbología fija. Por ello, si ud. está utilizando un software que permite gran número de opciones pero no las está utilizando es posible que esté sacrificando rendimiento y recursos a cambio de nada. Por no hablar de la dificultad que suelen entrañar estos sistemas tan potentes. Seguramente cuando decida implantar funcionalidad nueva ya haya otra versión del software, más rápida, más barata y más fácil. Más aún, cuando no haya acabado de implantar su aplicación con la funcionalidad inicial, ya existirán nuevas versiones. Para asegurarse de que no derrocha recursos, utilice el software que se adapta a la funcionalidad que necesita hoy, mañana ya habrá una nueva herramienta para evaluar. Y una vez decidida la funcionalidad, compare entre diversas herramientas para medir tiempos y rendimientos objetivamente. Exija a los comerciales que le demuestren rendimientos, compare, y decida en consecuencia. Escenario real (concurrencia) El rendimiento de un servidor puede sufrir drásticas consecuencias en el caso de coincidan varias peticiones simultáneas. En operaciones complejas en la que el uso del procesador es intensivo, como se da en los servidores geográficos, este problema se puede agravar aún más. El rendimiento en los casos de concurrencia puede no ser proporcional, como cabría pensar en un primer momento. Se han comprobado casos en los que, si una imagen de mapa tarda en generarse 3 segundos de media, cuando las peticiones son simultáneas este tiempo se multiplica por 3 ó 4, incluso puede hacer que se llegue a colapsar. Geograma S.L página 16

17 El proceso de desarrollo debe contemplar escenarios de concurrencia, para comprobar previamente el comportamiento de la aplicación ante peticiones simultáneas. Utilice las herramientas comerciales que posibilitan estas peticiones concurrentes, o pida a sus amigos y familiares que accedan a su aplicación todos a una hora establecida, pero no lance su aplicación a Internet sin tener en cuenta este aspecto. En algunos casos con pocos recursos, o en el caso de procesos de gran duración, se puede hacer necesario el uso de colas de procesos, o invocación asíncrona que impidan el colapso del servidor. Y si no mejora Los procesos con análisis geográficos pueden llegar a ser muy complejos. Si no consigue reducir el tiempo de proceso es posible que ya esté en el límite. Aunque la tecnología avanza muy rápido, los ordenadores tienen un límite en su capacidad de cálculo. Si un ordenador puede realizar 1 millón de operaciones por segundo, y ud. necesita calcular 1 millón de operaciones, lo más seguro es que tarde un segundo. Es posible que su cliente, jefe o Ud. mismo se hayan planteado un límite imposible. De ahí la importancia de uno de los primeros puntos tratados en este documento, la fijación de objetivos. La percepción del rendimiento es tan importante como el propio rendimiento. Un indicador animado de que el servidor está trabajando, por ejemplo, puede hacer que 10 segundos se conviertan en 3. Sólo la frase Generando mapa consigue algo similar. Utilice la experiencia de los usuarios para optimizar su sistema, con encuestas y preguntas directas. No se olvide del fondo, el usuario accede al sistema para conseguir información o resolver un Geograma S.L página 17

18 problema. Si un usuario dice Valió la pena esperar también estaremos ante un servidor geográfico optimizado. La optimización de un servidor de mapas es casi un arte, en la que el artista debe conocer sobre redes, sistemas operativos, mapas, bases de datos, programación, usuarios, diseño, hardware o marketing. Una cantidad de conocimientos imposibles de concentrar en una sola persona. El artista es un equipo multidisciplinar, bien compenetrado, formado y motivado. La experiencia más importante que Ud. puede sacar de este documento es la más sencilla: Para optimizar hay que medir, medir y medir. No se dará cuenta de la importancia de las mediciones hasta que no las comience a aplicar. Ya me dirán ;-). Geograma S.L página 18