Cambiamos a Redis como almacenamiento de sesión con el módulo Cm_RedisSession predeterminado de Magento 1.9.2.4. Después de la implementación, muchos clientes experimentaron tiempos de carga de página muy largos (> 20-30 seg.). Para Redis-Server estamos usando AWS ElastiCache (m3.large)
En Tideways (similar a Newrelic) vi este cuello de botella en la traza:
Después de leer más sobre este problema y buscar en el registro Cm_RedisSession, descubrí que la sesión del cliente estaba bloqueada y, después de más investigaciones, decidí actualizar Cm_RedisSession a 1.14, debido a las mejoras para el bloqueo de la sesión.
Con la última versión, el problema se minimiza, porque el bloqueo se romperá ahora correctamente después de 5 segundos. Pero todavía hay un tiempo de carga de 5 segundos.
Tenía dos teorías
Algunas solicitudes mueren, por lo que no hay
session_close()llamadas y, por esa razón, el bloqueo no se liberará:Habilité todos los registros (php-fpm, nginx y magento) y los observé hasta que este error aparece en Tideways para un Cliente, pero no hubo ningún error en este período de tiempo en particular
Varios scripts intentan leer / escribir la misma sesión:
Creé un script que llama paralelamente cientos de veces la misma página con la misma cookie de interfaz, pero no aparece ningún bloqueo.
En este punto, no puedo entender por qué aparece este bloqueo y, lo que es peor, no puedo reproducirlo en mi Maschine local o sistema de preparación.
¿Alguien tiene una pista o solución sobre cómo podría resolver este problema?
Editar : ¿alguien intentó deshabilitar el bloqueo en Cm_RedisSession?
Editar : mismo problema con 1.15
Editar : la mayoría de las solicitudes con bloqueo son solicitudes ajax. Pero no puedo reproducirlo de todos modos.
$ php5-fpm -v
PHP 5.5.32-1+deb.sury.org~trusty+1 (fpm-fcgi) (built: Feb 5 2016 10:10:42)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies$ nginx -v
nginx version: nginx/1.8.1local.xml
<redis_session>
<host>***************</host>
<port>****</port>
<password></password>
<timeout>2.5</timeout>
<persistent></persistent>
<db>0</db>
<compression_threshold>2048</compression_threshold>
<compression_lib>gzip</compression_lib>
<log_level>1</log_level>
<max_concurrency>6</max_concurrency>
<break_after_frontend>5</break_after_frontend>
<break_after_adminhtml>30</break_after_adminhtml>
<first_lifetime>600</first_lifetime>
<bot_first_lifetime>60</bot_first_lifetime>
<bot_lifetime>7200</bot_lifetime>
<disable_locking>0</disable_locking>
<min_lifetime>60</min_lifetime>
<max_lifetime>2592000</max_lifetime>
</redis_session>Redis INFOScreen:
$1939
# Server
redis_version:2.8.24
redis_git_sha1:0
redis_git_dirty:0
redis_build_id:0
redis_mode:standalone
os:Amazon ElastiCache
arch_bits:64
multiplexing_api:epoll
gcc_version:0.0.0
process_id:1
run_id:fbf620d695c006bdb570c05b104404eb8f2c12aa
tcp_port:6379
uptime_in_seconds:1140502
uptime_in_days:13
hz:10
lru_clock:12531431
config_file:/etc/redis.conf
# Clients
connected_clients:8
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
# Memory
used_memory:2586086144
used_memory_human:2.41G
used_memory_rss:2637590528
used_memory_peak:2586312888
used_memory_peak_human:2.41G
used_memory_lua:36864
mem_fragmentation_ratio:1.02
mem_allocator:jemalloc-3.6.0
# Persistence
loading:0
rdb_changes_since_last_save:18525202
rdb_bgsave_in_progress:0
rdb_last_save_time:1471008721
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
# Stats
total_connections_received:1518441
total_commands_processed:28898066
instantaneous_ops_per_sec:14
total_net_input_bytes:7409376406
total_net_output_bytes:3059470870
instantaneous_input_kbps:3.10
instantaneous_output_kbps:0.78
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:420590
evicted_keys:0
keyspace_hits:8754547
keyspace_misses:18323
pubsub_channels:0
pubsub_patterns:0
latest_fork_usec:0
# Replication
role:master
connected_slaves:0
master_repl_offset:322498
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2795
repl_backlog_histlen:319704
# CPU
used_cpu_sys:729.42
used_cpu_user:509.25
used_cpu_sys_children:0.00
used_cpu_user_children:0.00
# Keyspace
db0:keys=1413298,expires=1413297,avg_ttl=1780138273
Respuestas:
Parece que eliminé principalmente nuestros problemas. Sin embargo, nunca determiné la causa exacta.
Después de actualizar la última versión de Cm_RedisSession, el registro indicó que el 95% de las solicitudes que contenían la sesión en realidad no deberían tener estado. Implementé FLAG_NO_START_SESSION en preDispatch () para evitar que Magento cree sesiones. Me sorprendió mucho descubrir que en producción las solicitudes ahora "sin estado" todavía tenían el 95% de los bloqueos de sesión. Una investigación adicional descubrió que teníamos algunos observadores que estaban disparando y que aún intentaban comenzar la sesión. Una vez que se actualizaron para honrar también el FLAG_NO_START_SESSION, nuestro problema de bloqueo de sesión se eliminó casi por completo.
No creo que esto resuelva el problema, pero espero que otros puedan usar una técnica similar.
fuente