Archivos Mensuales: julio 2013

La política del “todos somos desecho”

Hoy se ha hecho bastante “popular” el caso de la remoción de la inmunidad parlamentaria a un Diputado de la bancada de oposición, acusado de malversación de fondos (aunque al no ser dinero del Estado Venezolano, no sé qué malversó) y evasión de impuestos, ni siquiera defiendo al hombre, si no es evasor, ¿qué teme?, ¿por qué requiere de una inmunidad ante tribunales? …

Pero no vengo a hablar de Richard Mardo, sino, en general … de cómo las leyes se convierten en un “todos somos desecho, a menos que tengamos el poder” …

¿por qué un diputado necesita tener inmunidad parlamentaria?, ¿por qué hay que hacer tantas malabares para poder llevarlos a tribunales? y al tonto de a pie, hasta por poner música a todo volumen lo pueden lanzar 72 horas en una cárcel …

Hay que hacer leyes que “bajen del Olimpo”, a los políticos … (aunque sé que es imposible, las leyes las hacen los políticos de los que queremos protegernos) …

Les contaré …

hace algún tiempo escribí, como no existía el concepto de “justicia ciudadana”, veamos el ejemplo dado hoy por los tribunales norteamericanos en el caso de Bradley Manning, libre, pero de manera condicional, se exponía a 135 años de prisión por haber filtrado 70 mil documentos a Wikileaks (de hecho, no mató a nadie con ello), a principios del año pasado, a Aaron Swartz lo acusaron por filtrar documentos científicos del MIT (donde se encontraban engavetados *papers* tan importantes como investigaciones de proteínas contra el cáncer), la fiscal solicitaba 35 años de cárcel, la presión fue tal, que Aaron Swartz terminó suicidándose.

En el otro lado de la moneda, Jeffrey Skilling, orquestó una elaborada treta de robos y especulaciones alrededor de las finanzas de Enron, como CEO recibió 300 millones de dólares de negociaciones fraudulentas, 217 millones de US$ en negociaciones de acciones, evadió más de 200 millones de US$ de impuestos, para colmo, en asociación con Kenneth Lay, terminaron lanzando “a la bancarrota” a Enron, se perdieron 2 mil millones de US$ en pensiones y jubilaciones, 40 mil millones de dólares más en ahorros e inversiones, afectando *sólo directamente* a más de 2.5 millones de personas (muchas perdieron sus ahorros o sus casas y se suicidaron), Jeffrey Skilling cumple condena de sólo 24 años por el mayor fraude financiero que vivió Estados Unidos en su historia.

… y estos si que mataron a mucha gente! …

Ya lo había indicado una vez, “si usas la informática para *hackear* las cuentas de un político y demostrar su corrupción, según las leyes venezolanas él podría ir preso de 5 a 10 años, tú, por violar la ley de delitos informáticos, irás preso entre 12 a 15 años, ¿vale la pena ser investigador?” …

¿recuerdan aquella investigación contra la piratería en España?, si haces una película porno “casera” y la distribuyes entre menores de edad, vas preso unos 5 años, si “pirateas” una película “para niños” con trademark, copyright, “mirar en su casa sólo con los ojos cerrados”, “no prestar porque te estamos observando”, entonces vas preso 15 años por violaciones al copyright, derechos de autor y piratería … ¿es eso sensato? …

En un par de casos más “terrenales” (de estas tierras, pues), tenemos al ex-director del banco Iraní-Venezolano, preso en Alemania por ingresar con dinero “ilegal”, sin embargo … acá todos “miran para los lados” y nadie se ha pronunciado; o el caso de una funcionaria de Bandes que jugaba al “yuppie” especulando con activos y papeles en USA, y tampoco, no veo a nadie pronunciándose al respecto; o los 175 millones de US$ *desaparecidos* del convenio Cuba-Venezuela para “proveernos” de una *supuesta* cédula electrónica que nadie ha visto, y en fin …

