Author: alex

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.

Categories
Internet Explorer Web

Cookies

Una cookie es un fragmento de información que se almacena en el disco duro del visitante de una página web a través de su navegador, a petición del servidor de la página. Esta información puede ser luego recuperada por el servidor en posteriores visitas.

No suelo darle importancia a las novedades de Internet Explorer, pero hoy me pareció interesante algunos consejos que dan desde el blog de éste navegador para reducir el tráfico HTTP que se produce entre un servidor y un cliente.

Antes de continuar, estas son las nuevas limitaciones que impone Internet Explorer para el manejo de Cookies:

  • Se incrementó de 20 a 50 el número de cookies que se puede crear por dominio.
  • document.cookie retornará una cadena vacía si el tamaño de las cookies es mayor a 4096 bytes.
  • El navegador ignorará las cabeceras Set-Cookie si éstas exceden de 5118 bytes.

Volviendo al tema anterior, éstos son los consejos que sugieren para reducir el tráfico HTTP:

  • Reducir el tamaño de las cookies: Recomiendan utilizar nombres y si es posible, valores más cortos. Ejm. en lugar de una cookie denominada username, usar sólo u.
  • Servir el contenido estático desde otro (sub)dominio: Una vez que el servidor envía las cookies usando la cabecera Set-Cookie, un navegador convencional enviará de vuelta estos valores en cada petición que se haga al servidor. Como los valores de las cookies son irrelevantes para los archivos estáticos, entonces se genera tráfico innecesario.
  • Usar el atributo path sólo cuando sea necesario: El atributo path permite manejar cookies para rutas específicas de un dominio, por ejemplo si se envían cookies para la ruta /aplicacion, entonces en el servidor se podrá acceder a estos valores sólo desde esa ruta *. Usar este atributo en general va a depender de los requerimientos de la aplicación, pero si quieres ahorrar unos cuantos bytes entonces haz que la ruta sea para todo el dominio.

Las resultados de estos consejos seguramente van a ser más evidentes en sitios con mucho tráfico que en sitios como éste, donde el número de lectores se puede contar con los dedos de la mano. 😀

*: En realidad se puede acceder a todos los datos de la petición y por consiguiente a todas las cookies, pero de manera convencional algunos lenguajes abstraen esta funcionalidad para dar acceso sólo a las cookies definidas para una ruta.

Categories
WordPress

Novedades de WordPress 2.3

Acaba de liberarse la primera beta de la versión 2.3 (incluye el parche para la vulnerabilidad previamente comentada).

Complementando a lo que Andrés ya publicó sobre las novedades que WordPress 2.3 incluirá, aquí les presento otras:

  • Notificación de la existencia de versiones nuevas, por el momento éstas notificaciones aparecen en el pie de página de la parte de administración. En mi opinión éstas deberían ser más visibles y llamativas -- algo parecido a lo que hace el plugin Akismet cuando recién se instala.

    Las consultas de nuevas versiones se hacen a http://api.wordpress.org/core/version-check/1.0/?version=VERSION&php=VERSION_PHP&locale=

  • Redirecciones automáticas en los siguientes casos:

    • Si la dirección URL del blog usa www o no (se obtiene del valor definido en las opciones).
    • Para el caso de blogs -- como éste -- que usen estructuras de permalinks que terminan en /, antes se aceptaba por ejemplo http://www.buayacorp.com/archivos/cusco y http://www.buayacorp.com/archivos/cusco/, ahora se redirigen correctamente a la versión con /.
    • Si sólo se especifica parte del nombre de la entrada, http://www.buayacorp.com/archivos/cus será redireccionado a http://www.buayacorp.com/archivos/cusco/.
  • Uso de Google Blog Search para mostrar los enlaces entrantes.
  • Posible auditoría de seguridad antes de la liberación de una versión estable.

Sin duda, el punto que más me llama la atención es la auditoría de seguridad al código de WordPress, que le vendría muy bien luego de los problemas reportados a lo largo del 2007, aunque me parece que éstos problemas no se reducirán mucho si no se mejora la forma de acceder a los datos.

Categories
Seguridad WordPress

WordPress: Lista de plugins no recomendados – Parte 2

Como seguramente saben, Weblog Tools Collection organizó un concurso de plugins para WordPress y hoy, casi un mes después que terminó el concurso, dan a conocer los resultados:

  1. El ganador del gran premio, el primero, de esta competición de Plugins para WordPress es para Anirudh Sanjeev por su plugin OneClick. OneClick es un plugin para WordPress y una extensión para Firefox que permite la instalación rápida y directa de plugins y temas en tu blog, con solo un clic. Ha recibido el premio más cuantioso, con un servidor dedicado básico para 6 meses (valorado en más de 1000 dólares) y un iPod Nano de 8 Gb (valorado en 600 dólares) o el dinero equivalente.
  2. El ganador del segundo premio es para Barry por su plugin MyDashboard. MyDashboard permite la rápida personalización del escritorio de WordPress.
  3. El ganador del tercer premio es para Keith Dsouza por su plugin WordPress Automatic Upgrade el cual permite actualizar de forma automática la instalación de tu WordPress desde la interfaz de administración.
  4. El ganador del premio de consolación ha sido Ozh por su plugin Who Sees Ads. WhoSeesAds es un maravillo e útil módulo que permite a los usuarios de WordPress determinar que anuncios se deben ver en cada momento en su blog.

Fuente

Luego de hacer unas pruebas en una instalación local de WordPress y ver someramente el código de estos plugins, veo que ninguno de ellos toma en cuenta el tema de seguridad, así que haré mi propia lista de plugins tomando como parámetro de ordenación el grado de peligrosidad (de mayor a menor):

  1. WordPress Automatic Upgrade: Permite a cualquier usuario no autenticado:
    • Generar y descargar los archivos de WordPress (incluye wp-config.php).
    • Generar y descargar una copia de seguridad de la base de datos donde está instalado el plugin.
    • Activar/Desactivar todos los plugins.
    • Actualizar la versión de WordPress.
  2. OneClick: Al ser vulnerable a CSRF, permite descargar plugins -- o código malicioso -- desde cualquier URL.
  3. Who Sees Ads: Es vulnerable a CSRF y XSS.
  4. MyDashboard: Es vulnerable a CSRF y XSS.

Si tienen esos plugins instalados (en especial los dos primeros), les sugiero que los desactiven cuanto antes, porque gracias a toda la publicidad que están recibiendo, seguramente pronto van a ser blanco de ataques.

Viendo estos ejemplos, no sé cómo algunos bloggers se quejan de la cantidad de fallos del código principal de WordPress y no dicen nada al respecto de los plugins, cuando muchas veces éstos últimos provocan problemas de seguridad aún más graves.