¿Está manteniendo Copias Locales de sus documentos?

En el Grupo de Soporte Técnico de ProjectWise se reciben muchas consultas  acerca de la lentitud de los archivos al abrirlos desde ProjectWise. Los que consultan creen que no debería ser tan lento ya que está prendida la opción “leave local copy on check in” en los ajustes del usuario.

Al mirar los ajustes del usuario se observa que efectivamente este ajuste está perdido, pero hay otros ajustes necesarios para que esta opción funcione correctamente. Por lo tanto no hay mejora en la performance.

Los ajustes mencionados están en el tab Settings del cuadro de diálogos User Properties. Se debe expandir la sección Document y buscar los siguientes ajustes:

• Leave local copy on check in
• Leave local copy on free
• Use up to date copy on check out
• Use up to date copy on copy out

Esto ajustes se utilizan para que los archivos persistan en las carpetas de trabajo y permitir utilizar estos archivos persistentes  en el computador cliente. Si se prende la opción “Leave local copy on check in”, cuando se hace check in de un archivo, no se borrará la copia local. Pero si no se prende la opción “Use up to date copy on check out” el archivo se copiará al computador local de todas maneras.

Se debe recordar que sólo los a archivos maestros se les hace check out, a los archivos de referencia se les hace copy out. Por lo tanto, si no se prende la opción “Leave local copy on free”, dichos archivos se borrarán. Aquí también se debe prender la opción “Use up to date copy on copy out”.

Estos ajustes tienen bajo impacto si se está trabajando en una red rápida o se abre un archivo sólo una vez. Sobre una red lenta, prender estos cuatro ajustes tendrán un impacto notable en el tiempo que se tarda en abrir un archivo por segunda vez.

Para ver el original de este artículo: http://communities.bentley.com/products/projectwise/content_management/b/weblog/archive/2011/08/18/are-you-keeping-your-copy-outs.aspx

Mantenimiento de la Base de Datos para ProjectWise

Muchas preguntas surgen respecto a qué clase de mantenimiento se le debe realizar a la base de datos de ProjectWise, o qué cosas tener en cuenta en los sistemas de base de datos. A continuación hay algunas áreas que se deben tener en cuenta:

Memoria:

• Asegurarse que la base de datos esté utilizanso la mayor cantidad de memoria posible. Algunas veces se ajusta la base de datos con 16 Gb de RAM, pero sólo utilizan 2 Gb de esa RAM para la base de datos. Asegurarse que el dba asigne la mayor cantidad posible de memoria a la base de datos.

Disco:

• La optimización de disco puede incrementar mucho la performance de SQL Server cuando se administra correctamente. Remover lo archivos de backup viejos a un file server o disco en red compartido puede incrementar el espacio en disco disponible para la transacción de logs, archivos de base de datos e índices.

Backup:

• Backup regulares de los logs de transacciones ayudan a mantener un tamaño adecuado de dichos logs, dado que dentro de una base de datos pueden crecer rapidamente y consumir todo el espacio disponible asignado a la base de datos.
• Los procesos de backup truncan los registros de log viejos que no se necesitan para recuperación y los marca como inactivos para poder sobreescribirlos. Implementar una buena estrategia de backup que consista en backup completos de la base de datos, backups de los logs de transacción y backups de la base de datos del sistema.

Indices:

• Una tarea agendada para reconstruir los índices es fácil de configurar y puede hacer que ProjectWise continúe ejecutando correctamente. Hay usuarios que los reconstruyen una vez por semana y otros que los reconstruyen una vez por día. Dependiendo en cuanto se utilice un datasource será cuan seguido hay que reconstruirlos.
• Se recomienda reconstruirlos cuando un índice esta fragmentado en mas del 30% y reorganizarlos cuando el índice esta fragmentado entre un 10% y un 30%. Reconstruir un índice fragmentado es mas ventajoso en índices que contiene por lo menos 100 páginas, de otra manera no se verán diferencias luego de reconstruir si los índices son pequeños.

Actualizar Estadísticas:

• Se recomienda actualizar las estadísticas si los resultados muestran datos desactualizados en la columna “Updated” y/o si hay una diferencia sustancial entre “Actual Number of Rows” y “Estimated Number of Rows” en la tabla. Se pueden visualizar las propiedades de la tabla desde MicroSoft SQL Server Management Studio: “Actual Number of Rows”.
• La actualización de estadísticas puede ser una tarea automatizada, los usuarios generalmente actualizan las estadísticas y reconstruyen los índices al mismo tiempo, y es tan fácil de configurar como la reconstrucción de los índices.

Análisis de distribución de I/O para Performance:

• Analizar la I/O del sistema y decidir la mejor distribución para la carga de I/O. Realizar análisis a nivel de objeto y realizar afinación a nivel de tabla. El objetivo es reducir los cuello de botella de I/O y definir ajustes óptimos para lectura y escritura de la base de datos.

