PHP factor 30 diferencia de rendimiento de Linux a Windows

Nuestro equipo está trabajando está desarrollando plugins de WordPress y proporciona instancias alojadas en un par de servidores independientes. Nuestra instalación de WordPress es administrada por Git, todos los servidores tienen la misma fuente y configuración de WordPress implementada, solo los dominios y los datos reales en la base de datos varían. Para cada instalación, MySQL se ejecuta en el mismo host. WordPress se ejecuta exclusivamente en cada servidor.

Sin embargo, después de haber implementado esta configuración en un Windows Server 2008 RC2, notamos una drástica diferencia de rendimiento en comparación con nuestros otros servidores: el tiempo de generación de páginas aumenta desde el promedio. 400ms a 4000-5000ms para páginas generadas con PHP. Para los recursos estáticos entregados solo por Apache, la velocidad es aproximadamente la misma que en Linux.

Así que tomamos algunas medidas para reducir el problema:{[17]]}

1. Asegúrese de que no haya software antivir en ejecución u otros elementos del dominio de Windows que interfieran
2. Recopilar datos de perfiles para identificar los temporizadores durante el script ejecución
3. Pruebe diferentes configuraciones de servidor y hardware
4. Revise la configuración de Apache y PHP para ver si hay errores obvios de configuración

Después de algunos perfiles rápidamente notamos que la evaluación de expresiones regulares es terriblemente lenta en nuestras máquinas windows. Evaluar 10.000 expresiones regulares (preg_match) toma alrededor de 90ms en Linux y 3000ms en Windows.

Los perfiles, las pruebas del sistema y los detalles de configuración se proporcionan a continuación. no queremos para optimizar este script(que sí sabemos hacer). Queremos que el script se ejecute aproximadamente a la misma velocidad en Windows que en Linux (dada la misma configuración con respecto a opcache/...). No hay necesidad de optimizar la huella de memoria del script también.

Actualización: Después de algún tiempo, los sistemas parecen quedarse sin memoria, lo que desencadena excepciones de memoria y asignaciones aleatorias. Ver abajo para más detalles. Reiniciar Apache / PHP solucionó el problema por ahora.

Traza a _get_browser is:

File (called from)
require wp-blog-header.php (index.php:17)
wp (wp-blog-header.php:14)
WP->main (functions.php:808)
php::do_action_ref_array (class-wp.php:616)
php::call_user_func_array (wp-includes/plugin:507)
wp_slimstat::slimtrack  (php::internal (507))
wp_slimstat::_get_browser (wp-slimstat.php:385)

Actualización 2 : Alguna razón por la que no recuerdo que volvimos a activar PHP como un módulo Apache en nuestros servidores (el mismo que ofrece un mal rendimiento). Pero hoy corren increíblemente rápido (~1seg / request). Agregar Opcache reduce esto a ~400ms / req. Apache / PHP / Windows se mantuvo igual.

1) Perfiles de resultados

El perfilado se realizó con XDebug en todas las máquinas. Por lo general, solo recogimos unas pocas carreras, esas fueron suficientes para revelar la ubicación donde se pasó la mayor parte del tiempo (50%+): el método [get_browser][1] del plugin de WordPress wp-slimstats:

protected static function _get_browser(){
    // Load cache
    @include_once(plugin_dir_path( __FILE__ ).'databases/browscap.php');
    // browscap.php contains $slimstat_patterns and $slimstat_browsers

    $browser = array('browser' => 'Default Browser', 'version' => '1', 'platform' => 'unknown', 'css_version' => 1, 'type' => 1);
    if (empty($slimstat_patterns) || !is_array($slimstat_patterns)) return $browser;

    $user_agent = isset($_SERVER['HTTP_USER_AGENT'])?$_SERVER['HTTP_USER_AGENT']:'';
    $search = array();
    foreach ($slimstat_patterns as $key => $pattern){
        if (preg_match($pattern . 'i', $user_agent)){
            $search = $value = $search + $slimstat_browsers[$key];
            while (array_key_exists(3, $value) && $value[3]) {
                $value = $slimstat_browsers[$value[3]];
                $search += $value;
            }
            break;
        }
    }

    // Lots of other lines to relevant to the profiling results
  }

