30
Jan 15

Apache 2.4 con MPM Event, conexiones rechazadas

Hace pocos días que empecé a probar en un entorno real el MPM Event de Apache 2.4 con PHP-FPM.

La configuración por defecto de Apache nunca está pensada para entornos de producción, siempre hay que hacer ajustes. Apache está pensado para “auto-limitarse”, tanto en el número de conexiones, como la ram, etc.. de modo que “nunca” colapsará el servidor. La idea e responder tantas peticiones como sea posible sin utilizar absolutamente todos los recursos del servidor. Así puede convivir con otros sistemas como mysql, php-fpm,…

La idea está bien pero eso requiere de ajustes en cada servidor para que apache utilice todos los recursos que sean posibles, a fin de responder todas las peticiones posibles.

Tras dos días de pruebas, no funciona del todo bien. El problema es que rechaza algunas conexiones.  Aparte de esto, todo funciona bien.

En este servidor tengo unos 350.000 hits por hora. Y rechaza unas 130 conexiones cada hora (de media, aveces más a veces menos, pero nunca 0).

Las conexiones rechazadas fueron aleatorias, nunca es sobre la misma dirección o el mismo tipo de fichero, ya puede ser peticiones a php, jpg, html… es indiferente.

Realicé múltiples ajustes en la configuración de MPM Event, por ejemplo:

<IfModule mpm_worker_module>
# event MPM
# StartServers: initial number of server processes to start
# MaxClients: maximum number of simultaneous client connections
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestsPerChild: maximum number of requests a server process serves

ServerLimit 1024
StartServers 8
MinSpareThreads 75
MaxSpareThreads 250
ThreadsPerChild 25
MaxClients 1025
MaxRequestsPerChild 0
</IfModule>

Hice de todo, subir todos los valores a “lo loco”, ajustándolo según la documentación, etc.. el resultado siempre fue el mismo. No puedo ni decir en que punto mejoró o empeoró. Después de cada cambio le daba unos 30 minutos de control para ver que pasaba, y hacía siempre lo mismo.

En el caso de MPM Prefork tengo la siguiente configuración, que funciona perfectamente:

<IfModule mpm_prefork_module>
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 250
MaxRequestsPerChild 0
</IfModule>

Se supone que MPM Event ya no es experimental, que es estable desde la versión 2.4 de Apache. Pero algo no va bien o falta documentación.

Un gráfico sobre los errores 503 detectados:

mpm-event-mpm-prefork

Seguiré investigando a ver si puedo publicar la solución.

Probé varias configuraciones en un entorno de pruebas. Pero la realidad siempre es diferente. Simular el tráfico real es muy difícil. Y desde luego el servidor no se comportó igual con todas las IP, url, y user-agents… fluctuante que se tiene en un entorno real.

Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.

Mark Zuckerberg


02
Oct 14

Cambios en rewrites en WordPress 4.0 para post_type (cpt)

En la versión 4.0 se hicieron varios cambios en relación a los rewrites, ahora es un poco más fácil de gestionar. Pero para las instalaciones antiguas hace falta un cambio cuando se utiliza post_type.

En la URL:

http://www.example.com/carreras/modalidad/tipo1/subtipo1/mi-carrera

Donde “mi-carrera” es el nombre del post_type que queremos mostrar.

En WordPress 3.9, el rewrite para manejar este post_type sería:

$custom = array(
    'carreras/modalidad/([^\/]+)/([^\/]+)/([^\/]+)/?$' => 'index.php?post_type=carrera&carrera=$matches[3]',
);

En el caso de WordPress 4.0:

$custom = array(
    'carreras/modalidad/([^/]+)/([^/]+)/([^/]+)/?$' => 'index.php?post_type=carrera&name=$matches[3]'
);

Lo que cambia principalmente es el parámetro “name”, antes se buscaba el contenido con el mismo nombre del post_type. Ahora indica el post_type y el contenido como “name”.

Ahora es más claro, el método anterior podía resultar algo confuso.


06
Mar 14

Con smartphones y tabletas se cambio de POP3 a IMAP