Para ver el original de este artículo: http://communities.bentley.com/products/projectwise/content_management/b/weblog/archive/2012/12/20/database-maintenance-for-projectwise.aspx

Caché o no Caché

En casi toda implementación de ProjectWise se recibe la misma pregunta sobre Caching Servers. “¿Cómo se si necesito un Caching Server en una oficina o no?”. Primero se debe entender qué hace un Caching Server y cómo se lo va a utilizar.

El ProjectWise Caching Server tiene dos propósitos. El primero es guardar los archivos administrados por ProjectWise y el segundo es hacer un caché de los archivos guardados en oficinas remotas. Un Caching Server generalmente necesitará el mismo poder de procesamiento que un file server local y no utiliza intensivamente el procesador. Sin embargo, el agregado de un Point Cloud Service puede incrementar las necesidades de procesamiento. El Point Cloud Service sólo se necesita en un ProjectWise Caching Server que tambien sera el área de almacenamiento de la nube de puntos.

Para instalaciones medianas a grandes, se recomienda que se instale un ProjectWise Caching Server en la misma ubicación que el ProjectWise Integration Server, por razones de performance. Tener ProjectWise Caching Server en una oficina remota es una de las mayores decisiones cuando se determina la arquitectura de hardware. Reglas generales para determinar si una oficina necesita un ProjectWise Caching Server incluirían lo siguiente:

• 10 o mas usuarios en una oficina utilizarán ProjectWise.
• Cinco o mas usuarios en una oficina trabajarán en el mismo proyecto y archivos.
• Oficinas que tiene alta latencia.
• Oficinas con ancho de banda limitado.
• Utilización de archivos grandes.
• Cuando se desea almacenamiento distribuído.
• Cuando se necesita mejor performance.

En muchas oficinas que están una al lado de la otra se puede comenzar sin Caching Server entendiendo que si la preformance es un problema se debe agregar uno.

Para ver el original de este artículo: http://projectwiseblog.com/2013/05/29/to-cache-or-not-to-cache/

Escalando un Sistema de ProjectWise

Dado que ProjectWise consiste de varios servidores que necesitan trabajar en conjunto, muchas veces es dificil diagnosticar los problemas de performance. Los diagnósticos de performance de ProjectWise generalmente entran dentro de cinco categorías diferentes. Es mejor asegurarse que se tiene el tamaño de sistema correcto. Condierando lo siguiente:

• CPU
• I/O de archivos
• Red
• Memoria
• Base de Datos

En general, casitodo hardware tiene un ciclo de vida de tres años alrededor del cual se puede planificar el sistema. Esto quiere decir que el hardware será suficiente para funcionar correctamente con versiones futuras del software de aplicación, como ProjectWise Integration Server, pero tambien funcionará con sistemas operativos nuevos que puedan ser desarrollados en ese período de tiempo. Ademas de los requerimientos de software, la carga de usuarios esperada debe ser tomada en consideración. Muchas compañías que utilizan ProjectWise verán un crecimiento en su uso a través del tiempo.

El siguiente cuadro muestra cómo un Integration Server se puede escalar para manejar una carga de hasta 2000 usuarios conectados. Sería una mejor práctica incluír un segundo (o mas) Integration Server, en un cluster o configuración de Network Load Balance, para permirir la conmutaciónpor error o para balancear la carga cuando se tiene uno cientos de usuarios o se necesita garantizara el tiempo de actividad. Se debe tener en cuenta que estos números son representativos de un SELECTseries 4 Integration Server que es 64bits verdadero.

Para ver el original de este artículo: http://projectwiseblog.com/2013/03/12/scaling-of-a-projectwise-system/

Performance en ProjectWise

Este es uno de los varios posts repecto a ProjectWise y Performance. Se cubrirán temas que ayudarán a entender qué hace que la performance de ProjectWise sea la correcta. Este tópico se refiere a la latencia y sus efectos en la performance.

Gran parte de la performance anticipada se puede determinar por la latencia entre los clientes y los servidores. En esta era digital, el ancho de banda y la latencia determinan la velocidad a la cual se reciben los datos. Lo bueno es que con plata generalmente se puede comprar mas ancho de banda, pero cuando se refiere a latencia, este no siempre es el caso. Latencia es la medida de tiempo que le toma a un paquete de datos en moverse desde / hacia. Los datos deben ir desde la interface del usuario al kernel, hacia placas de red, a switches, firewalls, routers, a otra placa de red, a otro kernel, y luego devuelta por la misma ruta. El tiempo que tarda todo este proceso se denomina latencia. Esta operación se realizará miles de veces por minuto. Por lo tanto, una latencia alta entrega baja performance sin importar el ancho de banda, que determina la cantidad de paquetes de datos que se pueden enviar simultaneamente.

