2015-03-27 14 views
7

Używam klienta Jedis do łączenia się z serwerem Redis. Poniżej przedstawiono ustawienia używam do łączenia z Jedis (przy użyciu Apache Commons basen):Ustawienia połączeń jedis dla wysokiej wydajności i niezawodności

JedisPoolConfig poolConfig = new JedisPoolConfig(); 
poolConfig.setTestOnBorrow(true); 
poolConfig.setTestOnReturn(true); 
poolConfig.setMaxIdle(400); 

// Tests whether connections are dead during idle periods 
poolConfig.setTestWhileIdle(true); 
poolConfig.setMaxTotal(400); 

// configuring it for some good max value so that timeout don't occur 
poolConfig.setMaxWaitMillis(120000); 

tej pory z tych ustawień nie mam napotykając żadnych problemów pod względem niezawodności (zawsze mogę dostać Jedis kiedy tylko chcę), ale widzę pewne opóźnienie w działaniu Jedisa.

Czy ktoś może zaproponować mi więcej optymalizacji pod kątem uzyskania wysokiej wydajności?

+0

Która część jest "wolna" dla Ciebie? Mogą to być objazdy w sieci, które można obniżyć, korzystając ze skryptów pipelining lub lua. Redis jest dość szybki, więc nie powinno tak być. Czy twoja pula jest zdefiniowana z wieloma przykładami jedis? Jeśli zbyt wiele komponentów zadaje proste pytanie o instancję typu jedis, będzie blokować zadania, ponieważ nie ma wystarczających zasobów dla wszystkich. Czy możesz to sprawdzić? – zenbeni

Odpowiedz

13

Masz 3 testy skonfigurowane:

  • TestOnBorrow - wysyła żądanie PING jeśli poprosisz o zasobie.
  • TestOnReturn - Wysyła PING, gdy zwracasz zasób do puli.
  • TestWhileIdle - Wysyła okresowe PINGS z bezczynnych zasobów w puli.

Podczas gdy dobrze jest wiedzieć, że połączenia są wciąż żywe, te żądania onBorrow PING marnują RTT przed Państwa zapytaniem, a pozostałe dwa testy marnują cenne zasoby Redis. Teoretycznie połączenie może zepsuć nawet po teście PING, więc powinieneś wychwycić wyjątek połączenia w swoim kodzie i poradzić sobie z nim, nawet jeśli wyślesz ping. Jeśli twoja sieć jest stabilna i nie masz zbyt wielu spadków, powinieneś usunąć te testy i obsłużyć ten scenariusz tylko w swoich wyjątkowych połowach.

Ponadto, ustawiając MaxIdle == MaxTotal, nie będzie eksmisji zasobów z puli (dobra/zła ?, zależy od użycia). A kiedy twoja pula zostanie wyczerpana, próba zdobycia zasobu zakończy się w timeout po 2 minutach oczekiwania na wolny zasób.

+0

Dzięki Ofir za odpowiedź na moje pytanie. Przechowywałem wszystkie te kontrole, aby zawsze uzyskać zasób bezbłędnie. Ale wydaje mi się, że powodują one również spowolnienie niektórych wniosków/wniosków Jedi. Rozumiałem twoje pierwsze użycie trzech parametrów, ale wciąż mam wątpliwości co do używania "maks. Bezczynności" i "maks. Sumy". powiedzmy, że przechowuję 100 zasobów jako "max Total" i 50 jako max idle, czy otrzymam tylko 50 aktywnych połączeń, czy dostanę 100 aktywnych połączeń z tymi ustawieniami? – pjain

+0

Chciałbyś również wiedzieć, jak jedis pool zarządza połączeniami? Powiedz Jeśli ustawię 100 jako aktywne połączenia, czy będzie on utrzymywał wszystkie 100 aktywnych połączeń automatycznie (przez cały okres użytkowania aplikacji) lub będę musiał połączyć się ponownie dla jakiegoś zasobu na wypadek, gdyby ktoś się zepsuł (jeśli jedis.getResource() zwróci wyjątek dla tych połączeń)? – pjain

+0

"Również, ustawiając MaxIdle == MaxTotal, nie będzie eksmisji zasobów z twojej puli (dobra/zła ?, zależy od twojego użycia)." Jest źle, tak myślę. Nawet jeśli ustawisz maxidle == MaxTotal, będzie eksmisja, jeśli ustawisz timeBetweenEvictionRunsMillis()> 0. –

Powiązane problemy