La cosa es, ¿por qué un ser humano, con la responsabilidad de un cargo público, debe sentirse inmune?, ¡al contrario!, debería sentirse “bien expuesto” pues sabe que está en la mira de todo el mundo (tan expuesto como para responder -vía alguna ley de transparencia y declaración de bienes del funcionario público- cómo paga trajes tan costosos Pedro Carreño) , si un médico mata a su paciente, va preso, si alguien se roba una harina de maíz para hacerle arepas a su familia, va preso, pero si el Ministro Giordani afirma que por SITME se perdieron 750 millones de US$ o Tarek El-Aissami indica que por manejos irregulares en la reparación del Teatro de Ópera de Maracay se perdieron 30 millones de Bs ¿hay algún imputado?, del último caso han denunciado formalmente al hermano de Rafael Isea, pero todos *olvidan* que el propio Presidente Hugo Chávez aprobó la remodelación en 2011 y que en Junio del 2012 el propio Rafael Isea afirmó que “estaría listo en diciembre de 2012” ¿no son los gobernadores los que firman y son garantes últimos, de los fondos del Estado?, ¿para esto si no hay diligencia en las investigaciones y contraloria social?, ¿verdad?.

Esto es “normal”, en el sentido que es común a todas las políticas (véase USA, Colombia, Chile, etc), hágase una simple contabilidad, ¿cuántos casos de corrupción le abre un gobierno a los de oposición y cuantos casos “propios” se abren en un período?, y la conclusión ¿por qué es tan fácil meter preso a un ciudadano “de a pie” y es casi imposible enjuiciar o tan siquiera “señalar” a las personas que ostentan el poder? …

En conclusión, ¿quieren *justicia*?, dejen de “defender” a Richard Mardo y entonces exijan las declaraciones juradas de bienes y declaraciones de impuestos de TODOS los diputados de la Asamblea Nacional … me encantaría ver las de Pedro Carreño y ¡como no!, Diosdado Cabello …

Quien no tiene rabo de paja … no le tiene miedo a la candela! …

[Debian] how-to: mezclar arquitecturas

Esta explicación rápida de cómo mezclar arquitecturas e instalar paquetes en Debian, viene de un hilo de discusión, asi que respondo acá.-

Agregando una arquitectura

Para agregar una arquitectura nueva, simplemente ejecutamos:

dpkg –add-architecture [arquitectura: amd64, i386, armel, etc]

Ejemplo, en un sistema de 64 bits, agregar soporte a 32 bits, ejecutamos:

dpkg –add-architecture i386

Luego, actualizamos el repositorio:

apt-get update

Y listo!, ya pueden desde apt instalar paquetes 32 ó 64 bits.-

Instalar un paquete manualemente

Si tuvieramos un .deb (ej: skype, teamviewer) para 32 bits, luego de agregada la plataforma, ejecutamos:

dpkg -i nombre_de_paquete.deb

Si posee dependencias insatisfechas, el paquete no instalará, pero podrás luego reparar esas dependencias insatisfechas con:

apt-get -f install

Y toda librería de 32 bits será instalada

Saludos!

Si yo tuviese una escuela

Una lectura 100% recomendada …

Si yo tuviese una escuela. – por N.J. Figueroa

[Debian] Virtualizando con Xen XCP

En mi blog “Phenobarbital con Soda! 2 – El hereje” he incorporado el primero (de una serie) de artículos sobre virtualización utillizando Xen XCP, la plataforma de computación en la nube de Xen, ahora estable en Debian Wheezy y lista para entornos de producción.

Hago la nota acá pues tengo muchos más suscriptores por este blog y me gustaría recibir más comentarios que vayan retroalimentando y mejorando la entrada.

Próximamente habrá una versión “copy & paste” en el wiki de phenobarbital.info.

 

[apache] benchmark de diversas configuraciones de Apache+PHP

He estado configurando un load-balance de servidores Apache2; claro, usando nginx como proxy reverso, una de las dudas que me saltó durante las pruebas fue:
¿cómo lograr el máximo rendimiento en cada nodo?, y es que, cada nodo de apache2 se ejecuta en una máquina virtual con una ínfima cantidad de RAM, así que, manos a la obra, decidí tomar el control del asunto.

Apache y MPM

Los “módulos de multi-procesamiento” (“Multi-Processing Modules” ó MPM) es como llama apache a sus módulos que procesan las solicitudes.

mpm_prefork: el más antiguo y utilizado por usuarios de PHP, prefork genera procesos de apache con el interprete PHP imbuido (mod_php), es el más sencilo de configurar (apt-get install apache2-mpm-prefork libapache2-mod-php5); sin embargo, prefork tiene el inconveniente de tener que integrar un compilador de PHP en cada proceso, por consiguiente el consumo de recursos ante sitios con alta demanda, es excesivo.