La imagen debajo puede ayudar en cuanto a expectativas de performance.

Para ver el original de este artículo: http://projectwiseblog.com/2013/03/04/projectwise-performance/

Latencia, mejores prácticas

Dado que la latencia de una red tiene mucho que ver con performance, aquí algunas mejores prácticas que los usuarios pueden llevar a cabo para minimizar el efecto de la latencia. Siguiendo estos simples pasos en la rutina diaria se puede disminuir considerablemente la cantidad total de transacciones con el servidor y por lo tanto incrementar la performance.

• Apagar el Preview Pane en ProjectWise Explorer en las oficinas de alta latencia. Esto limitará la cantidad de datos y transacciones necesarias por el Cliente durante la navegación de carpetas y archivos.
• Limitar el uso de Vistas personalizadas, sólo mostrando un mínimo de datos acerca de cada archivos.
• Limitar el uso de titleblock integration con AutoCAD y MicroStation.
• Limitar la cantidad de atributos en todo Environment que sea utilizado en oficinas de alta latencia.
• Utilizar, cuando sea posible, Caching Server(s) como almacenamiento de archivos en oficinas de alta latencia.
• Utilizar, cuando sea posible, Cachin Server(s) como caché de archivos en oficinas de alta latencia.
• Utilizar Fetchfile.exe para pre-popular el caching de archivos locales.
• Limitar la cantidad de archivos en cualquier carpeta a un número manejable.
• Navegar utilizando el árbol de carpetas en ProjectWise y no seleccionando las sub-carpetas en la lista de contenidos.

Para ver el original de este artículo: http://projectwiseblog.com/2013/03/07/latency-best-practices/

Monitorear y Analizar sus sistemas con un contador de Performance

Uno de los problemas que parecen ser plaga para todo el mundo, estén utilizando ProjectWise o no es la performance.

La performance puede hacer que su sistema ejecute normalmente, como que los usuarios se quejen que el sistema no se puede utilizar.

Hay varias formas de realizar un control de performance, desde ver la performance en tiempo real en el Administrador de Tareas o realizar un monitoreo con una aplicación y luego realizar un análisis con una herramienta como PAL. La razón de realizarlo de esta forma es que se podrá recolectar datos en un período de tiempo especificado y luego obtener los resultados en un reporte codificado por color.

Debajo están los pasos para realizar esta operación. Para poder obtener los mejores resultados, se recomienda ejecutar esto por un mínimo de 24 horas, algunas veces será conveniente ejecutarlo por una semana o mas dependiendo en cuál sea el problema. La performance general se puede monitorear por 24 horas y los problemas de memoria es mejor monitorearlos por un período mas largo de tiempo. Esto realmente depende de qué es lo que se desea, pero 24 horas durante tiempo de producción es  lo mejor para monitorear performance en general.

1. Descargue el monitor de performance que está asociado al pie de este blog.
2. Descomprima el paquete de archivos y ejecute el archivo .bat como administrador. Estos contadores configurarán todo por Ud y agregarán los contadores de ProjectWise si lo está ejecutando en un servidor de ProjectWise.
3. Lea las instrucciones en pantalla para asegurarse que todo se está ejecutando correctamente. Permita que se ejecute por lo menos por 24 horas para mejores resultados.
4. Descargue e instale PAL desde esta dirección: http://pal.codeplex.com/ (puede utilizar su propia herramienta de análisis, esta es sólo una herramienta gratis).
5. Una vez que haya finalizado el monitor de performance, ejecute los logs del monitor de performance a través de PAL. PAL utiliza algunos recursos y tomará cierto tiempo procesar toda la información, por lo tanto, aseguresé que lo ejecuta en una máquina poderosa. 

Una vez que PAL finalizó con los resultados, se podrá visualizar un reporte codificado por colores para ayudarlo a corregir los problemas y le indicará qué está mal en su sistema. Lo ideal es realizar los cambios que sugiere el reporte y volver a ejecutar los pasos anteriores para asegurarse que todo está ejecutando correctamente. Seguramente deberá realizar este procedimiento varias veces hasta que el servidor esté corriendo como corresponde. Esto se puede y se ha realizado en todos los servidores de ProjectWise y en el servidor de Base de Datos.

No se olvide del servidor de Base de Datos, ProjectWise es una aplicación dependiente de base de datos, por lo tanto si la Base de Datos es lenta, ProjectWise será lento.

Algo a tener en consideración es si está monitoreando un servidor de base de datos SQL, consumirá toda la memoria que tenga alocada sin importar si la esta utilizando o no (así es como funciona SQL debido a que el acceso a memoria es mas rápido que al disco), por lo tanto esto puede parecer falta de memoria en el reporte, pero no le privará de ver si SQL se esta quedando sin memoria. 

Monitor de Performance: PW-permon.zip

Para ver el original de este articulo: Monitoring and analyzing your system with performance counters