Kunci sesi setelah menggunakan Cm_RedisSession

Kami beralih ke Redis sebagai Penyimpanan Sesi dengan Modul Cm_RedisSession default dari Magento 1.9.2.4. Setelah penyebaran, banyak Pelanggan mengalami waktu pemuatan halaman yang sangat lama (> 20-30 Dtk). Untuk Redis-Server kami menggunakan AWS ElastiCache (m3.large)
Dalam Tideways (mirip dengan Newrelic) saya melihat hambatan ini dalam jejak:

Setelah membaca lebih lanjut tentang masalah ini dan melihat ke dalam log Cm_RedisSession, saya menemukan bahwa Sesi dari Pelanggan terkunci dan setelah penelitian lebih lanjut saya memutuskan untuk Meningkatkan Cm_RedisSession ke 1,14, karena peningkatan untuk penguncian sesi.

Dengan Versi terbaru masalahnya diminimalkan, karena kunci akan rusak sekarang dengan benar setelah 5 detik. Namun masih ada loadtime 5 Detik.

Saya punya dua teori.

1. Beberapa permintaan mati sehingga tidak ada session_close()panggilan dan untuk alasan itu kunci tidak akan dirilis:

   Saya mengaktifkan setiap log (php-fpm, nginx, dan magento) dan menontonnya hingga kesalahan ini muncul di Tideways untuk Pelanggan, tetapi tidak ada kesalahan dalam jangka waktu khusus ini

2. Banyak skrip mencoba membaca / menulis sesi yang sama:

   Saya membuat Script yang memanggil paralel seratus kali halaman yang sama dengan cookie frontend yang sama, tetapi tidak ada kunci yang muncul.

Pada titik ini, saya tidak tahu mengapa kunci ini muncul dan lebih buruk lagi, saya tidak dapat mereproduksinya di Maschine lokal saya atau Sistem pementasan.

Adakah yang punya petunjuk atau solusi bagaimana saya bisa menyelesaikan masalah ini?

Sunting : apakah seseorang mencoba menonaktifkan penguncian di Cm_RedisSession?

Sunting : Masalah yang sama dengan 1.15

Sunting : sebagian besar permintaan dengan kunci adalah permintaan ajax. Tapi toh saya tidak bisa mereproduksinya.

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

INFOLayar 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

Saya sepertinya telah menghilangkan sebagian besar masalah kami. Namun, saya tidak pernah benar-benar menentukan penyebab pastinya.

Setelah memutakhirkan versi terbaru Cm_RedisSession, pencatatan menunjukkan bahwa 95% permintaan yang memegang sesi harus benar-benar tanpa kewarganegaraan. Saya menerapkan FLAG_NO_START_SESSION di preDispatch () untuk mencegah sesi pembuatan Magento. Saya sangat terkejut menemukan bahwa dalam produksi permintaan "stateless" sekarang masih memegang 95% dari kunci sesi. Investigasi lebih lanjut menemukan bahwa kami memiliki beberapa pengamat yang sedang menembak yang masih mencoba untuk memulai sesi. Setelah ini diperbarui untuk menghormati FLAG_NO_START_SESSION masalah penguncian sesi kami hampir seluruhnya telah dihapus.

Saya tidak berpikir ini menyelesaikan masalah, tetapi saya berharap orang lain dapat menggunakan teknik serupa.