Esta función similar a la de PHP get_browser detecta las capacidades del navegador y el sistema operativo. La mayor parte del tiempo de ejecución del script se gasta en este bucle foreach, evaluando todos esos preg_match (~aproximadamente 8000 - 10000 por solicitud de página). Esto toma alrededor de 90ms en Linux y 3000ms en Windows. Los resultados fueron los mismos en todas las configuraciones probadas (la imagen muestra datos de dos executions):

Claro, cargar dos matrices enormes lleva algún tiempo. Evaluación de expresiones regulares también. Pero esperaríamos que tomaran aproximadamente el mismo tiempo en Linux y Windows. Este es el resultado de la generación de perfiles en una máquina virtual linux (solo una solicitud de página). La diferencia es bastante obvia:

Otro asesino del tiempo fue en realidad el Objeto-Caché WordPress utiliza:

function get( $key, $group = 'default', $force = false, &$found = null ) {
    if ( empty( $group ) )
        $group = 'default';

    if ( $this->multisite && ! isset( $this->global_groups[ $group ] ) )
        $key = $this->blog_prefix . $key;

    if ( $this->_exists( $key, $group ) ) {
        $found = true;
        $this->cache_hits += 1;
        if ( is_object($this->cache[$group][$key]) )
            return clone $this->cache[$group][$key];
        else
            return $this->cache[$group][$key];
    }

    $found = false;
    $this->cache_misses += 1;
    return false;
}

El tiempo se pasa dentro de esta función en sí (3 script executions):

En linux:

El último verdadero gran asesino fueron las traducciones. Cada traducción, cargada desde la memoria, toma cualquier cosa de 0.2 ms a 4ms en WordPress:

En linux:

2) sistemas Probados

Para asegurarnos de que la virtualización o Apache afectan esto, lo probamos en varias configuraciones. Antivir fue desactivado en todas las configuraciones:

• Linux Debian, Apache 2 y PHP en versiones estables actualizadas. Esto es lo mismo para los desarrolladores que se ejecutan en sus máquinas virtuales que para los servidores staging/live. Actuar como un sistema de referencia de rendimiento deseado. Ya sea en nuestra oficina o en algún alojamiento proporciona (espacio compartido). Los sistemas Windows tenían entre 4GB y 8GB de RAM, en todo momento el uso de memoria era inferior al 50%. Las virtualizaciones nunca ejecutan Windows y Apache al mismo tiempo.
• Servidores de vida, que se ejecutan en T-Systems (servidores virtualizados administrados), en Reproductor de VMware
  • Win 2008 R2. Apache 2.2.25 + PHP 5.4.26 NTS, VC9 como módulo fastcgi
  • Win 2008 R2. Apache 2.2.25 + PHP 5.5.1 NTS, VC11 como módulo fastcgi
  • Win 2008 R2. Apache 2.2.25 + PHP 5.5.1 NTS, VC11 como módulo apache
  • Win 2008 R2, Apache 2.2.25 + PHP 5.5.11 TS, VC11 como módulo apache (ese es el rápido que mencioné en la actualización 2)
• En una máquina local, Host: openSUSE, Virtualización: VMware player, igual que @T-Systems. A evitar que su infraestructura nos influya:
  • Win 2008 R2. Apache 2.2.25 + PHP 5.4.26 NTS, VC9 como módulo fastcgi
  • Win 2008 R2. IIS7 + PHP 5.4.26 NTS, VC9 como módulo fastcgi (con y sin wincache)
  • Win 2012. IIS * + PHP 5.5.10 NTS, VC11 como módulo fastcgi (con y sin wincache)
• En una máquina local sin virtualización
  • Win 2008 R2. Apache 2.2.25 + PHP 5.4.26 NTS, VC9 como fastcgi módulo

Los resultados de los perfiles mencionados anteriormente fueron los mismos en los diferentes sistemas (~10% de derivación). Windows siempre fue un factor significativo más lento que Linux.

El uso de una nueva instalación de WordPress y Slimstats resultó en aprox. los mismos resultados. Reescribir el código no es una opción aquí.

Update: Mientras tanto, encontramos otros dos sistemas Windows (ambos Windows 2008 R2, VM y Phys) donde esta pila completa se ejecuta bastante rápido. Mismo configuración sin embargo.

