Rudy afirma que Psystar existe, y que no es ningún engaño. La razón por su aparente desaparición fue la desbordante demanda de ordenadores que tuvieron, que causó que la compañía que administraba sus pagos con tarjeta de crédito cerrara la cuenta por tener que procesar demasiadas terjetas. Además, dicha compañía les forzó a moverse a un sitio más grande para que pudieran producir sus OpenComputer a gran escala.

El presidente de Psystar también ha afirmado que no están escondiéndose de Apple, sino que sencillamente se han visto desbordados por la demanda. De hecho, asegura que muy pronto podrán volver a aceptar pedidos. Desde mi punto de vista personal, de momento no haría ningún movimiento hasta tener confirmaciones más fiables. Recordemos que la legalidad del OpenComputer con Mac OS X Leopard instalado es bastante dudosa.

Como dicen en Applesfera, yo ya dudo de mi anterior post sobre la empresa que iba a dar ordenadores compatibles con Mac OS X Leopard.

El problema, aparte de todo lo que he copiado (que me perdonen los de Applesfera), es que hay una claúsula básica en este sistema operativo que reza: Solo usar en máquinas Apple.

Es decir, solo puedes usarlo en ordenadores fabricados por Apple, nada de montarte tu clónico e instalar.

Soy más partidario de que Apple ponga su software en todos los ordenadores, sacando versiones específicas.

Aunque algunos crean que no ganarían pasta, yo sé más de uno que directamente compraría el sistema operativo.

Los números no engañan: vale que ganas 1000 euros en cada equipo que vendes, que le incluyes el sistema operativo (-120 euros aprox del total). Como vendes mucho hardware, en plan millones de ordenadores (tanto sobremesa como portatiles) en todo el mundo… generas muchísima pasta.

Ahora cambia tu punto de vista: añade a esa gente el resto del mundo que tiene windows/linux con PC’s que casi seguro que se pasarían a Mac OS X y tendrás el 99% del mercado. Teniendo tus millones de dólares por hard y sumándole otros tantos de venta de software.

Uno de ellos, el estar liado estabilizando un blog con 5000-6000 visitas diarias diferente a Anieto2k.

Fue el propio anieto2k quien me “presentó” a Alex, de AlexSEO y BlogHogwarts, siendo este último un blog de Harry Potter. Su problema era el de siempre: mucha visita y el server inestable totalmente.

Por si fuera poco, ya sabemos todos que Harry Potter tiene muchos fans, este blog está alojado en un VPS (para los no entendidos, una máquina virtual). Con 1 giga de ram y, supongo yo, unos 500-600 Mhz de procesador, sin swap alguna (cosas de la tecnología usada por ese hosting), me decidí a mirar si podía estabilizar de alguna manera ese server.

La instalación era una Ubuntu con LAMP y Ricardo Galli ya había pasado por ahí, cosa que dificultaba mi trabajo. No es que odie o ame a Ricardo, pero reconozco que a veces habla con argumento y con empírica.

Tras varios toqueteos, conseguí ponerle eAccelerator (pues estaba instalado pero no se usaba) y medio configuré unos parámetros en Apache. La cosa estaba estable casi siempre, con valores sobre 5-10 de Load Average. Esto no es un gran elogio, pero la media anterior estaba en 15. El problema era que tenía avalanchas de visitas y hacía que el load se subiera a 50 y agotaba toda la ram. Aquello era impracticable.

Decidí mover ficha con algo que tenía medio pensado para NoPuedoCreer. El objetivo era cambiar la pila de Apache+PHP por algo más manejable. Encontré Nginx, un servidor web muy muy ligero con apenas consumo de memoria creado por un ruso. Aunque la opción más lógica era usar Lighttpd, Nginx tiene como punto positivo que las reglas rewrite que suele usar la gente en Apache funcionen a la primera casi sin tener que tocar nada.

Dicho y hecho. La parte de PHP se soluciona haciendo que se procese con el sistema directamente. Y aquí es donde estriba el cambio radical y fundamental: Apache tiene un módulo que directamente ejecuta las cosas en php en el propio entorno del servidor web, haciendo que se consuma mucha más memoria.

Sin embargo, Nginx se configura para que se pasen las peticiones php al comando del sistema directamente, siendo el sistema operativo el encargado de ejecutarlo y tener control sobre memoria. Aunque algunos me tachen de loco o de ‘are you from the past’, para mejorar el entendimiento entre php y nginx se usa php en modo fastcgi (en las librerias del sistema usa la configuración de CGI).

