Okej, wiem, że connection pool przechowuje otwarte połączenia do bazy danych, aby nie wykonywać za każdym razem kosztownego procesu podłączania się na nowo. Po prostu jak przychodzi klient to aplikacja sprawdza czy ma w connection poolu otwarte połączenie i jeżeli ma to klient je dostaje. Ale właśnie - czym jest tutaj klient ? Mógłby ktoś to wyjaśnić na przykładzie CRUDa postawionego na Tomcacie ? Stoi sobie taka apka pod jakimś adresem, wchodzi na nią jakiś użytkownik i pobiera coś z bazy, przychodzi drugi i też coś pobiera. Czy przez fakt, że transfer z i do bazy odbywa się w jednej aplikacji to w connection pool jest tak naprawdę tylko jedno połączenie ? Jeżeli tak to w takim razie kiedy zaczyna być widoczna przewaga dobrego, wydajnego connection pool i kiedy w takiej aplikacji zaobserwowalibyśmy w nim większą ilość połączeń ?
- Rejestracja:około 17 lat
- Ostatnio:13 dni
Nie, connection pool nie ma (prawie) nic wspólnego z użytkownikiem twojego serwisu. Użytkownikiem w tym momencie jest dowolny proces/wątek (zwał jak zwał), który chce wykonać zapytanie do DB. Z reguły połączeń do DB utrzymujesz więcej niż jedno, bo inaczej tylko jedna osoba na raz mogłaby odpytywać DB, a to trochę mało wydajne. Tak samo mało wydajne jest tworzenie nowego połączenia dla każdego zapytania. Więc co nam pozostaje? Pooling.
Działa to w taki sposób, że odpalasz sobie N połączeń do DB, które są odpalane na starcie aplikacji (N jest konfigurowalne) i są one zarządzane w postaci kolejki. Jak ktoś (inny proces) chce wykonać połączenie do DB, to pool "pożycza mu" dane połączenie na jakiś czas w czasie którego musi on wykonać połączenie i odebrać dane (timeout jest tutaj by zapobiec głodzeniu) a następnie "zwrócić" połączenie do puli. Jeśli jednak wszystkie połączenia są "zajęte" to taki proces ląduje w dodatkowej kolejce (FIFO lub LIFO), która po kolei przydziela połączenia jak tylko zostaną "zwrócone".
Okej czyli w puli są połaczenia, a z połączeń korzystają wątki. Ale jak to wygląda w działającej aplikacji, użytkownik chce wyciągnąć dane, więc za pośrednictwem wątku dobiera się do połączenia z poola i je wyciąga ? To by oznaczało, że przy pool size np 50 (chyba tyle jest domyślnie w Hikari, moge sie mylic) tylko 50 użytkowników może w jednej chwili korzystać (wyjmować dane) z bazy. Troche mało jeżeli mówimy o realnej apce typu np sklep.
- Rejestracja:ponad 12 lat
- Ostatnio:7 miesięcy
- Postów:6610
nie do końca mało - należy pisać tak aby samo pobranie trwało jak najkrócej:
- nie pobierasz wszystkich towarów i po stronie frontu filtrujesz z tego 10 tylko od razu pobierasz tylko 10
- jeśli wyświetlenie jednej pozycji jest czasochłonne bo np. do każdej pozycji dociągasz 20MB zdjęcie to możesz "szybko" zaciągnąć wszystkie dane do np. tablicy, zwolnić połączenie i dopiero obrabiać je dalej.
- dla operacji długotrwałych (np. jakieś raporty) możesz mieć osobną pulę połączeń i tutaj wprost komunikować userowi, że już generuje się 50 raportów - poczekaj na swoją kolej.
Przy krótkich połączeniach (a tak powinny one być pisane) user "nie widzi" tego, że np. jego pytanie trafiło do kolejki i musi chwilę poczekać.