CakeSession :: _ startSession - Wolna na Elasticache

Question

Używamy CakePHP 2.9 i używamy Elasticache Cluster do przechowywania sesji (który jest przechowywany przez Memcached).

Mamy wbudowanym zbieranie śmieci sesja niepełnosprawnej PHP jak tutaj zalecane: https://tideways.io/profiler/blog/php-session-garbage-collection-the-unknown-performance-bottleneck

session.gc_probability = 0

Mamy również wybrać ustawienie probability na 0 w CakePHP za config Cache.

Jednak; my wciąż występują problemy przy czym od czasu do czasu możemy wystąpić poważne powolnym upadki w CakeSession :: _ startSession, jak donosi New Relic:

Elasticache Klaster nie wykazuje żadnych wskaźników, które sugerują, że jest to problem (o ile nie ma pewnych danych, których nie rozumiem poprawnie).

Wszelkie sugestie dotyczące diagnozowania tej przyczyny?

Answer 1

Ten problem wydaje się być spowodowany blokowaniem sesji, o czym nawet nie wiedziałem.

Ten artykuł wyjaśnia, jak i dlaczego istnieje Session Blokowanie: https://ma.ttias.be/php-session-locking-prevent-sessions-blocking-in-requests/

Co ważne jest to, że memcached ma zamek sesja domyślnie włączona.

W naszym przypadku nie używamy Sesji do innych celów niż uwierzytelnianie, nasza aplikacja nie wykorzystuje informacji o sesji do przechowywania stanu użytkownika (tak jak robiłaby to koszyk na zakupy), więc po prostu wyłączyliśmy blokowanie sesji za pomocą php.ini ustawienie:

memcached.sess_locking = 0

Od wprowadzeniu tej zmiany, jakie obserwujemy ogromną poprawę czasów reakcji (~ 200ms średnio ~ 160). Jest to szczególnie widoczne na stronach o dużym obciążeniu AJAX, które jednocześnie ładują wiele danych. Wcześniej wydawało się, że żądania są ładowane sekwencyjnie, ale teraz wszystkie są obsługiwane jednocześnie, różnica w prędkości jest niesamowita.

Chociaż najprawdopodobniej niektóre przypadki odkryjemy w ciągu najbliższych tygodni/miesięcy w wyniku wyłączenia blokady sesji, wydaje się, że jest to przyczyną problemu, a ta zmiana prawdopodobnie spowodowała zatrzymanie problemu z powodu występujący.

Answer 2

Musisz debugować w trybie niezwiązanym, aby dowiedzieć się, która warstwa powoduje problemy.

Może to być ciasto, infrastruktura AWS, opóźnienia w sieci ...

Run to mały skrypt PHP i powiedz nam czasu zajęło.

// memcache 
$m = microtime(true); 
$memcache_obj = new Memcache; 
$memcache_obj->connect('myhost.cache.amazonaws.com', 11211); 
printf('%.5f', microtime(true) - $m) ; 

// memcached. 
$time = microtime(true); 
$m = new Memcached(); 
$m->addServer('<elasticache node endpoint>', 11211); 

$m->set('foo', 100); 
var_dump($m->get('foo')); 
printf('%.5f', microtime(true) - $time) ; 

Jeśli czas jest OK, problemem będzie ciasto.

Jednak będąc tutaj uczciwym, jestem pewien, że problemem jest klastra ElastiCache.

Spróbuj wskazać i punkt końcowy węzła, a nie punkt końcowy ElastiCache Cluster i daj mi znać, jak działa ti.