Categories
Perú PostgreSQL Software Libre

PostgreSQL Day Perú 2007

Este sábado, se realizará un pequeño evento sobre PostgreSQL:

Pedimos disculpa si el presente mail le llega por diversas listas.

La comunidad PostgreSQL Peru (http://www.postgresql.org.pe) tiene el agrado de invitarte a participar de nuestro primer PostgreSQL Day a llevarse a cabo este sábado 8 de Septiembre de 3pm a 8pm en los locales de la Universidad Cayetano Heredia de Miraflores (Av. Armendariz 445 - Miraflores - Lima).

El programa del evento es:

  • 3:00 pm Inauguración
    • Palabras de bienvenida al evento (10")
  • 3:10 pm Introducción a PostgreSQL
    1. Que es PostgreSQL (20")
    2. Estandares SQL92 AnSI y SQL99 (20")
    3. Comparativas contra otros dbms libres (20")
  • 4:10 pm Instalación de PostgreSQL en diversas plataformas
    1. Debian (15")
    2. CentOS (15")
    3. Windows (15")
    4. FreeBSD (15")
    5. Preguntas (20")
  • 5:30pm Break 15"
  • 5:45pm Entornos de Administración
    1. PgAdmin3 (20")
    2. PhpPgAdmin (20")
    3. Consola (20")
    4. Preguntas (20")
  • 7:05pm Mesa redonda de experiencias
    1. Experiencia Xendra (10")
    2. Experiencia Cargo Master (10")
    3. Experiencias EQSoft-Asoc. Empleados del BCP (10")
    4. Rueda de preguntas (25")

No es necesario inscribirse, se ingresará por orden de llegada, tenemos capacidad para recibir a 150 personas por lo cual te invitamos a llegar temprano, mas información sobre el evento será publicada en nuestra página web en los siguientes días, las diapositivas del evento serán publicadas en el mismo lugar.

Información sobre PostgreSQL:
PostgreSQL es un motor de base de datos totalmente libre, multiplataforma y de altas prestaciones, probado en varios proyectos a nivel nacional e internacional, es estable, rápido y fácil de utilizar, si quieres saber mas de PostgreSQL puedes visitar nuestra página web en http://www.postgresql.org.pe o la página principal del proyecto en http://www.postgresql.org

Si estás cerca y todavía sigues usando ciegamente MySQL te gustaría conocer algo más sobre PostgreSQL, ésta es tu oportunidad. 😉

Categories
PostgreSQL

Determinar el número de filas en PostgreSQL

Como suelo olvidar con facilidad ciertas cosas y al no usar mucho del.icio.us para recordarlas, pongo aquí un artículo que encontré hace unos días por si alguien más le encuentra utilidad. 😉

En cualquier gestor de base de datos, para conocer el número de registros basta con hacer uso de la función de agregación count.

sql:

SELECT count(*) FROM tabla;

Pero hacer esta operación en PostgreSQL sobre tablas grandes es bastante costosa porque se realiza un recorrido secuencial para obtener el número exacto de registros.

code:

test=> EXPLAIN ANALYZE SELECT COUNT(*) FROM actor;
                                               QUERY PLAN
---------------------------------------------------------------------------------------------------------
 Aggregate  (cost=4.50..4.51 rows=1 width=0) (actual time=0.882..0.884 rows=1 loops=1)

   ->  Seq Scan on actor  (cost=0.00..4.00 rows=200 width=0) (actual time=0.011..0.432 rows=200 loops=1)

 Total runtime: 0.963 ms
(3 filas)

Una forma de obtener el número aproximado de registros de manera rápida y sin los problemas inherentes al uso de la función count, es haciendo una consulta a los catálogos del sistema (pg_class):

sql:

SELECT reltuples FROM pg_class
   JOIN pg_namespace ON (pg_class.relnamespace = pg_namespace.oid)
WHERE nspname = 'public' -- esquema
AND relname = 'actor'; -- nombre de la tabla

Para que lo anterior funcione o dé resultados más cercanos a la realidad, es necesario ejecutar ANALYZE sobre esa tabla, tarea que se debe realizar periódicamente.

Categories
ASP.NET

20 tips para mejorar el rendimiento de aplicaciones ASP.NET

Me tomé la libertad de hacer una traducción libre (con algunos comentarios míos agregados) de "20 Tips to Improve ASP.net Application Performance":

  1. Deshabilitar el estado de sesión: Si no se usa, entonces es mejor desactivarlo puesto que aparte de consumir recursos del servidor, generalmente también lo hace en el tráfico HTTP entre servidor y cliente al propagar el ID de la sesión. Esta opción se puede desactivar a nivel de la aplicación (elemento sessionState del web.config) o para páginas individuales (propiedad EnableSessionState).
  2. Activa el buffer de la página: Para reducir la comunicación entre cliente y servidor es mejor enviar los contenidos en bloque.

    When you run your ASP.NET application by using the ASP.NET process model, it is even more important to have buffering enabled. The ASP.NET worker process first sends responses to IIS in the form of response buffers. After the ISAPI filter is running, IIS receives the response buffers. These response buffers are 31 KB in size., After IIS receives the response buffers, it then sends that actual response back to the client. With buffering disabled, instead of using the entire 31-KB buffer, ASP.NET can only send a few characters to the buffer. This causes extra CPU processing in both ASP.NET as well as in IIS. This may also cause memory consumption in the IIS process to increase dramatically.

  3. Evitar la validación en el lado del servidor: En el artículo original el autor recomienda realizar la validación sólo en el cliente (javascript), pero en mi opinión, esto es un error, puesto que depender solamente de javascript para este tipo de cosas es como no hacer nada.
  4. Usar el control Repeater y evitar en lo posible el uso de los controles DataList, DataGrid y DataView: Los últimos no son recomendados porque generan mucho código HTML, pero en ASP.NET 2 esto se puede solventar usando los Control Adapters o usando otra forma para desarrollar aplicaciones ASP.NET.
  5. Usar HttpResponse.IsClientConnected: Verficar si el cliente todavía sigue conectado antes de realizar operaciones costosas.

    Consider using the HttpResponse.IsClientConnected property to verify if the client is still connected before processing a request and performing expensive server-side operations. However, this call may need to go out of process on IIS 5.0 and can be very expensive. If you use it, measure whether it actually benefits your scenario.

  6. Usar HTTPServerUtility.Transfer en lugar de Response.Redirect: El último envía las cabeceras necesarias (Location) al cliente y éste hace una nueva petición al servidor Web en base a esa cabecera.
  7. Usar siempre Page.IsValid cuando se trabaja con los controles de validación: Esto principalmente se debe a lo que comentaba en el punto 3, la única forma de asegurar que los datos cumplen con las reglas de validación definidas en esos controles -- de validación --, es verificando el valor de esa propiedad.
  8. Desplegar las aplicaciones en modo Release: Esto es para que se hagan las optimizaciones necesarias al momento de compilar la página y/o aplicación, además de otros
    Leer el siguiente importantes aspectos.
  9. Deshabilitar el seguimiento de página: No hay ninguna razón válida para que esta característica esté habilitada en una aplicación en producción.
  10. Page.IsPostBack es tu amigo: Hay acciones/código que puede evitarse cuando el cliente realiza una petición (envía la página a través del método POST).
  11. Minimizar el número de excepciones: En una aplicación y escenario ideal no habrá este tipo de problemas, pero como nosotros siempre nos equivocamos por el mismo hecho de ser humanos, tenemos que tomar medidas necesarias para reducir al mínimo posible el número de excepciones que genera una aplicación. Una lectura recomendada al respecto.
  12. Usar la cache: Poner en cache aquellos datos que no cambian mucho. Por otro lado, usar el cache de salida para páginas o partes de páginas que no cambian frecuentemente.
  13. Usar/crear cache por petición: Usar HttpContext.Items para mantener los datos que se necesitan en las diferentes etapas del proceso que sigue una página ASP.NET antes de llegar al cliente.
  14. Usar StringBuilder para operaciones intensivas con cadenas.
  15. Deshabilitar el ViewState: Toda la "magia" de los controles de servidor de ASP.NET dependen de esta característica: los datos se serializan en campos ocultos que se envían/reciben en cada petición. Así que si alguien quiere "venderles" ASP.NET con la idea de que hacer aplicaciones de escritorio es igual que hacer aplicaciones Web, ya saben cuáles son los inconvenientes.
  16. Usar paginación: Sólo recuperar los datos necesarios para la página que se visualiza, de preferencia esto se debe realizar desde la base de datos.
  17. Usar App_offline.htm para actualizar las aplicaciones.
  18. Usar ControlState en lugar del ViewState para los controles: En el artículo original se recomienda el uso del control de estado, pero hasta donde sé, da lo mismo usar uno u otro, porque el control de estado también tiene los mismos inconvenientes que el ViewState con la única diferencia que éste no puede deshabilitarse.
  19. Usar el bloque finally para asegurarse que todos los recursos son liberados adecuadamente, aunque también se puede usar la instrucción using para este caso.
  20. Usar Option Strict y Option Explicit, supongo que alguno que desarrolle en VB.NET puede justificar esta parte.

Si alguien está interesado en leer información más útil y específica para mejorar el rendimiento de las aplicaciones ASP.NET, puede darle una mirada a Improving ASP.NET Performance y Scalable Apps with Asynchronous Programming in ASP.NET.