Cm_RedisSession kullandıktan sonra oturum kilidi


9

Magento 1.9.2.4'ten varsayılan Cm_RedisSession Modülü ile Oturum Depolama olarak Redis'e geçtik. Dağıtımdan sonra birçok Müşteri çok uzun sayfa yükleme süreleri (> 20-30 sn.) Yaşadı. Redis-Server için AWS ElastiCache (m3.large)
Tideways'de (Newrelic'e benzer şekilde) kullanıyoruz.

Tideways'ten izleme

Bu sorun hakkında daha fazla bilgi okuduktan ve Cm_RedisSession günlüğüne baktıktan sonra, Müşteriden Oturumun kilitlendiğini anladım ve daha fazla araştırmadan sonra oturum kilitleme iyileştirmeleri nedeniyle Cm_RedisSession'ı 1.14'e yükseltmeye karar verdim.

En son sürümde sorun en aza indirilmiştir, çünkü kilit şimdi 5 saniye sonra doğru bir şekilde kırılacaktır. Ama hala 5 saniyelik bir yükleme süresi var.

İki teorim vardı.

  1. Bazı istekler ölür, böylece session_close()arama yapılmaz ve bu nedenle kilit serbest bırakılmaz:

    Her günlüğü (php-fpm, nginx ve magento) etkinleştirdim ve bu hata Müşteri için Tideways'de görünene kadar izledim, ancak bu belirli zaman diliminde hata yoktu

  2. Birden çok komut dosyası aynı oturumu okumaya / yazmaya çalışır:

    Aynı ön uç çerezi ile aynı sayfaya yüz kez paralel çağıran bir Komut Dosyası oluşturdum, ancak kilit görünmüyor.

Bu noktada, bu kilidin neden göründüğünü ve daha da kötüsünü anlayamıyorum, yerel Maschine veya evreleme Sistemimde yeniden üretemiyorum.

Bu sorunu nasıl çözebileceğime dair bir ipucu ya da çözüm olan var mı?

Düzenleme : Birisi Cm_RedisSession kilitlemeyi devre dışı bırakmaya çalıştı mı?

Düzenleme : 1.15 ile aynı Sorun

Düzenleme : kilitli isteklerin çoğu ajax isteğidir. Ama yine de çoğaltamıyorum.


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

Yeniden INFOEkran:

$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

1
Cm_RedisSession Magento 1.9.x çekirdek kodunda yer alır, ancak aslında Colin Mollenhour tarafından geliştirilmiştir. 1.9.2.4'te bulunan Cm_RedisSession modül kodunu veya GitHub github.com/colinmollenhour/Cm_RedisSession'ın en son sürümü mü kullanıyorsunuz ?
paj

Yazdığım gibi, en son Sürüme
Pawel

Redis sunucusunu yerel olarak çalıştırırsanız aynı sorunu görüyorsunuz
paj

1
Tamamen aynı sorunu izliyorum. İlk olarak bu MemCache'i deneyimledik ve daha fazla görünürlük kazanma umuduyla Redis'e taşındık. Apache 2.x ile 1.14.2 kullanıyoruz. Redis-cli monitörünü kullanarak isteklerin oturumu kilitlediğini ve ardından kilidini açtığını belirleyebildim. Taleplerimizin küçük bir yüzdesinin neden bunu yaptığını henüz belirlemedik (günün zirvesinde saatte yaklaşık 50-100).
Craig Harris

1
magento.stackexchange.com/a/130691/69 Benzer bir soru ama ayıklarken kullanılmak için bazı seçenekler / araçlarını sunabilir.
B00MER

Yanıtlar:


6

Sorunlarımızı çoğunlukla ortadan kaldırmış gibi görünüyorum. Ancak, asıl nedeni asla belirlemedim.

En son Cm_RedisSession sürümünü yükselttikten sonra, günlük kaydı, oturumu tutan isteklerin% 95'inin gerçekte vatansız olması gerektiğini gösterdi. Magento'nun oturum oluşturmasını önlemek için preDispatch () öğesine FLAG_NO_START_SESSION uyguladım. Üretimde şu anda "vatansız" isteklerin hala oturum kilitlerinin% 95'ini tuttuğunu görmek beni çok şaşırttı. Daha fazla araştırma, halen oturumu başlatmaya çalışan bazı gözlemcilere sahip olduğumuzu tespit etti. Bunlar, FLAG_NO_START_SESSION sürümüne de uyacak şekilde güncellendiğinde, oturum kilitleme sorunumuz neredeyse tamamen kaldırıldı.

Bunun sorunu çözdüğünü düşünmüyorum, ama umarım başkaları da benzer bir teknik kullanabilir.


Durumsuz istek isteğinin bizim için çalışmadığını düşünüyorum, çünkü bu isteklerin oturuma ihtiyacı var.
Pawel
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.