El jue, 07-05-2009 a las 14:19 -0500, Gustavo Picon escribió: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On May 7, 2009, at 1:13 PM, Antonio Ognio wrote: > > El día 7 de mayo de 2009 12:53, Felix Manuel Arismendi Quispichuco > > <[email protected]> escribió: > >> Mira lo único que te puedo decir, es que les por completo el enlace > >> que > >> pasé y que vuelvo a colocar: > >> > >> http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tn012.pdf > >> > > > > De acuerdo. Seguiré tu sugerencia. > > > > A ver, ordenémonos: > > Lo que critiqué de los correos iniciales de Felix fue que mencionaba > entre otras cosas que: > > 1- .NET no escala como otras tecnologías libres > 2- hay benchmarks en los que java escala mejor que php (performance) > 3- la tecnología usada es inherente a la escalabilidad > 4- la escalabilidad es un punto débil de ruby > > Luego pone un pdf ACADÉMICO (bastante interesante) en el que se > menciona que hay 2 conceptos comunes de escalabilidad: > > 1- un concepto limitado usado informalmente, en el que un sistema > escala bien sin necesidad de agregar mas recursos (hardware, nodos o > lo que sea) > > 2- un concepto en el que la escalabilidad se logra agregando > recursos al sistema de una manera razonablemente económica.
El documento explica a saciedad que ambos conceptos son inherentes a la definición de escalabilidad, mas aún en cierta parte de los apendices da a entender que el termino escalabilidad es mas bien amplia ya hasta en cierta manera vago, ya que existen múltiples perspectivas desde las que se puede analizar el tema. Es altamente probable que no te hayas tomado el trabajo de leer el documento en su totalidad incluidas conclusiones y apendices, en el cual se comenta tanto en las entrevistas como en los apendices se señala en que casos lo comentado atañe a uno u otro concepto, ojo jamas descartando, devaluando u minimizando uno en desmedro del otro. "3.1 How Capacity Can Be Increased If we ask whether a system is scalable, we could be asking whether it can handle a “large” workload (Definition 1) or whether the system can be (repeatedly) augmented to handle increasing workloads (Definition 2). So if we ask how to increase the scalability of a system, the answer depends on whether we are considering scalability1 or scalability2. Increasing scalability1 means increasing a system’s capacity to handle a larger workload without adding resources to the system. Typically this is done by tuning the system in some way (e.g., by improving an algorithm, modifying a data structure, or reducing the amount of work the system needs to do by decreasing the services it provides when the system is heavily loaded). Increasing scalability in the sense of Definition 2 means improving the strategy for repeatedly adding capacity to a system, where such a strategy is more or less feasible depending on its cost implications. For any system to be scalable2, the capacity addition must be cost- effective. Cost-effectiveness has to be determined situationally. A large company may not have a problem going to a 32-bit event-ID because the server the system is running on has plenty of disk space. A small nonprofit with limited funds may be unable to purchase a larger capacity disk." > > Si se analiza en serio el asunto, es fácil darse cuenta que el > concepto 1 (el que defiende Felix) NO ES ESCALABLE. Simplemente porque > va a llegar un momento en el que el crecimiento va a llegar al límite > de los recursos del sistema (hardware, red, etc). Si este crecimiento > no se da, perfecto, pero eso NO HACE escalable el sistema. > Remítete al punto 3.1, y claro desde tu perspectiva donde solo se acepta como definición de escalabilidad lo denominado escalability (definición 2) en el documento en referencia, será valida tu aceveración categorica que tal cosa "NO ES ESCALABLE". > Cuál es la solución a una arquitectura pensada con el primer concepto > de escalabilidad cuando se llega al límite del sistema? Escalar > verticalmente, es decir, hacer un "upgrade" o un "reemplazo" al > sistema (que de por si ya rompe con el concepto 1). Esto a la larga > tampoco escala, por un factor económico (por ejemplo, un procesador el > doble de rápido no tiene el doble del precio, normalmente es 4 o mas > veces mas caro). > El detalle es que aquí no esta en cuestionamiento si arquitectura solo u optimización o optimización + architectura, según aplique a un caso especifico, sino la definición de "ESCALABILIDAD". > Cómo se escala a gran escala En La Cancha (no en la Academia)? > Hecha por la borda la academia y terminaremos en la situación triste que se vive en el país, donde prolifera la ignorancia y el conocimiento a medias. "5 Summary and Conclusions The ability or inability of systems (or systems of systems) to deal with issues of scale is becoming increasingly important in DoD and other systems. In studying this problem, we discovered that there was no uniform definition of what constituted a scalable system an omission that we’ve attempted to rectify in this report. We’ve shown that there are actually two common uses of the word scalability: 1. Scalability is the ability to handle increased workload (without adding resources to a system). 2. Scalability is the ability to handle increased workload by repeatedly applying a cost effective strategy for extending a system’s capability. We’ve also shown how those definitions relate to real-world systems, both informally and formally. We were helped in this effort by the results of both a literature survey and interviews with three individuals who have first-hand knowledge of scalability issues of differing magnitude." Entonces veamos como se usan ambos conceptos en el dodumento en referencia: Para la primera interpretación de escalabilidad: "Maggs: You notice that you’ve failed to scale when the system grinds to a halt because you have overloaded the CPU, run out of memory or disk space, or filled a network pipe. These are symptoms of some underlying scalability problem. Perhaps the underlying problem is a poor choice of algorithm. For instance, the bubblesort sorting algorithm works wonderfully up to a point. If the system never reaches that point, then perhaps bubblesort is the right algorithm to be using. However, if it is likely to exceed that point someday, then perhaps quicksort or another alternative would be a better choice. Discussion: This use of scale is consistent with scalability Definition 1, because “failure to scale” refers only to the exhaustion of a resource; it does not address the problems faced when resources are added." Para la interpretación 2: "Maggs: A system fails to scale when you need one more unit of something and you are unable to provide it without using up significantly more than one unit of some resource. Discussion: This comment is related to scalability Definition 2, because it concerns the overhead involved as resources are added." Es de destacar que el documento en ningún momento contrapone una interpretación a la otra, tampoco intenta establecer a ninguna como la única y valedera interpretación al respecto. Este es un aspecto relativo a la escalabilidad que sencillamente se escaparía si nos conformamos con aceptar como valida exclusivamente la interpretación 2, no siendo por cierto que esto esté relacionado con la interpretación 1: Maggs: Small systems can be managed and dealt with by small numbers of people. Large systems require many more people, and truly large systems may require more people than can be hired and trained fast enough. As labor costs go up, profits may also not scale. These kinds of problems are behind the development of so-called autonomic computing. Discussion: This comment refers to an aspect of scalability that is sometimes overlooked the growth in human administrative costs as systems get larger." Extraido del apendice B: "Our review showed that it was not always easy to decide what was meant when the term scalable was used. We began to question every use of the word to see what might be intended. This usually led to greater insight into the issue being addressed, as noted below in our comments on the papers." Abundando mas sobre el tema: (Este enlace aún existe) "http://computing-dictionary.thefreedictionary.com/scalable A ‘highly scalable’ device or application implies that it can handle a large in crease in users, workload, or transactions without undue strain. Scalable does not always mean that expansion is free. Extra-cost hardware or software may be required to achieve maximum scalability [Farlex 05]. Discussion: The first part of this definition focuses on the ability to handle increased demand, without necessarily implying that the system needs to be augmented. This part of the definition agrees with our Definition 1. The latter part of the definition mentions that the cost to increase a system’s capability might be a factor in deciding whether it is scalable. Such considerations are part of our Definition 2." "The author notes that measures of performance depend on underlying problem constraints: The complexity of the underlying problem dictates the best performance that we can hope to achieve with any algorithm. If it is mathematically impossible to evaluate lines of sight among N tanks in less than kN2 time, it is usefulto know that before we attempt to develop algorithms to solve the problem. Discussion: This comment refers to the ability to handle a simulation load independent of the amount of computational capacity available. Hence, is a comment consistent with our Definition 1—performance under increased load without adding resources to the system. In line with thinking that scalability is a matter of understanding resource bottlenecks, the author notes: “scalability is a function of the application, since each application may stress different system resources.” Discussion: The last comment refers to the concept of resource bottlenecks as barriers to allowing systems to do more work. As a result, it seems to be consistent with our Definition 1 the notion of scalability that focuses primarily on how well a system responds to increases in demand without augmenting the system. Alternatively, the comment could be taken as implicitly referring to strategies for increasing the capacity of different system resources, understanding that different strategies may be needed for different resources. Consequently, strategies for making systems scalable (in the sense of Definition 2) are application dependent. The paper also provide an alternative definition of scalability: “the size of the interval in which the ratio between simulation capability and architectural capability remains at least as good as it was for the specified benchmark architecture” (i.e., scalability is with reference to a benchmark and with reference to some measure of system capability)." Tal pareciese que tu enterpretación está demasiado atada al "escalar algo en internet", cuando el tema que se está tratando va bastante mas allá que solo eso. Bueno, luego de haber citado reiteradamente el documento en mención, llamado On System Scalability cuyos autores son: Charles B. Weinstock John B. Goodenough el documento está fechado en marzo del 2006, vuelvo a dejar el enlace, pues veo que algunos solo acostumbran hacer lecturas parciales: http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tn012.pdf A ver si le dan una leida por completo antes de volver a darle mas vueltas al tema. No está demás decir que, en lo que a mi respecta el tema está largamente agotado. Saludos. FMAQ. > Con el concepto 2. Escalando horizontalmente. Diseñando una > ARQUITECTURA que permita un crecimiento agregando nodos. Esto hace que > el diseño de la ARQUITECTURA sea distinto a lo clásico: manejar > sesiones de una manera distinta, denormalizar data, no usar joins, > hacer sharding, federation, etc. Todas estas cosas son TOTALMENTE > INDEPENDIENTES del lenguaje usado. Se puede hacer tanto con java como > con php. > > Es por esto que escalabilidad y performance NO SON SINÓNIMOS. Ambas > son metas importantes, pero en muchos casos, Y COMO EL MISMO PDF QUE > FELIX CITA MENCIONA EN EL PUNTO 2.3, a veces hay que SACRIFICAR > performance para obtener escalabilidad. > > Y por lo mismo que la escalabilidad depende de la arquitectura y no > del lenguaje, un ejemplo sencillo: puedo tener 2 sistemas, uno hecho > en java con el modelo de desarrollo clásico, y uno en php con soporte > de sharding. Lo mas probable es que el sistema con Java sea mucho mas > rápido con una carga de digamos 100 usuarios y 10000 registros. Pero > si crecemos a diez millones de usuarios que generan 50 millones de > registros AL DIA, el panorama cambia. El sistema clásico con Java va a > necesitar un servidor "big-iron" para mantener la carga (si es que la > puede soportar). Con el otro sistema con php solo se agregan nodos. > Cuál escala mejor? Cuál escala de una manera mas económica? > > Vuelvo a poner los recursos que recomiendo para los que en verdad > quieran profundizar mas en el tema (al menos los 2 primeros libros son > algo así como "literatura obligatoria" para escalar algo en internet > el día de hoy): > > - Building Scalable Web Sites[0] > - Scalable Internet Architectures[1] > - The Art of Capacity Planning[2] > > Saludos. > > - - tabo > > > 0- http://oreilly.com/catalog/9780596102357/ > 1- http://scalableinternetarchitectures.com/ > 2- http://oreilly.com/catalog/9780596518578/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.11 (Darwin) > > iEYEARECAAYFAkoDNFYACgkQywoV1jM0SwMmLwCgqxhLagT5SSjJSdjb2pRKU+mB > g5gAnRy1/t+j4c/4Wmay6vtUcw5SaF5Y > =/Az7 > -----END PGP SIGNATURE----- > _______________________________________________ > Lista de correo Linux-plug > Temática: Discusión general sobre Linux > Peruvian Linux User Group (http://www.linux.org.pe) > > Participa suscribiéndote y escribiendo a: [email protected] > Para darte de alta, de baja o hacer ajustes a tu suscripción visita: > http://listas.linux.org.pe/mailman/listinfo/linux-plug > > IMPORTANTE: Reglas y recomendaciones > http://www.linux.org.pe/listas/reglas.php > http://www.linux.org.pe/listas/comportamiento.php > http://www.linux.org.pe/listas/recomendaciones.php > _______________________________________________ Lista de correo Linux-plug Temática: Discusión general sobre Linux Peruvian Linux User Group (http://www.linux.org.pe) Participa suscribiéndote y escribiendo a: [email protected] Para darte de alta, de baja o hacer ajustes a tu suscripción visita: http://listas.linux.org.pe/mailman/listinfo/linux-plug IMPORTANTE: Reglas y recomendaciones http://www.linux.org.pe/listas/reglas.php http://www.linux.org.pe/listas/comportamiento.php http://www.linux.org.pe/listas/recomendaciones.php
