¿Es está una gran Película? No lo sé, pero voy a averiguarlo 🙂
Santos la pelicula
Deja un comentario
Archivo por meses: diciembre 2008
Reporting Services, técnicas de alto desempeño
Escenario
Estamos trabajando en un proyecto de plataforma de reportes basada en SSRS [2] el cual tendrá una gran cantidad de usuarios por lo que debemos tomar medidas para asegurar buenos tiempos de respuestas con la infraestructura que tenemos. La idea es evitar tener que hacer Render de los reportes cada vez que los usuarios demandan los distintos informes.
En este Post voy a exponer opciones de mitigación de problemas de desempeño en SSRS en escenarios de alto desempeño. Mi fuente de información para este post es el libro de potente libro de Rodney Landrum y Walter Voytek [1]
Cuando se propone una solución de informes basada en un servidor de reportes versus la construcción programática ad hoc de reportes se busca el obtener diferentes beneficios tales como reutilización, control de acceso consistente, desempeño, etc.
En el aspecto de desempeño hay que entender que en una solución de informes de negocio, no todos los informes tienen una variabilidad de los datos tal que sea necesario construirlo cada vez que un usuario lo requiere. En este tipo de informes es donde se puede aplicar técnicas de mitigación para cuidar el desempeño de la solución de informes.
Opciones de Mitigación
Para los informes que tienen datos que no tienen una taza de cambios muy alta podemos aplicar las siguientes técnicas de mitigación de problemas de performance.
- Ejecución agendada de Reportes
- Servicio de subscripción de reportes
- Instantáneas (snapshots)
- Caching de Contenido
Ejecución Agendada de Reportes
La idea es programar la ejecución de reportes en momentos predeterminados. Es el servidor quien ejecuta la consulta y genera el informe sin necesidad de intervención del usuario. Estos informes pueden ser almacenados en el servido y así mantener una perspectiva histórica de los datos.
En la siguiente figura se muestra la página de configuración de los reportes agendados.
Ahora, como el reporte se ejecuta por el servicio (usando SQL Server Agent[3]) sin intervención de humanos , los parámetros del informe deben contener valores por defecto o soportar nulos.
El beneficio de usar reportes agendados es que cuando un usuario carga el informe, ve una “foto” que está ya calculado y formateado por lo que la respuesta es “instantánea”.
Instantáneas (SnapShots)
Esta alternativa consiste en almacenar una foto estática del informe. Existen dos tipos de SnapShots:
- Los que generan una foto del informe en un momento determinado
- Los que generan fotos históricas del informe en diferentes momentos
Los beneficios de performance de utilizar está técnica son que el reporte ya está pre procesado y que no necesita hacer consultas a la base de datos. La siguiente imagen muestra la configuración del SnapShots.
Caching de Contenido
Está técnica es utilizada cuando los diferentes usuarios ven informes con datos que dependen de parámetros que ellos ingresan. En este caso, el contenido agendado no aplica porque genere el mismo resultado para todos los usuarios. El manejó de Cache de SSRS permite mantener copias de los reportes para cada informe las cuales se generan la primera vez que el cliente ve el informe. Las subsecuentes veces que se pide el informe y si ciertas condiciones coinciden el informe no se vuelve a generar sino que se usa la copia del Cache.
Las condiciones en la cuales un usuario recibirá un informe desde el Cache son:
- EL usuario subsecuente accede al informe antes que el tiempo de expiración de la copia del Cache se cumpla. Pasado ese tiempo el informe vuelve a calcularse y generar una nueva copia en el Cache.
- Si los parámetros del informe que el usuario está accediendo cambian, este reporte se calcula y genera una nueva copia en el Cache.
- El informe de la fuente de datos no está configurado para la autenticación de Windows o pregunte al usuario las credenciales de inicio de sesión
Esta técnica es muy buena para proteger el desempeño de reportes que consumen muchos recursos al hacer el Render. El Trade-Off es que no se pueden usar en informes que tienen datos sensibles en el tiempo, por ejemplo valores de la bolsa en horario de transacciones.Otro tema importante es preocuparse tanto en Cache como SnapShots es el uso de disco. La siguiente imagen es la configuración del Cache.
Servicio de Subscripción de Reportes
A diferencia de las otras tres técnicas presentadas en este Post, este servicio permite calcular los informes y enviarlo a los usuarios subscritos. Hacer esto evita que los usuarios vayan el servidor de informes y pedir su informe sino que el servicio se los envía. Las opciones de envío son las siguientes:
- Poner una copia en un lugar específico
- Envió por mail
- En algún sitio compartido en la red
- Incluso directo a la impresora
Usar está técnica tiene el beneficio de poder producir los reportes fuera de horarios punta ayudando así a evitar posibles denegación de servicios por sobrecarga de trabajo. Los informes pueden ser generados en diferentes formatos siendo el formato por defecto el Web Archive, pero podría ser otro como una imagen TIF o un PDF.
Podemos trabajar con dos tipos de subscripciones:
Standard Subscriptions: Es una configuración estática para uno o mas usuarios. Los parametros son los mismos para todos.
Data-driven subscriptions: La lista de suscripción es dinámica y puede ser resultado de una consulta. Esta es la forma más potente de trabajo, pero solo está disponible en la versión Enterprise de SQL.
Referencias
[1] Pro SQL Server 2005 Reporting Services
[2] SSRS
[3] SQL Server Agent
Los herederos
Carlos Peña escribió el domingo 28 en el cuerpo de reportajes del Perjurio, perdón del Mercurio, una columna notable sobre los resultados de la PSU (Prueba de selección Universitaria). La comparto aquí con ustedes.
Los resultados de la PSU dieron ocasión para que, por enésima vez, todos pusieran el grito en el cielo. Las causas de la abismante desigualdad (cuatro de diez estudiantes de escuelas municipalizadas no alcanzaron el mínimo) fueron rápidamente identificadas: el estatuto docente, los profesores, la gestión escolar, la LOCE, la educación municipal, la lenidad administrativa, la propia PSU. Cosas así.Pero ninguno de esos factores es el culpable definitivo.El año 1964, Pierre Bourdieu -uno de esos sociólogos que ya no se dan- publicó, junto a Jean Claude Passeron, un librito que llevaba por título "Los herederos".
A pesar de su apariencia inofensiva, el texto causó polémica. La función principal del sistema escolar, argüía el texto, era la de reproducir las divisiones sociales en vez de contribuir a remediarlas. Allí donde los franceses creían que la escuela era el lugar de la meritocracia, el sitio donde los ideales republicanos encontraban realización, Bourdieu y Passeron, con una amplia prueba empírica, sugerían lo contrario: la escuela eliminaba a los socialmente desfavorecidos y premiaba a los de mejor origen. Las diferencias de rendimiento escolar -concluían los autores- eran diferencias de clase. No muy lejos, y en 1973, Basil Bernstein -un sociólogo de origen judío, graduado en lingüística- investigó por qué a los hijos de la clase trabajadora inglesa les iba consistentemente mal en las pruebas estandarizadas. ¿Acaso estaban menos dotados que las clases medias y altas? No, dijo Berstein, lo que ocurre es que, como consecuencia de la división del trabajo, poseen un código lingüístico más restringido.
Las pruebas estandarizadas -concluía Berstein- reflejaban diferentes posiciones en la estructura social. El año 2004, el informe de la OECD constató en los países europeos severas diferencias de rendimiento entre los centros educativos. ¿A qué se debían? Más de la mitad de esas diferencias, concluía el informe, se explicaban por el entorno socioeconómico. Las investigaciones de Bourdieu, Berstein y la OECD se ven corroboradas por enésima vez en Chile. Los resultados de la última PSU -como antes las pruebas PAA, Simce o PISA- muestran que existe una estrecha relación entre origen socioeconómico y rendimiento.
En otras palabras, el origen social, sobre todo entre nosotros, es más predictivo del rendimiento que el esfuerzo personal. La conclusión es bastante obvia: la escuela y las pruebas estandarizadas expresan diferencias sociales. La brecha entre colegios públicos y privados es en verdad una brecha de clases. ¿Qué lecciones sacar de todo eso? La más evidente de todas es que no siempre es correcto asignar los cupos más selectivos del sistema universitario atendiendo solamente a la PSU. Como la PSU refleja diferencias sociales, echar mano exclusivamente a ella para asignar los lugares más escasos (esos que conferirán los lugares más altos de la escala invisible del prestigio y del poder) equivale simplemente a reproducir las élites actualmente existentes. Se suma a lo anterior que los problemas que hoy experimenta el sistema escolar no se deben a que haya empeorado. El de antes era peor. Lo que ocurre es que ayer la desigualdad social se expresaba como exclusión (para el año 1973, menos del cincuenta por ciento de los jóvenes lograba matricularse en un liceo) y hoy (cuando todos los niños y niñas están en una sala de clases) se expresa en los resultados del aprendizaje. Para curar esa desigualdad se saca poco con apelar a la familia, como suele hacerlo la retórica educacional al uso. Como la familia es una de las principales transmisoras de capital cultural, ella es también una fuente de desigualdad. A veces la familia es, por decirlo así, el problema y no la solución. Los datos que arroja la última PSU, como antes la PAA, nos ayudan, además, a curarnos de la ilusión meritocrática y nos recuerdan los ocultos mecanismos de la distribución del poder y el prestigio. En el promedio, los que resultan más favorecidos en las pruebas (y que en el futuro serán parte de las élites) se han beneficiado de circunstancias que no se deben a su desempeño o su voluntad. En algún sentido los triunfadores de la PSU tienen tanto de qué enorgullecerse como cualquier heredero: no de mucho. En fin, la evidencia disponible ayuda a evitar la ingenuidad entusiasta que por estos días cunde. Hoy día pareciéramos creer que con un poco de buena voluntad, algo de recursos y management los problemas de la educación se disiparán. Esta manera de apreciar el problema olvida que la educación, por su propia índole, tiende a reproducir las posiciones sociales previas y que, por lo mismo, no es el punto de partida de la desigualdad, sino, las más de las veces, su punto de llegada. Nada de eso significa, por supuesto, que debamos cruzarnos de brazos y no hacer nada. Hay que hacerlo, por supuesto. Formar mejor los profesores, evaluar las prácticas educativas, diferenciar recursos. Pero -malas noticias- lo que hay que hacer no se relaciona sólo con la escuela.
Referencia
19 mistakes technical leaders make most often
Me pasaron (Javier) este Post de TechRepublic que está muy bueno para las personas que lideran equipos técnicos. Les comparto los 19 errores comunes que cometemos los lideres de equipos técnicos.
- Asumir que el equipo está a su servicio, muy común en nuestro pueblo de patrones de fundo.
- Aislarse del equipo
- Employing hokey motivation techniques
- No proporcionar la dirección técnica y el contexto, error común de los malos manager porque asignan tareas operativas en vez de delegar
- El cumplimiento de sus propias necesidades a través del equipo
- Centrarse en la contribución individual, esto pasa sobre todo en los equipos inmaduros que necesitan “héroes”
- Tratando de ser técnicamente omnisciente, nadie lo sabe todo excepto dios Google 🙂
- Falla en delegar eficazmente
- No conocer tus propias deficiencias
- Fallar al representar los intereses de su equipo
- Fallar en anticiparse
- Repetir los mismos errores que otras ya cometieron
- Usar el proyecto para perseguir sus propios intereses técnicos
- No mantener a los técnicos involucrados
- Jugar el juego en lugar de centrarse en el objetivo
- Evitar el conflicto, ufff esto pasa todo el tiempo, es nuestra cultura!
- Poner el proyecto antes que la gente, ojo los proyectos pasan el equipo queda.
- Esperar que todos piensen y actúen como él, otro problema que veo en nuestra cultura
- Fallar al mostrar compasión
Referencia
19 mistakes technical leaders make most often | View from the Cubicle | TechRepublic.com
Evento Especial «Lo mejor del PDC 2008»
El día de ayer participé en el evento “Lo mejor del PDC2008”. Este es un evento organizado por Microsoft para difundir la información técnica presentada en el evento PDC2008 en Los Ángeles en Noviembre. El PDC es el mejor evento técnico que Microsoft hace a Nivel mundial.
En este evento me tocó participar de dos conferencias. La primera es del proyecto Dublín, que es un proyecto de construir un Applicaction Server para DotNEt. Creo que esto va a ser muy interesante para los desarrolladores porque les da un importante soporte para sus aplicaciones de negocio. Aquí esta la presentación.
La segunda presentación que participé fue sobre C# 4.0. C#, al igual que todos los proyectos comerciales de software, salió en su versión 1.0 “apurado” y era el lenguaje “seguidor” de otro muy famoso. Luego la versión 2.0 incluyo todo lo que debía y alcanzó al otro lenguaje. La versión 3.0 incluyo Linq que dio a los desarrolladores que siguen el paradigma de objetos la libertad de hacer consultas a colecciones de objetos y así “poder” abstraerse del uso de motores relacionales para las tareas de consultas y filtros. Por último la versión 4.0, que no sale todavía, traerá una nueva “innovación”. C# 4.0 podrá manejar tipos dinámicos. En mi opinión de desarrollador, C# brinda la libertad de unir el mundo “fuertemente tipado” con el mundo dinámico. Lo cual es muy potente, todo ese poder es articulado por el DLR que es la pieza clave para esto. Ahora, esta libertad en manos de desarrolladores no preparados será un problema porque le dará la posibilidad de inyectar errores que el compilador no detectará y puestos esos software en producción la traza del error será costosa. La presentación fué la sigueinte.
Todos sus comentarios son bienvenididos 🙂
Pocket Guide Series for Application Architecture
El grupo de P&P desarrollo un grupo de guías de arquitectura de bolsillo. Estas guías están basadas en la guía de arquitectura de aplicaciones 2.0 del mismo grupo. Son muy recomendables para las personas que están pensando en el software que se construirá más que en el cómo se programa.
Pocket Guides
Hail en Chile!!!
Que gran banda y además toca en ese estupendo local del puerto –> el HUEVO
Evento Especial PDC 2008
Estimados, como les conté anteriormente vamos a realizar un evento para mostrar lo mejor que vimos en el evento técnico PDC2008. Este es el evento técnico más importante que Microsoft hace.
Aquí está ya la agenda para que vayan viendo a que sesiones van ha asistir!!!!
No se lo pueden perder!
|
Inicio |
Fin |
Sala 1 |
Sala 2 |
Duración |
|
14:00 |
14:30 |
Almuerzo |
30m |
|
|
14:30 |
15:00 |
Apertura |
30m |
|
|
15:00 |
16:00 |
Application Server Extensions, Proyecto "Dublin" |
Parallel Computing |
60m |
|
16:00 |
16:15 |
Coffee Break |
15m |
|
|
16:15 |
17:15 |
Conozca las últimas novedades de ASP.NET |
Windows Azure, la nueva plataforma de Cloud Computing |
60m |
|
17:15 |
18:15 |
El futuro de C# |
Lo que se viene en Visual Studio 2010 y .NET 4.0 |
60m |
|
18:15 |
18:30 |
Cierre y Sorteo |
15m |
|
Datos útiles
- 17 de Diciembre, de 14:00 a 19:30 hrs.
- Hotel Intercontinental, Av. Vitacura 2885, Las Condes. Santiago.
- Registro aquí
Presentación del Architect Forum: Arquitectura de Inteligencia de Negocios
Aquí comparto con ustedes la presentación que realicé en el foro de arquitectos el miércoles 11. Es una presentación de conceptos básicos tratando de abordarlo desde la perspectiva de la arquitectura de software.
Invitación al Architect Forum: Arquitectura de Inteligencia de Negocios, del próximo 10-dic
Estimados
Queremos invitarlos a participar de un nuevo Architect Forum, a realizarse el próximo miércoles 10 de diciembre en las oficinas de Microsoft Chile.
En esta oportunidad, abordaremos la Arquitectura de Inteligencia de Negocios como tema principal del fórum.
Muchas compañías hoy en día producen y almacenan una alucinante cantidad de datos. Los números son difíciles de entender: en tan sólo unos pocos años, la terminología común para volúmenes de datos ha crecido de megabytes a gigabytes a terabytes (un billón de bytes). El tamaño de los datos de algunas grandes empresas de escala mundial inclusive se acerca a los petabyte (a cuatrillones de bytes). Imagine la cantidad de datos que son estos, para poner esto en perspectiva piense que el famoso supermercado norteamericano Wal-Mart almacenó 538 TB en su base de datos mientras que la colección impresa de la biblioteca del congreso Norte Americano el mismo año (2006) solo almacenó 20 TB.
La construcción de una sólida capacidad analítica requiere mucho más que la captura y almacenamiento de datos en grandes cantidades. Hay muchas piezas en movimiento para poner en su lugar, incluyendo aplicaciones de software, tecnología, datos, procesos, métrica, incentivos, las habilidades, la cultura, y el patrocinio de los directivos. Un importante primer paso para cualquier organización es comprender los elementos de una Arquitectura de Inteligencia de Negocios a fin de que la estructura pueda poner orden al caótico universo de bytes de datos.
Durante este fórum revisaremos los conceptos fundamentales de las soluciones de Business Intelligence desde la perspectiva de los arquitectos de software para luego ver herramientas concretas de la plataforma Microsoft para implementar este tipo de soluciones.
Para poder inscribirse a este evento tienen que hacer click aquí o enviar un email a la siguiente dirección: v-tamvil@microsoft.com
Los esperamos!
..:: Liarjo of Locksley ::.. 