¿Cuánto tiempo deben conservarse los archivos de la sesión de magento?

Question

Tengo un cliente cuyos archivos de sesión magento están creciendo rápidamente fuera de control. Los estamos purgando una vez a la semana, pero parece que puede ser necesario que sean más frecuentes.

1) ¿Qué hacen estos archivos? ¿Cómo están conectados a la experiencia en línea de los usuarios (por ejemplo, si los elimino y el usuario aún está en el sitio, cómo se verán afectados)

2) ¿Cuándo puedo eliminarlos? ¿Cuánto tiempo los archivos realmente necesitan permanecer en el servidor?

Chris

Answer 1

Cada archivo es la sesión de una persona y debe última no más de session.gc_maxlifetime segundos - la recolección de basura: configurada en el archivo php.ini del servidor o anulada en un archivo .htaccess. Bajar este valor significa que se acumularán menos sesiones.

Magento tiene otro truco relacionado con las sesiones; En el archivo /app/etc/local.xml, el valor session_save se puede cambiar a db, lo que significa que la base de datos se usará en lugar de archivos, pero respetará la vida útil del recolector de basura antes mencionado. También se puede especificar memcache si lo ha configurado (consulte /app/etc/local.xml.additional). Ambos son muy útiles si el servidor es un clúster.

Answer 2

depende de su duración de la sesión, el usuario si las sesiones se mantienen permanece conectado o sus preferencias permanecen intactos cuando se visita la tienda otra vez. Puede borrar todas las veces que quiera, pero recuerde que va a salir/carros claras para todos los usuarios que han iniciado sesión mientras lo hace

Answer 3

No olvide examinar qué parte del sistema almacena incorrectamente cantidades irracionales de datos en la sesión para solucionar realmente el problema. Limpiar las sesiones antes es solo una solución temporal.

Los archivos de sesión siempre deben ser pequeños. Las probabilidades son que algunas secuencias de comandos almacenan una cantidad inadecuadamente grande de datos en la sesión para "eficiencia" y causar el problema.

---

Es casi seguro que se almacenan objetos en la sesión que causa este problema. Un patrón común en Magento es tener datos de objeto encadenados como este:

$product-> 
    'attr1' => 'somevalue', 
    ... 
    'categories' => array(
     'products' => array(
     <and so on and so forth> 
     ), 
    ), 

Dejar caer un objeto en la sesión puede incluir este gigantescas cadenas de objetos sin querer, el almacenamiento de una gran cantidad de datos extraños. Si es posible, almacene solo datos de cadena/numéricos en la sesión, como matrices de ID para productos, en lugar de los productos mismos.

Answer 4

Con sesiones basadas en archivos, se eliminarán automáticamente mediante el cron de limpieza de la sesión PHP, por lo que es probable que los archivos se eliminen dentro de ~ 7200 segundos de la creación. Por lo tanto, incluso en un sitio ocupado (30.000 exclusivos por día), normalmente solo hay unos 4.000 archivos de sesión en ./var/session, que no es nada para un servidor Linux.

Sin embargo, la limpieza realmente depende del funcionamiento de cron, que normalmente no se ve en el directorio ./var/session de Magento. Por lo que debe establecer un nuevo sistema de cron

/usr/bin/find /home/myuser/public_html/var/session -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 -exec rm {} \; >/dev/null 2>&1 

El valor predeterminado limpiar periodo de sesiones es de 7200 segundos, lo que debería ser más que suficiente, aunque se puede cambiar para adaptarse lo anterior.

Con las sesiones de Memcache, TCP/IP es la única sobrecarga, que para una implementación de servidor único, lo haría más lento que el archivo. Entonces, usaría un socket Unix en su lugar, lo que elimina esa sobrecarga y brinda una mayor seguridad. Pero aún así, sus sesiones de cliente se verán truncadas/limitadas en cuanto a la cantidad de RAM que puede asignar. La sesión promedio de Magento es de 4 Kb, por lo que podrá admitir 256 sesiones activas, por MB que asigne. Por lo tanto, asegúrese de establecer un límite apropiado para evitar que los clientes pierdan la compra/sesión al azar. Y también ten en cuenta que un reinicio del daemon Memcache borrará todas las sesiones existentes (¡MALO!).

Con Redis (no nativo, pero disponible a través de una extensión), obtiene un nivel similar de compatibilidad como Memcache, pero con los beneficios adicionales de la persistencia (si desea usarlo). Con la extensión Cm_Redis, también podrá aprovechar la compresión de sesión. Hemos encontrado que esta extensión funciona muy bien en las implementaciones de CE y EE.

Con DB, la configuración de expiración predeterminada es de 1 semana, por lo que con el tamaño de tienda anterior como ejemplo (30k únicos por día), verá un tamaño de tabla DB para core_cache_session de alrededor de 7 GB - que hará que tu tienda se detenga por completo, para casi cada operación basada en sesión.

De la experiencia de acoger ambos de gran tamaño (230 mil visitantes únicos por día) y pequeños (< 1k visitantes únicos por día) almacena, nuestra recomendación es:

un solo servidor de despliegue - archivos

Multi implementación -server - Redis (utilizando una base de datos separada de la principal caché Magento)

me escribió algunas respuestas muy completas aquí http://magebase.com/magento-tutorials/magento-session-storage-which-to-choose-and-why/comment-page-1/#comment-1980

Answer 5

También los tenía acumulados, así que agregué un trabajo cron con lo siguiente ... (esto era de instrucciones en mi archivo php.ini ... solo en la configuración "session.gc_maxlifetime = 1440")

Para ejemplo, el siguiente script sería el equivalente a ; estableciendo session.gc_maxlifetime a 1440 (1440 segundos = 24 minutos): ; buscar/ruta/a/sesiones -cmin +24 | xargs rm