Actualización 2 : Ejecutar PHP como módulo apache en los Servidores Life fue un poco más rápido que el método fastcgi: hasta ~2 segundos, 50% menos.

Se está quedando sin memoria

Después de algún tiempo, nuestro Servidor en vivo deja de funcionar, activando estas excepciones de memoria:

PHP Fatal error:  Out of memory (allocated 4456448) (tried to allocate 136 bytes)
PHP Fatal error:  Out of memory (allocated 8650752) (tried to allocate 45 bytes) 
PHP Fatal error:  Out of memory (allocated 6815744) (tried to allocate 24 bytes) 

Esto sucede en ubicaciones de script aleatorias. Obviamente, el Administrador de memoria Zend no es capaz de asignar más memoria, aunque los scripts serían se le permite hacerlo. En el momento del incidente, el servidor tenía aproximadamente el 50% de RAM libre (2 GB+). Así que el servidor no se queda sin ram. Reiniciar Apache / PHP solucionó este problema por ahora.

No estoy seguro de si este problema está relacionado con los problemas de rendimiento aquí. Sin embargo, como ambos temas parecen estar relacionados con la memoria, se incluye aquí. Especialmente trataremos de reproducir la configuración de las pruebas de Windows que proporcionaron un rendimiento decente.

3) Configuración de Apache y PHP

... probablemente no tienen ninguna trampa común. Output-Buffering está habilitado( por defecto), multibye override deshabilitado, ... Si alguna opción(s) son de interés, estaremos encantados de proporcionarlas.

Salida de httpd.exe -V

Server version: Apache/2.4.7 (Win32)
Apache Lounge VC10 Server built:   Nov 26 2013 15:46:56
Server's Module Magic Number: 20120211:27
Server loaded:  APR 1.5.0, APR-UTIL 1.5.3
Compiled using: APR 1.5.0, APR-UTIL 1.5.3
Architecture:   32-bit
Server MPM:     WinNT
  threaded:     yes (fixed thread count)
    forked:     no
Server compiled with....
 -D APR_HAS_SENDFILE
 -D APR_HAS_MMAP
 -D APR_HAVE_IPV6 (IPv4-mapped addresses disabled)
 -D APR_HAS_OTHER_CHILD
 -D AP_HAVE_RELIABLE_PIPED_LOGS
 -D DYNAMIC_MODULE_LIMIT=256
 -D HTTPD_ROOT="/apache"
 -D SUEXEC_BIN="/apache/bin/suexec"
 -D DEFAULT_PIDLOG="logs/httpd.pid"
 -D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
 -D DEFAULT_ERRORLOG="logs/error.log"
 -D AP_TYPES_CONFIG_FILE="conf/mime.types"
 -D SERVER_CONFIG_FILE="conf/httpd.conf"

mpm_winnt_module configuración:

<IfModule mpm_winnt_module>
    ThreadsPerChild 150
    ThreadStackSize 8388608 
    MaxConnectionsPerChild 0
</IfModule>

Extracto de php.ini:

realpath_cache_size = 12M
pcre.recursion_limit = 100000

4) Razón actual sospechada

Antigua suposición:

Los tres ejemplos dependen en gran medida de grandes matrices y operaciones de cadena. Que algunos kind parece ser la fábrica común. Como la implementación funciona bien en Linux, sospechamos que esto es un problema de memoria en Windows. Dado que no hay interacción con la base de datos en las ubicaciones puntiagudas, no sospechamos que la base de datos o la integración de PHP del Servidor sea el problema. De alguna manera la interacción de memoria de PHP parece ser lenta. Tal vez hay alguien interfiriendo con la memoria en Windows haciendo el acceso dramáticamente más lento?

Antigua suposición 2:

Como la misma pila funciona bien en otras máquinas Windows, asumimos que el problema está en algún lugar de la configuración de Windows.

Nueva suposición 3: {[17]]}

En realidad estoy fuera de suposiciones. ¿Por qué ejecutaría PHP mucho más lento como fastcgi que como módulo apache>

¿Alguna idea sobre cómo verificar esto o encontrar el verdadero problema aquí? Cualquier ayuda o dirección para solucionar este problema es muy bienvenida.