Hace muchos años que gestiono servidores de correo para empresas. Y siempre pasaba lo mismo, se configuraba el IMAP y el SSL pero casi no lo se utilizaba, menos de un 10% de los usuarios. Casi siempre utilizaban outlook o similar con POP3 sin ningún tipo de cifrado. Explique muchas veces las ventajas de IMAP y del SSL pero nunca los utilizaban.

Desde que empezaron a utilizar smartphones y tabletas en las empresas esto cambio radicalmente. Primero empezó a utilizarse el SSL en casi todas las conexiones y en los últimos meses, por primera vez, el uso de IMAP es mayor al uso de POP3.

Uso de POP3 vs IMAP 2013-2014

En este gráfico lo verde es IMAP y lo rojo es POP. Lo que es escuro, en los dos colores es el SSL. Se ve como al pasar los meses, lo verde va avanzando hasta ser la mayoría. Aún muchos usuarios utilizan POP3 pero ya son menos del 50%.

Esto es bueno para los usuarios, la seguridad y privacidad, movilidad, etc.. Pero no tan “bueno” para los servidores ahora se necesitan mucho más recursos que antes para atender a las mismas cuentas. El consumo de recursos con POP3 es muy bajo, especialmente si no se utiliza SSL. Pero con IMAP las conexiones se mantienen, lo que incrementa el consumo de ancho de banda, CPU y RAM para menter las conexiones con los túneles de SSL en cada una de ellas.

También aumenta el consumo de espacio en el disco duro. Con POP3 el usuario descargaba los correos a su ordenador cada 10 minutos y el servidor no guardaba nada. Ahora con IMAP el servidor almacena todo, y cada cuenta ahora ocupa barios cientos de MB, y no son pocos los que consumen varios GB.

Todo sea por el progreso!


27
Jan 14

Bloquear actualizaciones en WordPress y sin penalizar el rendimiento

En cada actualización de WordPress puede surgir alguna incompatibilidad. Por este motivo se suele bloquear las actualizaciones para evitar una actualización accidental, o hecha por un usuario que no conoce los detalles de la instalación (osea, el cliente :P)

Existe un código que está muy propagado por internet:

