Verrouillage de session après utilisation de Cm_RedisSession

9

Nous sommes passés à Redis en tant que stockage de session avec le module Cm_RedisSession par défaut de Magento 1.9.2.4. Après le déploiement, de nombreux clients ont connu des temps de chargement des pages très longs (> 20-30 secondes). Pour le serveur Redis, nous utilisons AWS ElastiCache (m3.large)
Dans Tideways (similaire à Newrelic), j'ai vu ce goulot d'étranglement dans la trace:

Trace de Tideways

Après avoir lu plus sur ce problème et consulté le journal Cm_RedisSession, j'ai compris que la session du client était verrouillée et après plus de recherches, j'ai décidé de mettre à niveau Cm_RedisSession vers 1.14, en raison des améliorations apportées au verrouillage de session.

Avec la dernière version, le problème est minimisé, car le verrou se cassera désormais correctement après 5 secondes. Mais il reste un temps de chargement de 5 secondes.

J'avais deux théories.

  1. Certaines demandes meurent donc il n'y a pas d' session_close()appels et pour cette raison le verrou ne sera pas libéré:

    J'ai activé chaque journal (php-fpm, nginx et magento) et les ai regardés jusqu'à ce que cette erreur apparaisse dans Tideways for a Customer, mais il n'y a pas eu d'erreur dans cette période particulière

  2. Plusieurs scripts tentent de lire / écrire la même session:

    J'ai créé un script qui appelle parallèlement cent fois la même page avec le même cookie frontal, mais aucun verrou n'apparaît.

À ce stade, je ne peux pas comprendre pourquoi ce verrou apparaît et pire encore, je ne peux pas le reproduire sur mon Maschine local ou système de mise en scène.

Quelqu'un a-t-il un indice ou une solution pour résoudre ce problème?

Edit : quelqu'un at-il essayé de désactiver le verrouillage dans Cm_RedisSession?

Edit : même problème avec 1.15

Edit : la plupart des requêtes avec un verrou sont des requêtes ajax. Mais je ne peux pas le reproduire de toute façon.


$ 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.1

local.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>

INFOÉcran Redis :

$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
Pawel
la source
1
Cm_RedisSession est inclus dans le code principal de Magento 1.9.x mais est en fait développé par Colin Mollenhour. Utilisez-vous le code du module Cm_RedisSession inclus avec 1.9.2.4 ou la dernière version de GitHub github.com/colinmollenhour/Cm_RedisSession ?
paj
Comme je l'ai écrit, nous avons mis à niveau vers la dernière version
Pawel
Voyez-vous le même problème si vous exécutez le serveur redis localement
paj
1
Je cherche exactement le même problème. Nous avons d'abord expérimenté ce MemCache et avons déménagé à Redis dans l'espoir de gagner en visibilité. Nous utilisons 1.14.2 avec Apache 2.x. En utilisant le moniteur redis-cli, j'ai pu identifier que les demandes bloquaient la session et ne la déverrouillaient pas. Nous n'avons toujours pas déterminé pourquoi un petit pourcentage de nos demandes le font (environ 50 à 100 par heure en période de pointe).
Craig Harris
1
magento.stackexchange.com/a/130691/69 Une question similaire mais peut offrir des options / outils à utiliser lors du débogage.
B00MER

Réponses:

6

Il semble que j'aie surtout éliminé nos problèmes. Cependant, je n'ai jamais vraiment déterminé la cause exacte.

Après la mise à niveau de la dernière version de Cm_RedisSession, la journalisation a indiqué que 95% des demandes qui tenaient la session devraient en fait être sans état. J'ai implémenté FLAG_NO_START_SESSION dans le preDispatch () pour empêcher Magento de créer des sessions. J'ai été très surpris de constater qu'en production, les demandes désormais "sans état" détenaient toujours 95% des verrous de session. Une enquête plus approfondie a révélé que certains observateurs qui tiraient tentaient toujours de commencer la session. Une fois ceux-ci mis à jour pour honorer également le FLAG_NO_START_SESSION, notre problème de verrouillage de session a été presque entièrement supprimé.

Je ne pense pas que cela résout le problème, mais j'espère que d'autres pourront utiliser une technique similaire.

Craig Harris
la source
Je pense que la demande de demande sans état ne fonctionne pas pour nous, car cette demande nécessite la session.
Pawel