Lepszym wytłumaczeniem partitionCount w BoneCP

Question

Od oficjalnego dokumentu BoneCP: http://jolbox.com/index.html?page=http://jolbox.com/configuration.html

partitionCount w celu zmniejszenia blokady rywalizacji, a tym samym zwiększenia wydajności, każde żądanie połączenia przychodzące odbiera się połączenia z puli, która ma wątek-powinowactwo, tj. puli [threadId% partition_count]. Im wyższa jest ta liczba, tym lepszy będzie Twój występ w przypadku, gdy masz dużo krótkich wątków. Po przekroczeniu pewnego progu zachowanie tych pul rozpocznie się ma negatywny wpływ na wydajność (i tylko w przypadku, gdy połączenia na partycji zaczynają się kończyć).

domyślna: 2, minimalna: 1, zalecane: 3-4 (ale bardzo specyficzna aplikacja)

Ale to nie jest tak jasne i nie ma dobrego przykładu. Prowadzę normalną usługę sieciową z równoczesnym wątkiem 0-500. Co to jest dobra wartość i dlaczego?

Answer 1

Wewnętrznie BoneCP ma numer puli połączeń. Za każdym razem, gdy wątek próbuje nawiązać połączenie, trwa thread.getId() % partitionCount i działa z połączeniem z tej puli. Będziesz mieć łącznie maxConnectionsPerPartition * partitionCount liczbę połączeń.

Dlaczego ma to pozytywny wpływ na wydajność? Cóż, aby nie używać dwóch wątków jednocześnie na tym samym łączu (oczywiście byłoby to złe), BoneCP musi wykonać blokadę, aby zwolnić lub uzyskać połączenie. Ale w tym samym czasie wszystkie inne wątki, które chcą zrobić to samo, muszą czekać na ten zamek. Więc w pewnym sensie możesz zwolnić lub odebrać partitionCount liczbę połączeń równolegle.

Jakiej liczby ustawić? Myślę, że liczba rdzeni to dobry początek, ponieważ i tak nie będzie więcej równoległej pracy. Ale poza tym spróbuj przewidzieć, ile wątków będzie ścigać się po połączenia, mierz i powtórz.

BTW, większość świata opiera się na c3po przez ponad dekadę i że w zasadzie liczba partycji została ustawiona na 1. Nie można zatem pomylić się z tym.