charly_rojo

Alberto Nakayama sobre el funcionamiento de Taringa.net,..,la red de servidores y recursos que el sitio consume actualmente es impresionante. Para un sitio como Taringa, con más de 13 millones de páginas vistas por mes, mantenerse optimizado es crucial, en el sentido en que esto implica una reducción en el ancho de banda que se consume, y por ende, en los gastos mensuales en servidores y su mantenimiento. La gran pregunta es, ¿pueden los estándares web ayudar a minimizar los costos de funcionamiento de Taringa? En este post explico como optimizé la página principal, utilizando técnicas simples de estándares web, logrando reducir su tamaño en aproximadamente un 50%, de esta manera, ahorrando miles de dólares mensuales en servidores y su mantenimiento. El problema Una rápida inspección al código HTML de la página principal muestra que el sitio no parece tan optimizado como uno quisiera. Algunos puntos que pude identificar: * H1, el elemento más importante de una página no está siendo usado. Este elemento se encarga de describir el título de la página, además de proveer valiosos keywords a los buscadores. Tampoco hay una jerarquía de cabeceras (H1, H2, H3) coherente. * Semántica pobre. No se usan los elementos de HTML para describir el contenido correspondiente. Una lista de ítems, que lógicamente se marcaría con el elemento UL, en Taringa se reemplaza por una serie de DIVs. DIV se usa para describir una sección de una página —como una cabecera, por ejemplo, o un conjunto de elementos. UL, en cambio, se usa para describir una lista no ordenada de elementos, en el caso de Taringa, podríamos usar UL para describir los últimos posts enviados. * Poca optimización para buscadores (SEO). Esto es claramente una consecuencia del punto anterior. Los buscadores aman el contenido, pero también un contenido bien marcado y elementos de HTML bien usados. Mientras más limpio sea el código de una página, mayor indexabilidad tendrá. En promedio, la página principal de Taringa pesa 50KB. El sitio sirve más de 13 millones de páginas vistas por día, en un cálculo rápido, más de 600GB son transferidos por día (50KB x 13M = 620GB). Haciendo un cálculo rústico de 1GB = 1 dólar, nos revela que Taringa gastaría 600 dólares por día solamente en servir HTML. Es bueno aclarar que en este artículo no voy a rediseñar la parte visual de Taringa. Hace un tiempo trabajé en Trade2Win.com, un sitio con alrededor de 2 millones de impresiones al mes, y aprendí que en sitios similares con mucho tráfico, las decisiones visuales deben hacerse con muchísimo cuidado porque repercuten directamente en los hábitos de uso de millones de usuarios. Un retoque pequeño, y al parecer inofensivo, como cambiar el ícono de búsqueda por otro que al parecer funcionaría mejor, puede traer consecuencias desastrosas. Por lo tanto, solo me voy a enfocar en rediseñar el código HTML y CSS de la página principal del sitio, tratando de ser fiel al estilo visual del sitio lo más posible. Optimización para buscadores Una de las ventajas de diseñar con estándares viene de regalo: la optimización del sitio en buscadores. Los estándares (en este artículo hablamos solamente de HTML, CSS y JS) fomentan la semántica, y los buscadores en general valoran a las páginas semánticas sobre aquellas que no lo son. La semántica, en pocas palabras, trata sobre el uso de un elemento determinado de HTML para describir el contenido para el que fue creado: por ejemplo, es lógico que el título de una página se marque con el elemento H1, ya que es el elemento más importante, pero en Taringa se lo reemplaza por una combinación de DIVs y As. Google, en todo caso, no podría encontrar el título de la página ya que no hay un H1 disponible, penalizando su posición en los resultados. Ahora bien, el listado de últimos posts en la página principal es tal vez lo más interesante del sitio. Cada ítem se describe con un título y uno o dos íconos para una mejor identificación visual de la categoría. Éste es el código que se usa actualmente en Taringa para mostrar los últimos posts: <div class="link"> <div class="link_titulo"> <span class="categoria arte" alt="Arte" title="Arte"></span> <a href="" target="_self" title="Firmas A Pedido" alt=" Firmas A Pedido" class="box_link">Firmas A Pedido</a> </div> </div> Claramente, es demasiado. Se usa un serie de SPANs para cada ícono, todo agrupado en un conjunto de DIVs, resultando en código no optimizado. Una propuesta, utilizando estándares web y marcado semántico, podría ser de la siguiente manera: <li class="icon-art" title="arte"> <a href="">Firmas A Pedido</a> </li> Como vemos, cada ítem es marcado con su elemento correspondiente, LI. Luego, el atributo class se encargará de mostrar los íconos correspondientes para cada ítem, salvando preciosos bits y eliminando DIVs sin función. Este enfoque semántico, del ejemplo, se extiende a toda la página, desde la lista de posts nuevos, hasta los posts más votados e incluso los avisos de Taringa. De ahora en más, Google no interpretará la página principal de Taringa como una serie de contenido tirado sin descripción, ya que cada elemento ahora describe perfectamente su contenido, proveyendo mejor información para su clasificación e indexación. Reduciendo la cantidad de pedidos al servidor Alberto inteligentemente implementa CSS Sprites para mostrar los íconos en cada post. La idea es utilizar un archivo GIF con todos los íconos, en vez de 50 o más archivos separados, de esta manera reduciendo la cantidad de pedidos al servidor y disminuyendo la carga. En este ejemplo, fuí un poco más allá y extendí el concepto para todas las imágenes del sitio, incluyendo los logos de Taringa/Google en la caja del buscador y los logos del pie de página. Los íconos de los sponsors también fueron optimizados. Iconos en Taringa.net Una propuesta de organización de íconos para Taringa En total, contando íconos, logos y otras imágenes, Taringa usa 14 archivos GIF. Esta optimización de imágenes me permitió reducirlos a solamente 2. En números fríos, una reducción de más del 85% en pedidos al servidor. Flexibilidad a prueba de balas Una mención aparte se merecen las imágenes con bordes redondeados, por ejemplo, el marco contenedor de la página, y muy especialmente, las secciones o módulos de Taringa. Es demasiado frustante para un diseñador no tener otra alternativa que aplicar artilugios varios para poder mostrar un simple borde redondeado. CSS es un lenguaje con muchas fallas, pero en mi opinión, esta es la más grave. Sin embargo, siempre se puede optimizar y simplificar. A modo de ejemplo, para mostrar el marco contenedor del sitio, en azul, Taringa usa 2 imágenes diferentes (rtopbg.gif y maincontainerbg.gif), además de código no semántico en el HTML para mostrarlas. Aunque este enfoque es totalmente válido, todavía se puede utilizar una sola imágen, y eliminar los DIVs extra en el HTML para una mejor interpretación del documento. Con un poco de CSS luego nos encargaremos de mostrar los bordes de la imágen, ya sea superiores o inferiores, reduciendo los pedidos al servidor en un 50%. Otros criterios de optimización se aplicaron para otras partes de la página. La clave, siempre, es simplificar. Las secciones, o módulos de Taringa, requiren una explicación aparte. En el sitio actual, se usan 4 imágenes para mostrar los bordes redondeados: 2 para cada esquina, uno para el fondo del título del módulo, y una imágen para los bordes inferiores (que tiene bordes inferiores para los diferentes anchos de las cajas). Además, claro, de código HTML extra para mostrarlas. En el ejemplo, aplique lo que se conoce como Progressive Enhacement para reducir el uso de imágenes para módulos de 4 a 1. De hecho, simplificando más aún, podríamos incluso no necesitar imágenes. La idea básicamente es proveer una mejor versión del sitio para aquellos navegadores avanzados. En este caso, los bordes redondeados para los módulos utilizan una propiedad específica de Safari y Firefox (-webkit-border-radius y -moz-border-radius, respectivamente); sin embargo, los usuarios que naveguen con Internet Explorer igualmente podrán disfrutar del contenido y la funcionalidad del sitio. Taringa.net zoomeada 4 veces La página principal de Taringa con zoom x4. Especial atención se puso para que la página y su contenido luzca mínimamente bien (sobre todo legible) al aumentar el tamaño de texto, como pueden ver en la captura siguiente: La nueva propuesta de Taringa.net zoomeada 4 veces El ejemplo de este artículo con zoom x4. El rediseño de Taringa es ahora indestructible y soporta cambios en el tamaño de texto para aquellos usuarios que lo necesiten, aumentando su accesibilidad. Si en el futuro se necesita agregar más opciones en la barra de navegación, llegando a las dos lineas de texto, podemos ver que la caja contenedora no se romperá, aguantando cambios en el texto. Conclusiones Este es un ejemplo rápido sobre como se podría optimizar el HTML y CSS de Taringa para minimizar los costos en servidores. Como extra, se recodificó la página para una mejor semántica y optimización en buscadores. El resultado es una optimización de 50KB a 26KB en el tamaño del archivo HTML, es decir una reducción del 50%. Por cuestiones de tiempo, el ejemplo solamente está probado y funcionando en Safari y Firefox. Pero a los fines prácticos, una implementación para las diferentes versiones de Internet Explorer no agregaría demasiados bytes al resultado final. En números: Sitio actual Sitio propuesto Imágenes 29 6 Tablas 2 0 Tamaño en KB 50 26 BW diario 600 GB 300 GB Gasto en BW diario 600 USD 300 USD Gasto en BW anual 219000 USD 109500 USD Optimización en % 50% Los valores son estimativos. Este enfoque de optimización se puede aplicar a sitios con mucha demanda de servidor. Por ejemplo, Meneame, Fayerwayer, Clarín y La Nación y demás. Fuente http://www.rodrigogalindez.com/archivos/redisenando-taringa/ Las oficinas de taringa por dentro: La evolucion de taringa (como era el primer diseño, los diseños que pasaron antes de tomar el actual de la pagina): Entrevista a los dueños de taringa:

