El Lunes, 1 de Septiembre de 2008 04:26, Alejandro Vargas escribió: > El día 31 de agosto de 2008 0:09, Herr Groucho <[EMAIL PROTECTED]> > escribió: > >> Bueno, pero dijiste que actualmente la descarga se hace > >> secuencialmente, ¿no? > > > > No. Actualmente se abren todas las conexiones simultáneas que > > haga falta, hasta un límite configurable. > > Una cosa es tener abierta la conexión y otra cosa es pedirle a > todos que transmitan al mismo tiempo o ir uno por uno > interrogándolos y pidiéndoles datos. Pueden estar todos conectados > pero no transmitiendo.
Es lo que hay ahora, y como bien decís "es otra cosa" y por eso estamos hablando: no suena bien tener 10000 conexiones inactivas casi todo el tiempo que sería lo que obtendríamos de dejar el sistema operando como está diseñado ahora al llevarlo a 10000 puntos. > > Es impresindible obtener los datos al mismo tiempo. Eso no quiere > > decir que no se los pueda tener disponibles hasta unas pocas > > horas después de tomados, en tanto hayan sido tomados al mismo > > tiempo. > > Bueno, entonces te da lo mismo que tarden 5 o 10 minutos más o > menos en comunicarse para transmitirte la información. Correcto, da lo mismo que el retardo para tener el dato en el sistema fluctue 5 o 10 min, en tanto la velocidad promedio de lectura sea tanto o más alta que la velocidad de generación de los datos. > Bueno, pero insisto... a ver, cuánto tiempo puede llegar descargar > los datos de cada uno. > Si podés disponer hasta de una hora para > tenerlos todos, digamos que sería deseable tenerlos en menos de > media hora. > > Entonces, 10000/30 = 333, o sea que deberías poder > atender a 333 por minuto, ya sea al mismo tiempo o secuencialmente. > O sea, que si el sistema es capaz de descargar toda la información > necesaria en un minuto, y de atender a 333 al mismo tiempo, en > media hora tendrías descargado todo lo que te hace falta. No entendés. Mientras me tomé media hora para traer 1 bloque de datos de cada módulos, se generaron 30/5=6 bloques de datos nuevos en cada módulo, que me va a llevar más de media hora leerlos y así cuesta abajo. > De ahí para arriba, cualquier mejora de esos valores que podás > hacer te va a dar más márgen de seguridad para crecer o afrontar > poblemas que pueda haber (por ejemplo ancho de banda reducido por > fallas del proveedor, o paquetes perdidos por problemas de > comunicaciones, o que tengas que hacer algún proceso pesado que > reduzca la velocidad de respuesta, o que aumente la cantidad de > datos a transmitir, nunca se sabe, es mejor tener un margen. El problema típico es que se pierda enlace con algún módulo y cuando vuelva a estar en línea haya que traer datos atrasados. > Si encontrás la manera de que no se comuniquen todos al mismo > tiempo, sino que te vayan llamando de a poco, digamos de a unos 300 > o 400 por vez, y los atendés en un minuto o menos, yo creo que los > números te cuadrarían. Como expliqué, aunque nadie se quejaría por tener los datos 1 hora después de obtenidos, no puedo tomarme una hora en leer los datos: la velocidad de lectura de los datos tiene que igualar o superar la velocidad de obtención de los mismos. Lo que puedo hacer es atrasarme en leer un módulo 1 hora, siempre que siga leyendo datos de algún otro módulo a razón de 10000 cada 5 min. Si el módulo ya está conectado, puede demorar entre 7 y 12 segundos (casi siempre menos que 10) leerle un bloque de datos cuando el factor limitante no es la potencia de cómputo del servidor o el ancho de banda del caño. Luego el tiempo de lectura es lineal en función de la cantidad de bloques. 10000/(300/10)=333 conexiones simultáneas. De pedo te dio el mismo valor. Supongamos 400 para tener margen para recuperarse de fallas. -- Herr Groucho ID Jabber: [EMAIL PROTECTED] Señal distintiva: LU5MJR - 144,550 MHz FM. Clave pública GPG: hkp://pks.lugmen.org.ar Fingerprint GPG: B7BD 0FC7 D9A2 66F3 4EFC 45EE 7DE2 3932 597B 6354