//Disable Theme Updates # 3.0+
remove_action( 'load-update-core.php', 'wp_update_themes' );
add_filter( 'pre_site_transient_update_themes', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_update_themes' );

//Disable Plugin Updates #3.0+
remove_action( 'load-update-core.php', 'wp_update_plugins' );
add_filter( 'pre_site_transient_update_plugins', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_update_plugins' );

//Diasable Core Updates # 3.0+
add_filter( 'pre_site_transient_update_core', create_function( '$a', "return null;" ) );
wp_clear_scheduled_hook( 'wp_version_check' );

Este código funciona pero hay un problema, que empeora el rendimiento de wordpress. Casi multiplica por 4 los tiempos de respuesta.

Sucede porque la función que se crea para engañar al sistema devuelve un valor “null”, así WordPress cree que no hay ninguna actualización. Pero como no sabe cuando se hizo la comprobación ni cual fué la última versión ni nada (porque es un null), vuelve a conectar a wordpress.org para comprobar datos. Es decir, que cada click que se hace en el sitio hace que nuestro WordPress vuelva a consultar a wordpress.org. Una perdida de tiempo.

Un forma más adecuada de hacer este “hack” o bloqueo es la siguiente:

function custom_fake_check_version($a) {
    global $wp_version;
    return (object) array(
        'last_checked' => time(),
        'version_checked' => $wp_version,
    );
}
add_filter('pre_site_transient_update_core',    'custom_fake_check_version');
add_filter('pre_site_transient_update_plugins', 'custom_fake_check_version');
add_filter('pre_site_transient_update_themes',  'custom_fake_check_version');

Es lo mismo que lo anterior, salvo que en lugar de devolver un “null” le estamos diciendo al sistema que la última vez que se comprobó la versión fue “ahora mismo” y que la versión es “la versión actual”. Por lo tanto, WordPress no volverá a consultar ese dato en los servidores de wordpress.org hasta que se eliminen estos filtros.


24
Jan 14

Scripts para probar la autenticación en IMAP, POP3 y SMTP

Hace casi un año escribí estos scripts para probar los métodos de autenticación en el servidor de correo que estaba instalando en ese momento. La idea es crear un fichero de configuración con los datos de usuario y los métodos que se desean probar. Así, de forma fácil y rápida se puede verificar si la autenticación mediante “PLAIN”, “LOGIN”, “CRAM-MD5″, etc…

He publicado el código en git en la siguiente dirección: https://github.com/gabrielperezs/Authentications-tools-for-mail-servers

Funciona de la siguiente forma, es muy simple:

Se crea un fichero con la configuración, como este, lo llamamos example.conf:

# Account to test
username=test@mydomain.com
password=the_account_password
server=mail.example.org
#auth=auto
auth=manual
authtype=PLAIN LOGIN CRAM-MD5 DIGEST-MD5

Se puede indicar el parámetro “auth” como “auto” para que el script detecte automáticamente los métodos de autenticación disponibles. Si se indica como “manual” (tal como el ejemplo) permite indicar los métodos de autenticación que se quiera o los scripts de perl soporten. Depende de los módulos de perl que estén instalados en el systema.

Cuando se ejecuta se verá algo así:

$ perl imap-test.pl ~/example.conf
PLAIN -> mail.example.org (test@mydomain.com): OK - SSL OK
LOGIN -> mail.example.org (test@mydomain.com): OK - SSL OK
CRAM-MD5 -> mail.example.org (test@mydomain.com): ERROR - SSL ERROR
DIGEST-MD5 -> mail.example.org (test@mydomain.com): ERROR - SSL ERROR

Esto indica que los métodos de autenticación PLAIN, y LOGIN funcionan correctamente. Tanto con como sin SSL. Y los métodos CRAM-MD5 y DIGEST-MD5 no funcionan.

Los otros dos scripts (smtp-test.pl, pop3-test.pl) funcionan exactamente igual.


20
Dec 13

Comparativa del Nexus 7 2012 y Nexus 7 2013

Esta es la prueba del nexus 7 2013

wpid-Screenshot_2013-12-16-20-28-30.png

wpid-Screenshot_2013-12-16-20-28-19.png

 

Y este es del 2012

Screenshot_2013-12-16-20-28-37

Screenshot_2013-12-16-20-28-22


16
Oct 13

La insensibilidad en el día mundial de la alimentación

Un vecino de Palma de Mallorca ha tenido la “gran idea” de colocar este cartel en un contenedor. Dudo que un insensible de este nivel sepa que hoy es el día mundial de la alimentación.

IMG_20131016_114041

Es increíble que alguien se tome el trabajo de escribir y pegar esto en un contenedor para llamar CERDO a una o varias personas  que buscan en la basura para poder alimentarse. Para este vecino el problema no está en que la gente tenga que buscar en la basura para comer, no, el problema está en que no limpian después de “comer”.


28
Aug 13

Detectar móvil, tablet o desktop en WordPress

La forma más económica de hacer una web compatible con todos los dispositivos es hacer una maqueta adaptable. Que el mismo diseño, la misma maqueta sea perfectamente navegable en las tres familias de dispositivos.

Cuando hay recursos se suele hacer una maqueta especifica para cada dispositivo. Pero en el mundo WordPress la idea es reducir costes en todo lo posible, por lo que se utiliza solo un theme (maqueta) y esta es adaptable.

Cuando se desarrollan estas maquetas siempre surge algún problema del tipo:

  • “quiero este slider en las tablet y escritorios pero NO en los móviles”
  • “El tamaño de las fotos debe ser menor en movil y tablet que en escritorio”
  • “Los espacios de publicidad deben ser diferentes o deben desaparecer de la versión móvil”

Este tipo de necesidades pueden ser por temas estéticos o técnicos (sobre todo cuando las versiones de escritorio son demasiado grandes y/o pesadas para un móvil).

Por eso hemos hecho un pequeño y simple wordpress plugin para facilitar esta detección, y así generar el html necesario para cada dispositivo. Lo hemos llamado ttt-devices, se llama así porque lo hemos hecho en 33themes.com

Su funcionamiento es muy simple. Solo hay que instalarlo y definir los “if” que hagan falta, por ejemplo:

<body>
<?php if (is_tttdevice('mobile')): ?>
   <h1>Titulo</h1>
   <img src="header-mobile.jpg">
<?php else: ?>
   <h1>Titulo</h1>
   <img src="header.jpg">
<?php endif; ?>
</body>

En la descripción del plugin en la página de wordpress se puede ver en detalle sus funcionalidades, espero que os sea útil.


23
Feb 13

De perfiles, sueldos y formación

El problema en España son los directivos.

Hace tiempo que tenía esta idea en la cabeza pero no estaba seguro si era cierta o no, pero he visto una entrevista a Bernardo Hernández (Product Director en Google) que me ha convencido del todo.

Pregunta: “Yo te preguntaba si hubiera sido posible una empresa como google/facebook en España, tu eres optimista…”

Respuesta: “Insisto en que sería perfectamente posible. La diferencia fundamental que nos separa los emprendedores Españoles y Americanos es la formación técnica. Si haces una lista de los emprendedores que han tenido éxito a los largo de los últimos 15-20 años en los Estados Unidos son todos ingenieros informáticos, todos ingenieros informáticos.  Haces una lista de los empresarios que hemos hecho alguna cosa en España, en el tema de la tecnología, la excepción es el ingeniero informático, casi ninguno.

La entrevista completa, la pregunta es en el minuto 13:

Este hombre lo tiene claro, tiene una amplia experiencia y no solo en Estados Unidos o en el sector tecnológico, por ejemplo trabajó en BBVA en España. También ha creado varias empresas e invierte en otras al mismo tiempo que trabaja en Google.

Sin embargo en España la mentalidad es otra y no parece que vaya a cambiar. Hoy leí un  informe contratado por el gobierno de España con fondos de la UE para conocer los perfiles que se van a necesitar en el futuro en el ámbito de los contenidos digitales.

Perfiles Profesionales más demandados en el ámbito de los Contenidos Digitales en España 2012 – 2017 – Profesionales TIC 2011

En este estudio separan los perfiles en grupos, en el área de “Negocio”, sub-grupo “Estrategia y gestión de negocio” definen al perfil del jefe, del director de la siguiente manera:

Conocimientos financieros, presupuestarios y de economía; Conocimientos generales de todas las fases de la creación y explotación de una publicación; Conocimientos sobre el mercado editorial y de medios de comunicación; Conocimiento sobre tendencias y nuevos modelos de negocio; Conocimientos sobre nuevas tecnologías y social media; Conocimientos sobre marketing, comunicación y publicidad;Nivel avanzado de inglés; Conocimientos sobre gestión comercial de canales, principalmente con los majors (Amazon,Google, Apple).

Sinceramente, dudo mucho que alguien con “conocimientos generales” pueda crear algo como facebook, Adwords, Netflix, etc… por no decir que es imposible. Y además, se da la -casualidad- de que estos perfiles no valoran en absoluto a los perfiles técnicos. Razón por la cual aquí los técnicos tienen salarios bajos, y no es por la crisis, en medio de la burbuja del ladrillo un buen albañil o un buen comercial de calle cobraba más que un buen programador, administrador de sistemas, un diseñador web o diseñador 3d.

Y como muestra esta oferta de empleo de la empresa Habitissimo de aquí de Palma de Mallorca. Recuerdo que en twitter ponían “Habitissimo busca talento“… y si piden talento, porque buscan un perfil con muchos conocimientos, conozco muy poca gente que sepa todo lo que piden. Eso sí, no piensan ofrecer un salario acorde, ofrecen de 18.000€ a 33.000€ al año. Cualquiera que tenga esos conocimientos puede trabajar por su cuenta y cobrar mucho más, así de claro. No encuentro razón alguna para que alguien con esos conocimientos acepte ese salario (el de 33.000€ claro, 18.000€ es una tomadura de pelo en toda regla). Y si alguien se encuentra en esa situación que no tenga miedo y monte un proyecto propio, aunque sea de servicios, solo hace falta ser autónomo y un ordenador. Y a facturar horas de servicios!

Luego dirán que no encuentran personal cualificado, que en España falta formación, que no hay buenos programadores, ingenieros o diseñadores…


10
Jan 13

Efecto menéame

Envié un enlace a meneame.net, a los pocos minutos recibió unos 80 clicks, como era tarde pensé que no llegaría a portada. El post es sobre una nueva ley que sanciona de forma penal el fraude a la Seguridad Social. Lo que me animó a enviarlo fue el comentario final del post, con el que estoy 100% de acuerdo:

Nuevo delito por fraude a la Seguridad Social. Ojo defraudadores!

[…]

Ya era hora que el fraude a todos, porque la seguridad social la pagamos todos…, fuera considerado una auténtica lacra social y una actitud equiparada a graves delitos. Los recursos, escasos actualmente, deben dedicarse, y en mayor cuantía, a los que realmente lo necesiten y perseguir toda situación que utilice fondos públicos para un fin no previsto. Lo realmente triste, serán aquellas situaciones de necesidad que por pura supervivencia, el desempleado que cobra 400 euros de ayuda deba mantener a su familia y se vea obligado a trabajar de lo que sea, lo den o no de alta… es duro pensar que a partir de ahora, esa persona a pesar de poder ser condenado a multas mínimas pase a tener la consideración de delincuente, en el ámbito penal…

José Manuel Raya Sánchez

Como siempre duermo muy tarde, volví a mirarlo a las 2 de la mañana, y apenas llegaba a los 100 clicks. Al día siguiente a las 9h me encuentro con que estaba en portada, y no solo en portada, era noticia destacada! Que alegría!. Justo después de la alegría empezó la preocupación ¿aguantará el servidor el efecto menéame?

Quería compartir los datos. Hace unos meses buscaba información sobre el efecto menéame ¿cuantas visitas? ¿en cuanto tiempo? ¿que tan -fuerte- es? y no encontré mayor cosa. Hace tiempo Enrique Dans escribió en su blog sobre el efecto menéame, su servicio de hosting no aguantó, cito:

El “efecto Menéame”, por ejemplo, fue prácticamente el único responsable del reciente cambio de servidor de este blog a uno dedicado: la caída de calidad de servicio que el blog mostraba los días que llegaba a la portada del Menéame (cinco veces en el último mes) era algo que claramente no interesaba ni a mi proveedor, ni a mí mismo, ni a quienes compartían conmigo el servidor anterior.

En algunas pantallas que muestra Erique Dans indican 1.000 visitas por salir en portada, claro, este post se escribió en el 2008. A día de hoy el efecto es mucho mayor. En este caso fueron 1.941 meneos y 7.890 clicks. Que nuestro servidor aguantase sin problemas este trafico sorpresa es motivo de orgullo sinceramente :)

Así que comparto estas gráficas del momento de más actividad, para aquellos que preparan servidores y quieren datos más concretos del “efecto menéame”.

efecto-mename-request

 

 

 

 

Efecto meneame, conecciones

Lógicamente el efecto menéame puede ser muy variado, hay noticias que tienen 300 meneos y 20.000 clicks. Pero la gráfica ya da una idea del trafico que puede llegar y en cuanto tiempo.

Estoy bastante contento con este caso (por eso publico el post) ya que todo el curro técnico que muchas veces no se valora (porque no se “ve”; optimización de código, test de stress, prueba de configuraciones, caches, actualizaciones, leer, leer, leer…) ahora se ha puesto a prueba y con buenos resultados. Por ejemplo, si esta web tuviera 10 CSS y 10 JS sin comprimir ( Minify JavaScript and CSS), solo con ese detalle, habrían muchos más “request” al servidor, 20 veces más. En los momentos de más tráfico habría superado a los 600 request por segundo.

Espero que la próxima vez que llegue a portada pueda escribir otro post igual de contento ;)