Hola, vuelvo a postear sobre código abap Ahora voy a enseñarles las mejores practicas para codificar en abap, para mejorar asi la performance del programa, performance al acceder a la base de datos y también para prolijidad/legibilidad del código. Veamos de que trata: Primero quiero aclarar a grandes rasgos como es la arquitectura SAP y su ide: 1) En el nivel mas bajo tenemos la base de datos que acompaña la instalación del sistema SAP. La misma puede ser unix, oracle, etc., 2) En segundo lugar tenemos el servidor de aplicaciones, que administra los procesos entre la base de datos y la capa de usuario (que explicaré en el punto 3), 3)La capa de usuario que para nosotros es nuestro ide, pero que puede ser también el entorno de para el usuario final. Rapidamente les dejo un ejemplo: El programador o un usuario final, lanzan un proceso. Por ejemplo el programador hace un select a base de datos o el usuario final ejecuta una transaccion que termina haciendo un select a base de datos. El servidor de aplicaciones administra este pedido a base de datos y luego se hace el fetch o select propiamente dicho. El objetivo de este post es que nosotros, desarrolladores, tratemos de emplear las mejores practicas para que ese acceso a base de datos sea haga de la mejor manera posible para darle la mejor experiencia al usuario. Veamos primero buenas practicas dentro de nuestro codigo: 1) Sentencia SORT: al hacerlo es mejor indicarle al programa los campos criterio para realizar el ordenamiento. Por ejemplo sort it_tab by vbeln posnr. Si no se detalla el sentido por defecto se ordena de manera descendiente. Sino habría que indicar: sort it_tab by vbeln posnr ascending para que sea en orden ascendente. 2) Sentencia LOOP: evitar el uso de cabecera como workarea: Lo mejor es usar loop it_tab assigning <fieldsymbol> ó sino pueden usar loop it_tab reference into ref_area. Sino usar loop it_tab into workarea. Después eviten el where en la iteracion: Loop it_tab assigning <fs> where netwr GT 0. NO!!!! Es preferible hacerlo asi: loop it_tab_assiging <fs>. check <fs>-netwr GT 0. Traten de usar indices para no leer toda la tabla, esto mejora la performance. Por ejemplo ordenen la tabla por un campo y busquen la primera ocurrencia del valor que buscan: sort it_tab by vbeln. read table it_tab transporting no fields with key vbeln = 101010 binary search. if sy-subrc EQ 0. l_index = sy-tabix. loop it_tab assigning <fs> from l_index. ... endloop. endif. Veamos un poco de buenas practicas para acceder a base de datos: 1) Cuando accedan a una tabla en un select mínimo pongan el primer campo clave, sino tienen ese dato hablen con el funcional y traten de buscarle la vuelta, quizas haya alguna tabla secundatia para poder conseguir ese dato o algun truquillo para conseguirlo (piensen antes de escribir, es ahi donde se ve el valor agregado de cada uno). Cuanto mas campos claves completen más rapido se hará la búsqueda. 2) Cuando hacen un select es mejor especificar los campos antes que poner asterisco, si tienen que traer todos los campos úsenlo pero son los menos esos casos, generalmente usamos algunos campos de la tabla luego. 3) Es mejor hace un select into table que varios select single. Es decir, es mejor ir una vez a base de datos y traernos todos los registros que ir varias veces y traer uno solo. Bueno esto es todo por ahora. Tengan en cuenta que estoy hablando a un nivel general y quizás cuando estén codificando no puedan aplicar estos consejos. Tranquilos! son las mejores practicas, si ya agotaron varias posibilidades y no lograron aplicarlas hagan lo menos feo posible entonces Suerte y cualquier cosa me avisan! Saludos!!