mpm_worker: en worker no sólo se generan procesos, sino que cada proceso puede generar múltiples hilos, al procesar múltiples hilos de manera asincrónica a la vez, podemos consumir menos recursos que levantar un proceso de apache por cada solicitud

mpm_event: es una versión más reciente de worker, los procesos padre generan hilos “principales”, dichos hilos principales pueden “pasar” procesos a hilos hijos (creados por demanda) para asumir nuevas solicitudes, event tiene una característica de trabajo muy parecida al modo asíncrono multi-hilado de Nginx.

Las pruebas:

Hemos instalado el siguiente servidor (una máquina virtual) muy sencilla:

Servidor: Debian Wheezy 7.0
RAM: 512MB
Document Size: 70Kb
CPUs: 1

Usando apache benchmark, con una configuración muy simple:
ab -n 100 -c 50 http://web1.example.net/test.php

Donde test.php contiene un “loop” sencillo y un phpinfo().

He decidido probar las diferentes combinaciones tomando el mejor de 10 resultados.

Resultados (raw)

* apache mpm_prefork + mod_php:

la clásica combinación MPM_PREFORK+MOD_PHP.

Server API: Apache 2.0 Handler

Concurrency Level: 50
Time taken for tests: 37.756 seconds
Complete requests: 100
Failed requests: 14
 (Connect: 0, Receive: 0, Length: 14, Exceptions: 0)