Me configuré un script ejecutado cada vez que se arranca el sistema que se crean 7 procesos php en fastcgi a la espera que Nginx les pase algo por hacer. Dado que BlogHogwarts estaba en un VPS, tuve que poner un script en el cron que cada día haga un kill de estos procesos y los relance de nuevo (se quedaban colgados) - esto no he tenido que hacerlo con Anieto2k.

Así que simplemente copié la configuración referente a eAccelerator del Apache y lo metí en la configuración CGI de php. Acto seguido escribí las configuraciónes referentes al dominio con las reglas rewrite para Nginx, que podeis consultar en este post.

Paré el apache, y arranqué Nginx con los procesos php ya creados.

Et voilá! Resultado: como mucho, el load se pone en 5, sucediendo esto cuando se postea alguna información relevante y se linkea mucho desde diferentes sites a ese blog. Nginx casi no tiene carga, pues todo lo procesa el php con sus procesos. Generalmente el uso más notable es el de la base de datos, siendo este como máximo de un 40-50% en contadísimas ocasiones, lo normal es un 2-5%. Lleva la máquina sin caerse hace bastantes días, y el consumo de memoria es estable sin llegar a consumirse nunca el total.

En la parte del usuario, se notan 3 cosas: la velocidad en general de la web, que se carga cada página de golpe (antes apache procesaba cosas y esperaba a que los procesos php terminaran y seguía mostrando la web - ahora simplemente se procesa todo en el lado php y se muestra de golpe) y que no hay merma de rendimiento aparente.

Tras esto, decidí hacerlo en Anieto2k, sobretodo tras su puesta en escena del GeekTest, que hizo que nos tumbaran la máquina los de Microsiervos. Así que dicho y hecho, mismo proceso mismos resultados. Siendo la máquina que hostea Anieto2k, Filmclub y este mismo blog una máquina dedicada con Debian, el load rara vez pasa de 0.57 y la base de datos se mantiene entre un 20-40% por culpa de los accesos al GeekTest.

Todos estos blogs estan en wordpress 2.5, cosa que aumenta el consumo de CPU+Memoria. Pero como si no lo notara. Podemos tener avalanchas bestias y la máquina sigue respondiendo, sin perder ápice de configuración o trucos usados ya en php.

Recomiendo a todos los que tengan problemas de load, mucho tráfico y simplemente quieran algo más manejable y rápido, que usen este método.

]]> http://www.arlay.net/2008/04/10/como-consegui-estabilizar-anieto2k-y-bloghogwarts/feed/ http://www.arlay.net/2007/11/27/sale-la-nueva-version-de-wp-supercache/ http://www.arlay.net/2007/11/27/sale-la-nueva-version-de-wp-supercache/#comments Tue, 27 Nov 2007 10:45:13 +0000 Relay http://www.arlay.net/2007/11/27/sale-la-nueva-version-de-wp-supercache/ Ya lo comentaba anieto2k, pero ahora acaba de salir la nueva versión de este plugin para Wordpress con algún que otro bug arreglado.

Habrá que probarlo algún día.

Actualización: Anieto2k ya tiene noticia al respecto.

Tal como comenta anieto2k, ha salido 1BlogrCache que, básicamente, es un mejorado plugin de lo que es WP-Cache (ampliamente conocido en el mundo entero). El tema radica en que la mayoría de gente suele usar directamente eaccelerator (pese a los fieles de APC) y estamos, realmente, cacheando el doble y mal.

Con esto, solo argumentar que igual pierde el sentido tener una aplicación php con base de datos, dado que cada vez que se cachea la página (sobretodo la manera de 1BlogrCache) es básicamente escribir a estático el post. Se supone que tener una aplicación mysql + php es para separar el contenido de la presentación además de hacerlo algo dinámico.

Si empezamos a cachearlo todo, ¿por qué no hacer una aplicación php que simplemente escriba a disco la página estática (con ello decir todas las páginas) directamente?

Si cambiamos el theme, que la aplicación reescriba todas las páginas (dependiendo de las opciones que se guarden en un fichero en la propia raíz o donde sea) usando algoritmos recursivos y punto. O mejor, mantenemos unos apuntadores al theme y solo hay que cambiar esos apuntadores (pueden ser softlinks a los ficheros).

Si hay un comentario nuevo, no problemo… se añade al final del html estático y, así, con todos los posts…

Total (que es lo que cuenta), si con wordpress ahorramos simplemente megas escritos a disco, y luego le añadimos cualquier tipo de caché y lo seguimos tirando a disco… más vale hacerlo directamente desde el principio, por ahorrarnos 400 megas de disco (hoy en día los discos duros son baratísimos).

