Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Morir de éxito

SegFault's Diary
Por SegFault
departamento hacer las cosas bien sale caro , Sección Diarios
Puesto a las Mon Jan 13th, 2003 at 03:50:34 PM CET
A raíz de los problemas que está pasando KDE-Look, he recordado lo que le pasó también a Segfault.org y a otros sitios (Kuro5hin ha estado varias veces ha punto de cerrar) y me planteo qué posibilidades tienen los sitios amateurs cuando tienen un éxito que desborda sus posibilidades. Hoy en día gracias a la banda ancha es relativamente sencillo montarse un sitio casero como LibreXpresion.org que puede cumplir muy bien su cometido pero ¿qué ocurre cuando el éxito hace que la capacidad de la máquina o (lo que ocurre en la mayoría de los casos) el caudal de Internet no es suficiente? Los servicios de hosting no son especialmente baratos, y si tienes que soportar algún aumento inesperado de tráfico, puede resultar muy doloroso. Quizá utilizar una red de répiclas pueda ser una solución para algunos sitios, especialmente de descargas, pero para lugares como este ¿existe alguna solución que no afecte al bolsillo de la persona que desinteresadamente ofrece un servicio?

 


< Conferencia de Árpád Gereöffy, de MPlayer (11 comments) | Reactivación del grupo de traducción al catalán del Proyecto GNU (5 comments) >
Enlaces Relacionados
· Kuro5hin
· problemas que está pasando KDE-Look
· Segfault.org
· LibreXpresion.org
· aumento inesperado de tráfico
· More on SegFault's Diary
· Also by SegFault

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Morir de éxito | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
Distribuído (4.00 / 1) (#12)
por suy (suy21.existe-en.lycos.es) a las Thu Jan 16th, 2003 at 12:56:31 AM CET
(Información Usuario) http://lacurva.net/

La solución, no pensando en el presente, ni siquiera en el futuro cercano, es que la información quede distribuída entre los clientes. Algo así como una red p2p. Pensad que en edonkey hay algo así como 2 terabytes de información (o eso aseguraba alguien en una firma que vi). Si toda esa información queda replicada entre todos (que no sería mucho espacio comparado con un divx), y el ancho de banda repartido (que seguiría siendo bajo, en comparación con lo que chupa un edonkey), se podría tener un weblog muy chulo, muy rápido...

Una buena solución momentánea, es cambiar el formato de la presentación. Estoy convencido que se puede ahorrar hasta un 20% en el peso de la página si se usan hojas de estilo, en vez de esas horribles tablas, y elementos font.

Y otra solución más (momentánea), es buscar algun espónsor, y poner algún banner incluído en la página. Eso, y soluciones técnicas (como las que se han comentado) que yo no soy capaz de llegar a entender.


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere


No puedo hablar por todo escomposlinux (3.00 / 1) (#13)
por gonzotba a las Thu Jan 16th, 2003 at 11:28:26 AM CET
(Información Usuario)

Pero creo que antes que tener que depender de banners y de financiación extra (al margen de la que quieran aportar los voluntarios de escomposlinux en la medida de las posibilidades de cada uno) se intentaría buscar por todos los medios un medio técnico que resolviera el sistema. Precisamente ahí está el reto en el que se basa la filosofía de ecolnet.

Si no se pudiera resolver, probablemente Libertonia moriría de éxito. En todo caso, aunque una gran pérdida, sería una digna manera de mantener los ideales y la integridad del proyecto, que al fin y al cabo es lo único que al final nos queda. Somos modestos pero consecuentes con los principios que nos mueven.

Esa es, claro, mi impresión personal. Pero no creo que los demás difieran mucho.

Un saludo!

[ Padre ]


Así es (3.00 / 1) (#14)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Thu Jan 16th, 2003 at 12:18:50 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

La declaración de escomposlinux es en ese punto es diáfana.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


Me parece genial (none / 0) (#16)
por suy (suy21.existe-en.lycos.es) a las Fri Jan 17th, 2003 at 01:03:56 AM CET
(Información Usuario) http://lacurva.net/

Me parece genial lo que habéis dicho. Si hay que cerrar por defender los principios, habréis demostrado una vez más lo nobles que sóis.

De todas formas, antes de que pase, avisad, porque seguro que os salen apoyos de mucha gente. Almenos, aquí podéis contar con uno O:-)


Esto será mi vida, porque es lo único importante en ella.
Y, si fracaso, moriré, porque para mí no existe nada más.

Raistlin Majere
[ Padre ]


Nada de cerrar (none / 0) (#17)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Fri Jan 17th, 2003 at 11:32:24 AM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

En todo caso, todo iría más lento. O nos buscaríamos algun sistema para "distribuir" la carga, aunque fuera un poco "incómodo". Desde luego que pienso aprovechar todo el ancho de banda que le pago a mi proveedor de ADSL. ;-)

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


mod_gzip (4.00 / 1) (#18)
por sinner a las Fri Jan 17th, 2003 at 10:43:34 PM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Hola,

Siguiendo los RFCs, hay un módulo para apache que se llama mod_gzip que es libre HDYS.

Lo que hace es comprimir el contenido antes de enviarlo al navegador, con lo que, a cambio de un mínimo uso de la CPU, acelera el envio de contenidos y disminuye el ancho de banda.

Yo lo tengo en la intranet y la peña alucinaba de lo rápido que era.

Por ejemplo, usando el phpMyAdmin, el rendimiento es notablemente superior. El jefe cree que le he dado el pego y he cambiado el P-II por un dual athlon con 1 GB de RAM o algo.

Las únicas pegas que tiene el mod_gzip osn:

- no todos los navegadores "antiguos" soportan el RFC plenamente

- no funciona en SSL.

A ver si esto ayuda!


Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Es una solución (momentánea) (none / 0) (#19)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Sat Jan 18th, 2003 at 12:11:30 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Puede ayudar durante a mantener el crecimiento un tiempo más, pero me temo que es sólo una solución parcial. :-/

Habrá que explorar algo más en la línea de lo que propone iarenaza (no en vano es el maestro BOFH). ;-)

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


 
Si y no (3.00 / 1) (#1)
por trukulo (mzv-at-menta-dot-net) a las Mon Jan 13th, 2003 at 03:59:45 PM CET
(Información Usuario) http://mercurio.homeip.net

Me explico. Haberla hayla, pero puede costarle todo el éxito que había cosechado.

La solución pasa por que sólo puedan entrar en el sitio usuarios registrados, y no permitir más registros nuevos hasta que haya un descenso significativo del número de miembros.

Problema, se puede perder todo el interés que tenía el que usuarios anónimos pudiesen participar.

Y muchos más que se me ocurren, pero voy a currar que ya he estado escribiendo mucho hoy.


Miguel Angel Zarza.
Aka trukulo.
email: trukulo(at)menta(dot)net
jabber ID: trukulo(at)bulmalug(dot)net
web: http://mercurio.homeip.net


 
Ya me gustaría encontrarla (none / 0) (#2)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Mon Jan 13th, 2003 at 04:41:23 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Si sabes una solución, no dudes en hacérnosla saber. Mientras tanto, iremos pensando en algo (¿BD distribuida? ¿caché de BD?).

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson


Creo que ya lo hemos hablado alguna vez (5.00 / 1) (#5)
por iarenaza a las Tue Jan 14th, 2003 at 01:44:33 PM CET
(Información Usuario) http://www.escomposlinux.org/

Asi que ahi va de nuevo.

La idea es replicar. Pero no solo los servidores web, sino tambien la base de datos. El truco aqui es que del 100% del trafico de la base de datos, el 90-95% son lecturas (ojo, digo trafico en volumen de bytes, no en numero de cosultas) y el 5% son escrituras/actualizaciones.

Esto nos permite, previa adaptación del software, el siguiente esquema:

* Una base de datos maestra que recibe las consultas de insercion/actualizacion/borrado, unicamente.

* Varias bases de datos secundarias, que se replican automaticamente desde la maestra, que reciben el trafico de lectura. Generalmente estaran en el mismo servidor que el servidor web, para que todo el trafico sea local y no consuman ancho de banda externo.

* Servidores web asociados a dichas bases de datos secundarias. Todas las consultas de lectura van contra su base de datos secundaria asociada, y todas las actualizaciones van contra la base de datos maestra.

Por supuesto todo lo anterior supone parchear de arriba a abajo las soluciones existentes (scoop, slash, *nukes y demas), pero creo que es la mejor forma de escalar cuando solo dispones de enlaces de baja capacidad, pero potencialmente muchos.

Saludos. Iñaki.

[ Padre ]


La posibilidad de replicar las BD (none / 0) (#6)
por SegFault (segfault tiene un Mailbox en frenopatico punto net) a las Tue Jan 14th, 2003 at 07:32:17 PM CET
(Información Usuario) http://www.frenopatico.net/segfault

¿Cada cuanto tiempo deberían replicarse las BD? Realmente es eficiente. Te lo digo porque no tengo experiencia, pero no se si sería muy eficiente en sitios en los que la participación (la escritura) es muy alta (y se supone que a medida que más visitas hay más escrituras habrá), sin contar que en cada visita se actualizan contadores de visitas, comentarios vistos, etc (pienso en slash y en scoop) con lo que no estoy muy seguro de que unas réplicas periódicas sean la mejor forma, ya que además no se cuanto ancho de banda consumirían, imagino que serán incrementales, pero no lo se :-?

[ Padre ]


La replicacion es en tiempo real (none / 0) (#9)
por iarenaza a las Wed Jan 15th, 2003 at 12:59:05 PM CET
(Información Usuario) http://www.escomposlinux.org/

No son replicas hechas con rsync, mirror u otros protocolos externos, sino que se usa el propio mecanismo de sincronizacion de la base de datos (MySQL tiene, Postgres tiene, etc).

En el caso de MySQL, cada operacion de escritura en la BBDD maestra se escribe en una especie de fichero de log (similar a la tecnologia de las transacciones) y dicho fichero se va leyendo en tiempo real por el proceso de replicacion y aplicando los cambios en las BBDD esclavas.

De ahi que mientras tengas algo de ancho de banda para aplicar dichos cambios segun se van produciendo, las BBDD secundarias estan casi al dia de forma continuada.

Saludos. Iñaki.

[ Padre ]


Imagino (none / 0) (#10)
por SegFault (segfault tiene un Mailbox en frenopatico punto net) a las Wed Jan 15th, 2003 at 02:19:15 PM CET
(Información Usuario) http://www.frenopatico.net/segfault

Ya sabía que serían con los mecanismos de cada base de datos (por eso puse el enlace a la documentación de replicación de MySQL, la BD utilizada por la mayoría de aplicaciones web, creo :) ). Además, creo que hacer una réplica con rsync de una base de datos funconando no termina de ser una BuenaIdea(TM) :).

Creo que el principal inconveniente de replicar la base de datos es el que mencionas de modificar las aplicaciones para que las consultas las hagan de una BD y las escrituras en otra distinta. Además tiene más ventajas como que en caso de que la BD central caiga, la aplicación seguirá funcionando en sólo lectura, que es más que nada :-) Y para comunicarse, suponiendo que el proceso de replicación de la BD no utilice ninguna compresión, pueden utilizarse túneles con compresión (¡que pesadito el niño!).

[ Padre ]


 
Piranha? (none / 0) (#7)
por sinner a las Wed Jan 15th, 2003 at 02:46:37 AM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

¿Habals de algo parecido a Piranha?

A ver esto:

Una única IP, que es el "router" de tráfico. El router, va dirigiendo el trafico entrante, con RoundRobin, a los diferentes servidores clusterizados via subnet interna. Los servidores clusterizados, responden a la petición del gateway por la red externa.

El sistema es transparente para los usuarios.

El "truco" está en la replicación de la base de datos.

Avisadme si montais algo, que estube testeando unas configuraciones de Piranha y creo que me acuerdo lo suficiente para atreverme a causar un kernel ooops.... digooooo para atreverme a ayudar :)



Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Me temo que no (none / 0) (#8)
por jcantero (jcantero@agujero-negro.escomposlinux.org) a las Wed Jan 15th, 2003 at 12:22:55 PM CET
(Información Usuario) http://www.escomposlinux.org/jcantero/

Porque lo que se intenta es "distribuir" el uso del ancho de banda, mientras que piranha lo "centraliza". La máquina que corriera piranha recibiría la suma de todos los tráficos, y en realidad éste no se reduciría tampoco en las máquina s destino que tuvieran los servicios, salvo que se replicaran -y el problema está en replicar precisamente-.

--
"Papá, ¡Internet es más que una red pornográfica global!" -- Lisa Simpson
[ Padre ]


 
Una posibilidad (none / 0) (#3)
por SegFault (segfault tiene un Mailbox en frenopatico punto net) a las Mon Jan 13th, 2003 at 05:23:47 PM CET
(Información Usuario) http://www.frenopatico.net/segfault

No tengo ninguna experiencia en la solución, pero se me ocurre pensar que quizás tener la BB.DD. en una conexión (ADSL) cuasi-dedicada y varios servidores web que conecten a la BD conectando túneles con compresión (gran parte de la transferencia de la BD a la aplicación web será texto sencillo). Si la aplicación web tiene algún sistema de cacheado (o de página estáticas) podría ganarse bastante. Luego sólo necesitas algún sistema de redirección desde las páginas (creo que podría implentarse con mod_rewrite o pedirle a Akamai que libere su soft :) ).

Repito, que no tengo ni idea de si sería útil, de si sería muy complejo o de si no sirve para nada, pero es la primera idea que se me ocurre.

[ Padre ]


Pues no estaba tan bien pensada (none / 0) (#4)
por SegFault (segfault tiene un Mailbox en frenopatico punto net) a las Tue Jan 14th, 2003 at 12:08:33 PM CET
(Información Usuario) http://www.frenopatico.net/segfault

Como solución no es tan buena (o tan sencilla) porque las URLs enlazarían al sitio de réplica en vez de al 'original', de forma que tendría que hacerse un balanceo en las DNS (cosa no del todo fácil me temo) o bien otra solución sería que los servidores de réplica también tuvieran un mod_rewrite para hacer una redirección, y que todos los servidores de réplica tengan la misma configuración.

En Barrapunto, rvr@infoastro@com comenta la opción de utilizar housing u otra modalidad de alojamiento compartido con otros proyectos para repartir costes. Imagino que también sería una opción, creo que parecida a lo que hace SinDominio.

[ Padre ]


 
Os dice algo la palabra edonkey para web (none / 0) (#11)
por LINO FUN a las Thu Jan 16th, 2003 at 12:14:48 AM CET
(Información Usuario)

Seria posible compartir ancho de banda entre webs?



El problema no es el ancho de banda solo (none / 0) (#15)
por iarenaza a las Thu Jan 16th, 2003 at 03:11:02 PM CET
(Información Usuario) http://www.escomposlinux.org/

Edonkey funciona porque los contenidos son estaticos. Si los contenidos estuviesen cambiando en cada conexion, en cada visita, simplemente no funcionaria. Edonkey funciona porque si te falta un trodo de lo que quieres descargar, el mismo trozo, identico, esta en varios sitios, y puedes tirar de uno cualquiera de ellos (o de varios a la vez).

Con contenidos dinamicos, eso deja de funcionar, ya que no todos los trozos son iguales (a menos que repliques en tiempo real, con lo cual venimos al problema original y edonkey deja de servir como solucion).

Saludos. Iñaki.

[ Padre ]


 
Morir de éxito | 19 comentarios (19 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda