Sitzungssperre nach Verwendung von Cm_RedisSession

Wir haben mit dem Standardmodul Cm_RedisSession von Magento 1.9.2.4 zu Redis als Sitzungsspeicher gewechselt. Nach der Bereitstellung hatten viele Kunden sehr lange Ladezeiten (> 20-30 Sek.). Für den Redis-Server verwenden wir AWS ElastiCache (m3.large).
In Tideways (ähnlich wie Newrelic) habe ich diesen Engpass in der Ablaufverfolgung gesehen:

Nachdem ich mehr über dieses Problem gelesen und das Cm_RedisSession-Protokoll durchgesehen hatte, stellte ich fest, dass die Sitzung des Kunden gesperrt war, und entschied mich nach weiteren Recherchen, Cm_RedisSession auf 1.14 zu aktualisieren, da die Sitzungssperre verbessert wurde.

Mit der neuesten Version wird das Problem minimiert, da die Sperre nach 5 Sekunden nun korrekt aufgehoben wird. Es gibt aber noch eine Ladezeit von 5 Sekunden.

Ich hatte zwei Theorien.

1. Einige Anfragen sterben ab, sodass keine session_close()Anrufe mehr getätigt werden. Aus diesem Grund wird die Sperre nicht aufgehoben:

   Ich habe jedes Protokoll (php-fpm, nginx und magento) aktiviert und sie beobachtet, bis dieser Fehler in Tideways für einen Kunden angezeigt wird, aber in diesem bestimmten Zeitraum gab es keinen Fehler

2. Mehrere Skripte versuchen, dieselbe Sitzung zu lesen / schreiben:

   Ich habe ein Skript erstellt, das hundertmal parallel dieselbe Seite mit demselben Frontend-Cookie aufruft, aber keine Sperre angezeigt wird.

Zu diesem Zeitpunkt kann ich nicht herausfinden, warum diese Sperre angezeigt wird, und noch schlimmer, ich kann sie nicht auf meiner lokalen Maschine oder meinem Staging-System reproduzieren.

Hat jemand einen Hinweis oder eine Lösung, wie ich dieses Problem lösen könnte?

Bearbeiten : Hat jemand versucht, die Sperre in Cm_RedisSession zu deaktivieren?

Edit : gleiches Problem mit 1.15

Bearbeiten : Die meisten Anforderungen mit einer Sperre sind Ajax-Anforderungen. Aber ich kann es trotzdem nicht reproduzieren.

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

Redis- INFOBildschirm:

$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

Ich scheine unsere Probleme größtenteils beseitigt zu haben. Die genaue Ursache habe ich jedoch nie ermittelt.

Nach dem Upgrade der neuesten Version von Cm_RedisSession ergab die Protokollierung, dass 95% der Anforderungen, die die Sitzung abhielten, tatsächlich zustandslos sein sollten. Ich habe FLAG_NO_START_SESSION in preDispatch () implementiert, um zu verhindern, dass Magento Sitzungen erstellt. Ich war sehr überrascht, dass in der Produktion die jetzt "zustandslosen" Anforderungen immer noch 95% der Sitzungssperren enthielten. Weitere Untersuchungen ergaben, dass wir einige schießende Beobachter hatten, die immer noch versuchten, die Sitzung zu starten. Nachdem diese aktualisiert wurden, um auch die FLAG_NO_START_SESSION zu berücksichtigen, wurde unser Problem mit der Sitzungssperre fast vollständig behoben.

Ich glaube nicht, dass dies das Problem löst, aber ich hoffe, dass andere eine ähnliche Technik anwenden können.