ďťż
Podstrony
|
telcocafeTakie proste pytanie: czy jeśli nie będę rozłączał się z bazą np. po zakończeniu skryptu to połączenie jest automatycznie zrywane?Jeśli tak to po jakim czasie - automatycznie, czy ileś sekund po zakończeniu skryptu jest aktywne? Można zrobić klasę do bazy i w destruktorze rozłączyć, ale uważam że niepotrzebnie komplikujemy życie tworząc klasy do obsługi innych klas, gdy można do zrobić bez kombinacji, krócej i szybciej. Może głupie pytanie, ale staram się jak mogę optymalizować skrypty ;) Użytkownik Ghoost edytował ten post 31 maj 2009, 08:10 Połączenie jest zamykane z końcem wykonywania się skryptu - jeżeli nie zrobisz tego wcześniej. Jakiegoś realnego wpływu na wydajność to to nie ma. Przy mało ruchliwych stronach problemów z wydajnością mieć nie powinieneś (jedyne co może je zrobić to źle zaprojektowana struktura bazy danych - nieoptymalne zapytania). Strona nie jest mało ruchliwa - AJAXem wywoływana jest masa stron PHP, które pobierają dane z mysql. Czyli, że mysqli::close zamyka po prostu połączenie wcześniej? Ciekawiło mnie po prostu czy te połączenie nie jest zrywane, zamiast rozłączane przy końcu skryptu Połączenie jest domyślnie zrywane po zakończeniu skryptu. Stałe połączenia są dostępne w MySQLi dopiero od PHP 5.3. http://www.php.net/m...li.overview.php http://www.php.net/m...ersistconns.php Kurczę, zupełnie zapomniałem o stałych połączeniach ;) (w moim przypadku to będzie wręcz idealne rozwiązanie, biorąc pod uwagę mnóstwo zapytań AJAX) Pamiętam, że używało się kiedyś do tego mysql_pconnect, ale nie widzę jak to zrobić w mysqli :/ Napiszesz jaka jest od tego funkcja? // Ach, mamy PHP 5.29 :D // A w PHP6 jest stałe połączenie w mysqli? // Albo kiedy PHP 5.3? Użytkownik Ghoost edytował ten post 31 maj 2009, 17:38 Po co ci trwałe połączenia? Na stronach o relatywnie małym ruchu tego typu sprawy wydajnościowe są całkowicie pomijalne. Jeżeli jedna strona robi ci wiele zapytań Ajax na raz - to i tak wykona się tyle samo zapytań gdyby to nie szło ajaksem :P Dla PHP 5.2.9 i 5.3.X używaj PDO w pierwszej kolejności, MySQLi w drugiej, jako że PDO jest domyślnym interfejsem, a mysqli ma stać się opcjonalny i z czasem przesunięty do PECL. mysqli ma stać się opcjonalny i z czasem przesunięty do PECL A nie mysql_*? PDO oferuje stałe połączenia: http://www.php.net/m...connections.php. Jeżeli zdecydujesz się na PDO, pamiętaj, aby tworzenie obiektu objąć w instrukcję try jak w przykładzie 2. Stałe połączenia mogą powodować błędy, jeżeli jest nałożony limit połączeń w MySQL. mysql już poleciało, mysqli z czasem też poleci do PECL, czy też będzie domyślnie nie budowane w samym PHP. A nie mysql_*? PDO oferuje stałe połączenia: http://www.php.net/m...connections.php. Jeżeli zdecydujesz się na PDO, pamiętaj, aby tworzenie obiektu objąć w instrukcję try jak w przykładzie 2. Stałe połączenia mogą powodować błędy, jeżeli jest nałożony limit połączeń w MySQL. Hmmm hmmm... A to jeżeli łączymy się tylko z jedną bazą to nie ma tylko jednego stałego połączenia? $dbh = new PDO('mysql:host=localhost;dbname=db', 'root','pass',array(PDO::ATTR_PERSISTENT => true)); Jeżeli będę dawał taki kod, to będzie szukane połączenie stałe i tak jakby wznawiane? (no, innego słowa nie mogę wymyślic ;)) // Od kiedy wpadłem na forum po długim czasie nieobecności, sporo pomogliście ;) Zmieniłem sposób walidacji, przerzuciłem się z mysqli na PDO, jest o wiele lepiej - stałe połączenia, podobno szybsze, preparowanie zapytań - :thumbsup: ) Użytkownik Ghoost edytował ten post 01 czerwiec 2009, 18:41 Teoretycznie tak. Jednak stałe połączenia zżerają zasoby serwera. Ze swojego doświadczenia powiem tyle, że stałe połączenia używam tylko i wyłącznie wtedy kiedy dostęp do danych muszę mieć pełny i szybki. Pisałem aplikację dla firmy brokerskiej, która potrzebuje dane po sekundach mieć dostepne. i na przykład odpytują co 2 - 3 sekundy serwer. Wtedy tworzę stałe połączenie i przypisuję je pod sesję użytkownika, żeby jeden user miał jedno połączenie dla siebie. Poza takimi ekstremami nie widzę konieczności używania stałych połączeń. |
|||
Sitedesign by AltusUmbrae. |