Así no hace falta ni montar Apache, monto Cherokee y lo sirvo todo estático.

Cual fue nuestra sorpresa (sí, lo hice con más gente delante) al encontrarnos un típico mensaje de error de windows.

Saludos

http://highscalability.com/youtube-architecture

Es un resumen y un video de las charlas técnicas que Google hace cada año sobre como se escaló el sistema que actualmente sirve 100 millones de videos al día a los usuarios.

Totalmente recomendado a los geeks y/o curiosos.

Desde que el fin de semana mudamos anieto2k a mi servidor, hemos venido experimentando lo que es un Load Average alto. Después de varios tests, dejé una configuración un poco absurda para probar. Mientras, seguía hablando con Andrés y quedamos (hacía como 5 años que no nos veíamos - y eso que esto es una isla del mismo tamaño que un pañuelo).

Total, que nos liamos a cervezas y hablando, y terminamos cenando en el mismo sitio. Con muchas cosas dichas y encima de la mesa, nos despedimos. Seguimos hablando via gmail chat, y de golpe… el servidor, el cual tenía monitorizado, se queda de golpe sin ram, sin swap y con load average de 156 (total, el top colgado) y la máquina colgada.

Mandé un ticket para que lo reiniciaran, lo hicieron pero no contestaba al ssh, así que les mande otro ticket para que vieran lo que pasaba y, después de varios mails con los del DataCenter para temas de las ip’s y demás, a las 10 y poco estaba el servidor de nuevo en marcha.

Después de mirar mucho, estamos ante la duda de si hay algo de php mal configurado, he vuelto a cambiar los valores del apache y ahora está como hace dos días. Aguantará por norma lo que se le heche, pero me preocupa que tantas visitas, con el WP-Caché activado, generen tanto load.

Voy a mirarlo y pasar a PHP5, de momento se queda como está. Al menos está sirviendo cosas

Lástima de no habernos hecho una foto, tengo entendido que tiene muchos fans nuestro amigo Andrés jejeje.

Saludos

Despues del trapicheo con mi MB, los de Apple (bueno, no sé exactamente sí eran de Apple o de TNT, puesto que la chica me dijo que me enviaba por mail todos los datos para hacer el envío, incluido el RMA del MacBook) se pusieron en contacto conmigo el miércoles para hacerme la recogida. Hablé con ellos el Lunes 23 de Abril, dado que el Viernes anterior llamé sin tener el equipo delante.

Al hablar con ellos el Lunes, fueron totalmente correctos, abriéndome un caso y pasándome directamente con el servicio Post Venta y me dijeron que me llamarían. Yo andaba algo impaciente, pues la chica del servicio postventa me dijo que me mandaría un numero de caso al mail para pegarlo en la caja del MB (suerte que aún tenía las dos en las que viene).

Como no recibía nada, hablé con Kooma y me dijo que tardaban varios días [las cosas de palacio, que van despacio]. Así fue, el miércoles me llamaban de TNT/Apple, me pasaban por la tarde el susodicho mail (un pdf con 4 hojas - resguardos y demás con RMA incluido) y por la mañana siguiente, léase Jueves 26 de Abril pasaba el repartidor de la compañía para llevárselo - También podría haberlo entregado yo, que me viene medio de paso para ir a mi Universidad. Pero nada mal el trato ni el flujo de las cosas.

Despues de todo, supongo queel Miércoles andará por aquí el nuevo juguetito. Así que mantendré el contacto.

Puse a descargar los CD’s 1 de openSuse (versiones x86 y x86_64 porque no sabía cual iba bien), dado que llevan memtest en el arranque y así darle un par de horas de testeo de memoria (cosa que sugerí a Kooma cuando le pasó). Después de no arrancar el cd esta mañana, miro y veo que hay que instalar una aplicación llamado rEFIt que permite una especie de bios de arranque… bueno, arrancaremos, instalaremos y dejaremos el memtest; me arranca el Mac OS pero al salir el escritorio, vuelve a salir la pantalluca gris oscuro (ya la hemos jodido!!). Reinicio con botonazo, y cuando arranco el safari, se me queda como arrancando, pero se para y ni hace nada. Como si alguna dependencia fallara; y no solo eso, cualquier aplicación se queda tonta, quería actualizar el sistema (es lo primero que hice nada más encender el portatil por primera vez), vuelvo a intentarlo y nada. No puedo hacer nada.

Lo he apagado y tengo que llamar al servicio técnico y que me lo recojan. Lo que me jode es no poder determinar que sea la placa base que tenga problemas (parece más ram, pero a Kooma fue la placa base). A ver si luego por la noche puedo encenderlo.