MySQL_Connect versus MySQL_PConnect

Přidáno: 28.05.2011 v 19.58

Na internetu se vždy jednou za čas objeví diskuze na téma: „Používat či nepoužívat persistentní (trvalé) spojení s databází?“ Teoreticky jsou výhody persistentního připojení popsány opravdu velmi lákavě. Skutečné výhody a nevýhody z reálného fungování však k sehnání nejsou. A tak jsem se nedávno konečně odhodlal persistentní spojení vyzkoušet na vlastní pěst.

Co vlastně znamená trvalé persistentní spojení?

Klasické mysql_connect (které využívá většina PHP programátorů) vytvoří pro každé volání nové spojení. To znamená, že přijdeli návštěvník na web, pokusí se mysql_connect připojit k databázi a po načtení celé stránky se spojení ukončí. Vše funguje dobře, ale opakované vytváření spojení zabírá nějaký čas. A proto je zde mysql_pconnect, které vytvoří trvalé persistentní spojení s databází. To v praxi znamená, že při zobrazení stránky se mysql_pconnect dotáže, zda již existuje nějaké volné spojení. Pokud neexistuje, vytvoří nové tak jako mysql_connect. Pokud ale nějaké existuje, nic nevytváří a předá pouze identifikátor. To by teoreticky podle dokumentace mělo přinést zrychlení a snížení náročnosti obzvláště u velkých projektů.

Má to nějaké nevýhody?

Ano, nevýhodou je omezení maximálního počtu trvalých připojení. U mysql_connect se nic takového neřeší, zde už ale musejí být nastaveny limity (kvůli udržení funkčnosti serveru). Tyto limity mohou být u některých levnějších poskytovatelů velmi nízké (například 50 spojení). To znamená, že server zvládne přijmout maximálně 50 dotazů do databáze v jednom okamžiku. Pro nějaký menší web dobré, ale u větších už nikoliv. U mého poskytovatele mám limit 500 spojení a to je už i pro větší projekty postačující. Tím končí vše, co z dokumentace a na internetu vyčtete. Pořád to zní velmi dobře, tak proč to nezkusit?

Skutečnost

Změna je jednoduchá, pouze přepíšete mysql_connect na mysql_pconnect a to je vše. Web fungoval, a tak jsem ho nechal několik měsíců takto běžet. Po nějaké době, jsem při řešení jednoho problému objevil, že se mi v databázi vyskytla nekonzistentní data. V mé aplikaci je však všechno pečlivě ošetřeno použitím cizích klíčů a transakcí. O to víc bylo zarážející, že jsem našel ještě další nekonzistentní výskyt. Nedařilo se mi identifikovat žádný problém a byl jsem z toho už zoufalý. Vzpomněl jsem si však, že před použitím persistentního spojení vše fungovalo dokonale a začal jsem zkoumat.

Skutečnost kterou jsem objevil mě vedla k okamžitému zrušení používání persistentního spojení. Pokud uživatel spustil akci, která vyvolá transakci, ale uprostřed dojde k fatální chybě (například pádem webového serveru), persistentní spojení databázového serveru si proběhlé dotazy v nedokončené transakci pamatuje a když jiný návštěvník dostane toto spojení a provede jakoukoliv další transakci úspěšně, promítnou se i předchozí stará nekonzistentní data.

Závěr

Ozkoušeno mám pouze na platformě PHP a MySQL, ale myslím si, že stejně chování bude i kdekoliv jinde. Na jednu stranu je to asi logické chování, na tu druhou je to pro mě důvod, proč již nikdy persistentní spojení nepoužiji. A nechci domýšlet následky u e-shopů či dokonce nějakého účetního systému.

Nový komentář

 

 

 

 

Pravidla

  • Tučně * označené položky je nutné vyplnit.
    E-mail nebude zveřejněn.
  • Pište prosím slušně a k věci. Pokud můžete, používejte diakritiku.
  • HTML formátování není podporováno.
  • Na předchozí komentáře odkazujte zápisem [4].

 

Navigace

Kategorie článků

Nejzajímavější články

Tento kód slouží k testování robotů vykrádajících obsah těchto stránek