Write errors: 0
Total transferred: 6701286 bytes
HTML transferred: 6674386 bytes
Requests per second: 2.65 [#/sec] (mean)
Time per request: 18877.780 [ms] (mean)
Time per request: 377.556 [ms] (mean, across all concurrent requests)
Transfer rate: 173.33 [Kbytes/sec] received

* apache mpm_worker + php5-fpm + fastcgi:

hemos combinado PHP5-FPM (vía socket, es unos 15% más rápido así que vía TCP, ya que te quitas unas cuantas capas del transporte TCP/IP) + fastcgi (el modo por defecto de configurar FPM, ya que fcgid no permite enviar solicitudes a procesos remotos).

Server API FPM/FastCGI

Concurrency Level: 50
Time taken for tests: 33.945 seconds
Complete requests: 100
Failed requests: 5
 (Connect: 0, Receive: 0, Length: 5, Exceptions: 0)
Write errors: 0
Total transferred: 7714795 bytes
HTML transferred: 7680695 bytes
Requests per second: 2.95 [#/sec] (mean)
Time per request: 16972.487 [ms] (mean)
Time per request: 339.450 [ms] (mean, across all concurrent requests)
Transfer rate: 221.95 [Kbytes/sec] received

Nota: el uso de RAM es muy eficiente usando php5-fpm, nunca consumiendo más de 140MB de RAM.

* apache mpm_worker + php5-cgi + mod_ fcgid:

combinamos mpm_worker con PHP5 en modo fastCGI pero usando fcgid

Server API CGI/FastCGI

Concurrency Level: 50
Time taken for tests: 32.200 seconds
Complete requests: 100
Failed requests: 8
 (Connect: 0, Receive: 0, Length: 8, Exceptions: 0)
Write errors: 0
Total transferred: 7641087 bytes
HTML transferred: 7606987 bytes
Requests per second: 3.11 [#/sec] (mean)
Time per request: 16099.806 [ms] (mean)
Time per request: 321.996 [ms] (mean, across all concurrent requests)
Transfer rate: 231.74 [Kbytes/sec] received

* apache mpm_event + php5-cgi + mod_fcgid:

realizamos la misma combinación, pero sustituyendo mpm_worker por mpm_event.

Server API CGI/FastCGI

Concurrency Level: 50
Time taken for tests: 46.755 seconds
Complete requests: 100
Failed requests: 8
 (Connect: 0, Receive: 0, Length: 8, Exceptions: 0)
Write errors: 0
Total transferred: 7641191 bytes
HTML transferred: 7607091 bytes
Requests per second: 2.14 [#/sec] (mean)
Time per request: 23377.675 [ms] (mean)
Time per request: 467.553 [ms] (mean, across all concurrent requests)
Transfer rate: 159.60 [Kbytes/sec] received

* apache mpm_event + fastcgi + php5-fpm:

La misma combinación de fastcgi + php5-fpm, pero usando mpm_event

Server API FPM/FastCGI

Concurrency Level: 50
Time taken for tests: 35.976 seconds
Complete requests: 100
Failed requests: 10
 (Connect: 0, Receive: 0, Length: 10, Exceptions: 0)
Write errors: 0
Total transferred: 7714787 bytes
HTML transferred: 7680687 bytes
Requests per second: 2.78 [#/sec] (mean)
Time per request: 17987.970 [ms] (mean)
Time per request: 359.759 [ms] (mean, across all concurrent requests)
Transfer rate: 209.42 [Kbytes/sec] received

Nota: se incrementó hasta 400 conexiones con 100 niveles de concurrencia, los valores de conexión y procesamiento se mantuvieron invariables.

 

Las gráficas

… y es que la gente le encanta un gráfico

conexion

El primero representa el tiempo que tarda Apache en recibir una conexión y procesarla, como vemos, aun con pocas solicitudes, prefork se va **adelante** (pues el servidor con solo 512MB de RAM estaba a punto de irse a la SWAP), mientras, mpm_event fue más diligente en conectarse y procesar rápidamente las solicitudes, sin tomar en cuenta cuanto más tardó en transmitirlas.

Ganador: Empate entre MPM-Event+PHP5-FPM y MPM-Event+PHP5-CGI+FCGID

tiempo-total

El tiempo total de la prueba, es lo que tardó Apache desde que se inició el apache-benchmark hasta que se completaron las 100 solicitudes, como vemos (y muy interesante el resultado) event-fcgid fue el peor en el resultado, tardando incluso más que mpm_prefork en conectar-procesar y transmitir resultados, de manera paradójica, la misma configuración pero usando mpm_worker fue la mejor de todas.

Ganador: MPM-Worker+PHP5-CGI+mod_fcgidsolicitud

En general, los resultados fueron parejos, sin embargo, worker-fcgid aparece nuevamente victorioso acá, además, en promedio terminó más solicitudes por segundo (unas 3.11 solicitudes/seg versus 2.9 de worker-fpm).

Ganador: MPM-Worker+PHP5-CGI+mod_fcgid
transfer-rate

 

La velocidad de respuesta, o rata de transferencia de los datos desde el servidor hacia el cliente, es también muy importante, como vemos, Worker-fcgid aparece con una velocidad más alta que el resto.

Ganador: MPM-Worker+PHP5-CGI+mod_fcgid

… ¿Y por qué no Nginx?

Con un conjunto de VPS, uso de .htaccess, facilidad de implementación de instalaciones adaptadas a apache2, en uso de apache2 es *casi* que una obligación en el proyecto que estoy realizando, sin embargo, es más que notable la diferencia de Nginx+PHP5-FPM versus el resto de configuraciones.

Pero para este caso en particular, necesitaba apache2.

Las conclusiones

Es precipitado adelantarse a dar ganadores sin explicar para qué se podría utilizar cada combinación, por ejemplo, mpm_prefork se muy sencillo de configurar y para sitios web con muy pocas visitas y si el recurso no es problema, con APC (o xcache) más mod_deflate+mod_expires puede superar a cualquiera de las configuraciones actuales.

Para sitios web con muchísimo tráfico y tiempos de respuesta cortos, es obvio que MPM-Worker+PHP5-CGI+mod_fcgid podría rendir mejor que cualquier otra combinación (MPM-Event+PHP5-FPM+FastCGI podría ser una segunda opción); sin embargo, hay que recordar que mod_fcgid no permite llamar procesos externos (como PHP5-FPM).

PHP5-FPM aparece como una buena opción (en conjunto con MPM-Worker, aunque mejores números, MPM-Event suele consumir más recursos como RAM y CPU que Worker) para pequeños servidores con bajos recursos, PHP5-FPM es bastante óptimo (durante las pruebas Apache+PHP-FPM+todo el sistema operativo no consumían más de 150MB de RAM), además la posibilidad de “compartir” el proceso PHP5-FPM con otras instancias (de apache o de nginx) tanto en el servidor como en otros servidores, nos brindan un ahorro notable de recursos.

La gran sorpresa de la noche fue mpm_event, tal vez me faltó algún detalle de configuración, sin embargo, ver que MPM_EVENT consume más recursos que mpm_worker y además, no rinde mejor que este … me hace dudar de implementarlo con PHP.

A %d blogueros les gusta esto: