Czy musze zamykać połączenia z bazą?

Question

Czy na koniec działania każdego skryptu musze zamykać polączenie mysqli poprzez '$con->close()' i co się stanie jak nie zamkne tego? Będzie aktywne po zakonczeniu wczytywania skryptu PHP czy może wplynie na bezpieczenstwo?

 

Czy bardziej wydajnie będzie po prostu nie zamykać go jeśli sam skrypt nie wykonuje sie dluzej niż 10ms?

Answer 1

Nie musisz zamykać, nic się nie stanie. Możesz, ale myślę że raczej nie masz aplikacji przy której spowodowałoby to znaczącą różnicę.

http://php.net/manual/en/mysqli.close.php

Open non-persistent MySQL connections and result sets are automatically destroyed when a PHP script finishes its execution. So, while explicitly closing open connections and freeing result sets is optional, doing so is recommended. This will immediately return resources to PHP and MySQL, which can improve performance. For related information, see freeing resources

 

Comments

Nie musisz zamykać, nic się nie stanie.

tu bym dyskutował... metoda close() zwraca boolean co już w pierwszym odruchu mówi mi, że może warto tę zwrotkę wrzucić w logi?

Pewnie masz rację, że najczęściej nic się nie stanie, ale wiem z doświadczenia, że gdy składa się baza danych to cenna jest każda, najdrobniejsza wskazówka i informacja... I wtedy właśnie takie dobrze zorganizowane logi potrafią naprawdę mocno przyspieszyć podnoszenie systemu.

myślę że raczej nie masz aplikacji przy której spowodowałoby to znaczącą różnicę

pewnie tak :), ale wg mnie warto uczyć się mysleć przyszłościowo i starać się stosować dobre praktyki.

---

Zgodzę się, że logi często potrafią wiele rzeczy uratować, ale czy samo true/false z zamknięcia połączenia będzie pomocne... No nie wiem, podyskutować o tym możemy, ale jak mam być szczery to nie przyszłoby mi do głowy, aby logować boola zwróconego z funkcji zamykającej połączenie :) Oczywiście jednocześnie przyznaję, że nie mam praktycznego doświadczenia z wtopami na dużej skali, może stąd brak takiego pomyślunku.

Na pewno warto stosować dobre praktyki od początku, tylko czy to taką jest? Moglibyśmy tak zwalniać zasoby usuwając wiele wartości podczas działania skryptu, tyle że na małą skalę moim zdaniem więcej by było tracone czasu na same usuwanie tego, niż faktycznego zysku.

---

może stąd brak takiego pomyślunku.

kiedyś też tak myślałem, ale jak masz awarię i musisz w parę minut wyszperać coś sensownego z milionach logów to uwierz mi, warto mieć jakieś punkty zaczepienia :)

Oczywiście, że w większości malych projektów to nie ma sensu, ale chodziło mi bardziej o to, aby zawsze chociaż analizować takie kwestie, i tu duży plusik z mojej strony dla autora wątku, za to, że zainteresował się tą sprawą, a nie pisze na ślepo "bo w poradnikach jest tak...".

Wiem po prostu z własnego doświadczenia, że gdy wpadłem nagle w duży projekt to otworzyły mi się oczy na rzeczy, o których kiedyś bym w ogóle nie myślał. Ba, nawet Ci powiem, że w moich własnych projektach zacząłem mocno iść w stronę różnych logów i eventów statystycznych i widze wymierne korzyści tego... jak chociażby lepsze poznanie zachowań userów, możliwość łatwiejszej analizy wprowadzanych ficzerów itp.

A co do takich logów to jakiś czas temu jeden z adminów mi to fajnie wytłumaczył... Powiedział wprost, że w praktyce większość operacji nieudanych można by wyciągać z logów na samej bazie itp. itd. Ale dzwoni Ci check alarmowy, pada baza, lecą 500, masz takich baz w systemie kilkadziesiąt, z każdej bazy korzysta wiele mikrousług i lepiej w tym momencie zalogować parę tysięcy logów więcej ale mieć je w jednym zwartym systemie niż rozproszone wszędzie :) wchodzisz i paroma odpytaniami elastica jesteś w stanie dojść co powoduje wyjebkę.

Jak pisałem, nikt oczywiście nie będzie takich logów robił w prostym e-sklepie czy "stronie fryzjera", ale wg mnie dużym zyskiem będzie, jeśli autor tego posta gdzieś z tyłu głowy będzie miał info, że w niektóych sytuacjach może Ci to uratować dupę :)

Czasami takie rzeczy też mogą pomóc choćby na rozmowach o pracę :) Na przykład łatwo sprawdzić, czy ktoś miał styczność z jakimiś średnio dużymi czy dużymi bazami... proste pytanko - jaki typ powinien mieć wg Ciebie ID w tabeli w bazie? Jak ktoś wie co to BigData to o int nawet się nie zająknie :) ale każda książka o podstawach baz danych usilnie wali inty, ba, często nawet bez wzmianki kiedy jest to oki, a kiedy jest to strzał w kolano (nie oszukujmy się, z drugiej strony dla prostego bloga nie ma co panikować... także wszystko leży od rodzaju apki :)

---

Nie mam powodu, aby nie wierzyć :)

nawet Ci powiem, że w moich własnych projektach zacząłem mocno iść w stronę różnych logów i eventów statystycznych i widze wymierne korzyści tego

To w sumie ciekawa kwestia, opowiedziałbyś krótko coś więcej? Jakie akcje (przykładowo) rejestrujesz do takich logów i jak później je analizujesz?

dzwoni Ci check alarmowy, pada baza, lecą 500, masz takich baz w systemie kilkadziesiąt, z każdej bazy korzysta wiele mikrousług i lepiej w tym momencie zalogować parę tysięcy logów więcej ale mieć je w jednym zwartym systemie niż rozproszone wszędzie

Lekko zgubiłem kontekst chyba. Zarządzanie tym z jednego miejsca na pewno jest spoko, ale nasza dyskusja wyszła od logowania rzeczy nie do końca dla mnie oczywistych. Tego że warto zalogować więcej i porządkować to w jedno miejsce na logikę biorąc nie będę kwestionował ;)

jeśli autor tego posta gdzieś z tyłu głowy będzie miał info, że w niektóych sytuacjach może Ci to uratować dupę 

Pewnie, zawsze trzeba myśleć co się robi i do tego dobierać rozwiązania.

Jak ktoś wie co to BigData to o int nawet się nie zająknie :) ale każda książka o podstawach baz danych usilnie wali inty, ba, często nawet bez wzmianki kiedy jest to oki, a kiedy jest to strzał w kolano 

Na tym chyba rzecz polega, że jeśli ktoś jest już na odpowiednim poziomie to dane rzeczy wie i tyle. A z książkami w większości wiemy jak jest... Już takich rzeczy bym się nawet nie czepiał, niech najpierw zaczną być dobrze tłumaczone inne podstawowe rzeczy :D

---

To w sumie ciekawa kwestia, opowiedziałbyś krótko coś więcej? Jakie akcje rejestrujesz do takich logów i jak później je analizujesz?

Nauczyłem się, że dobre są różne eventy frontowe, do których kiedyś nie przywiązywałem takiej uwagi, np. evnty na kliki praktycznie dla każdego klikalnego elementu, eventy na inicjalizacji różnych komponentów na stronie, analiza scrollowania usera, trzymanie jakiegoś uuid sesyjnego dla eventów aby móc analizować usera, np. wejście w formularz zamówienia, informacja co wybierał, co zmieniał, ile razy, itp. itd. czy skończyl proces, jeśli nie to co robił dalej, czy np. interesował się jeszcze takim produktem w tej sesji, jeśli tak to z jakiego miejsca itp. itd. Do tego mamy dzisiaj wiele ciekawych parametrów z samego środowiska, np. navigator.connection.effectiveType co daje Ci jakiś pogląd o łączach userów, itp. Oczywiście to wszystko ma sens tylko wtedy, gdy jest potem przestrzeń na analizę takich eventów, bo zbieranie ich dla samego zbierania to mija się z celem :)

W sumie przede wszystkim warto zbierać kliki, pozwala to analizować mapy klikalności na stronie i fajnie modyfikować np. położenie róznych elementów aby więcej osób w nie wchodziło, wywalanie tych zbędnych itp.

Jak ktoś nie chce np. puszczać dziesiątek requestów z eventami to zawsze można je agregować i robić jakieś bardziej skompresowane requesty ale to już są szczegóły mniej istotne, potrzeba wtedy więcej nakładów pracy w back-endzie na ich odpowiednie rozrzucenie w bazie... zawsze jest więc pytanie gdzie jest ta granica co robić client-side, a co w back-endzie :)

---

Ok, dzięki, rozumiem :) Brzmi ciekawie i pewnie warto byłoby się szerzej zainteresować, ale takie analizy bardziej w gestii jakiegoś UI/UX designera pewnie. Życia mi nie starczy na zainteresowanie się wszystkim czym bym chciał w samym programowaniu :P

Answer 2

Zależy od bazy i usługi
Ale czasami bez tego nie da się połączyć z innej usługi

Np kiedy Visual Studio ma otwarte stałe połączenie do bazy, to nie można obsługiwać tej bazy za pomocą SQL Server Management Studio
Ale aplikacja wtedy działa prawidłowo

Możliwe, że jeśli nie zamkniesz i z innej aplikacji spróbujesz sie połączyć to będziesz czekać w nieskończoność, albo dostaniesz info że teraz korzysta inna usługa