Hoe breekbaar is mssql_Pconnect

[Guillome]

Hoi,

Ik ben de bouwer en beheerder van een website die door veel mensen bezocht wordt. Duizenden per dag.
Ik heb altijd mssql_connect gebruikt, 2 keer voor 2 databases.
In de nieuwe versie heb ik mssql_pconnect toegevoegd:

PHP:

  $_DB_conn_external = mssql_pconnect($_db_external_ip, $_db_external_user, $_db_external_pass) or die("Kan geen verbinding 2 maken");
  if (!mssql_select_db($_db_external, $_DB_conn_external))
  {
    $_DB_conn_external = mssql_connect($_db_external_ip, $_db_external_user, $_db_external_pass) or die("Kan geen verbinding 2 maken");
    mssql_select_db($_db_external, $_DB_conn_external) or die("Kan de database 2 niet selecteren.");
  }
  $_DB_conn = mssql_pconnect($_db_ip, $_db_user, $_db_pass) or die("Kan geen verbinding maken.");
  if (!mssql_select_db($_db, $_DB_conn))
  {
    $_DB_conn = mssql_connect($_db_ip, $_db_user, $_db_pass, true) or die("Kan geen verbinding maken.");
    mssql_select_db($_db, $_DB_conn) or die("Kan de database niet selecteren.");
  }

Ik doe het dubbel omdat pconnect soms geen verbinding kan maken (bij herhaaldelijk op F5 bijv.).
Maar gister zijn verschillende tabellen in de DB corrupt geraakt. Kan dat hier door komen?
Is dit link met veel gebruikers tegelijk vanuit 1 pand?

[TJHeuvel]

Ik doe het dubbel omdat pconnect soms geen verbinding kan maken (bij herhaaldelijk op F5 bijv.)

Een beetje gaare oplossing IMO...

De connectie zou gewoon moeten werken, ten aller tijde. Upgrade anders je database-server, deze kan het verkeer gewoon niet aan.

Je zou, al is het afgeraden, de connectie in een lusje kunnen zetten. Probeer het 3 keer, als daarna nogsteeds geen database connectie is laat de gebruiker het gewoon weten.

[Guillome]

De server wordt ook door andere apps gebruikt, het is een MSSQL server.
De connectie komt soms niet tot stand, terwijl er op dat moment weinig gebruikers online waren.

Maar dit is wel deels offtopic. Mijn vraag was hoe breekbaar dit kan zijn voor een database

[ Voor 22% gewijzigd door Guillome op 26-03-2010 12:31 ]

[arnob]

ik weet niet wat voor library het is maar een tabel raakt niet corrupt als je foute commando's geeft. Als de client bokt dan heeft de (MSSQL) server nog geen last.. ik neem aan dat de tabel dus niet corrupt is.
Bedoel je dat je andere data dan verwacht hebt?
Misschien dat je sessies door elkaar lopen?

[Guillome]

Er waren 7 tabellen niet meer te gebruiken. De site liep vast (timeout) en de enterprice manager ook (timeout expired)

[djexplo]

Het geen verbinding krijgen van mssql_pconnect komt door:

Please note that mssql_pconnect creates a connection for the pool for *each process*. If you have "ThreadsPerChild" set to 50 in apache, and mssql.max_procs set to 25 in php, then eventually you will get mssql_pconnect failing to give you a connection to the database. This has stumped me for quite a while, and the answer finally presented itself thanks to the people in #php.

[HuHu]

Guillome schreef op vrijdag 26 maart 2010 @ 09:43:

Ik doe het dubbel omdat pconnect soms geen verbinding kan maken (bij herhaaldelijk op F5 bijv.).

Dat is altijd dom en geen oplossing. Op het moment dat je zoiets doet moet je jezelf al afvragen waar je mee bezig bent.

Waarom heb je eigenlijk de connect vervangen door een pconnect? Heb je er een goede reden voor? Zat je met efficiëntie-problemen? Zit er een grote overhead in het opzetten van een connectie? Een te hoge belasting op de server door het databasegebruik? Zo nee: terug naar connect.

[Guillome]

Omdat het anders 2 keer zo`n 0.3 seconden duurt voordat de verbinding uberhaupt tot stand is gekomen. Met pconnect is dat vele malen sneller. Puur voor snelheidswinst.
Ik vond het ook niet een nette oplossing, en vraag daarom ook de voor- en nadelen van pconnect.

[Bram®]

Lijkt mij sterk dat twee keer een connectie proberen te maken, een corruptie veroorzaakt.
Het is waarschijnlijker dat je ergens een persistente connectie open hebt staan die iets aan het doen is, en in het midden daarvan wordt onderbroken (script timeout bijv.) en daardoor een tabel beschadigd.
Of je filesystem heeft problemen.

De laatste keer dat ik met MSSQL+PHP heb gewerkt is alweer een paar jaar geleden, maar toen was MS bezig met een eigen driver voor PHP: http://blogs.msdn.com/sqlphp/.
Ik weet niet precies wat de reden erachter was, volgens mij meer features, maar misschien is het goed om daar eens naar te kijken.

Het is niet stom om te proberen meerdere malen een connectie te maken, want het kan prima zijn dat een server een connectie weigert omdat 'ie te druk is. Wacht dan wel even tussen het maken van verbindingen en doe dit slechts als tijdelijke maatregel (probeer de oorzaak te vinden en op te lossen).

Kijkend naar je code: als je eerste pconnect goed gaat maar je mssql_select_db fout, dan ga je een niet-persistente connectie opzetten, een selectdb en daarna weer een pconnect. Wat is de logica daarachter??


Ikzelf zou dit een stuk logischer vinden:

PHP:

<?php 
  $conn = false;

  $i=0;
  while (!is_resource($conn) && $i<3) {
    $i++;
    usleep(100);
    $conn = mssql_pconnect();
  }

  if (!is_resource($conn)) {
    die('Kon geen verbinding maken');
  }

  // Nu pas database selecteren

?>

[CH4OS]

Guillome schreef op vrijdag 26 maart 2010 @ 12:50:
Omdat het anders 2 keer zo`n 0.3 seconden duurt voordat de verbinding uberhaupt tot stand is gekomen. Met pconnect is dat vele malen sneller. Puur voor snelheidswinst.
Ik vond het ook niet een nette oplossing, en vraag daarom ook de voor- en nadelen van pconnect.

Ik denk dat het dan interessanter is om uit te zoeken waarom je 2 pogingen moet wagen om überhaupt een verbinding te krijgen. Dáár zit namelijk je probleem, niet in je PHP-code.

[Bram®]

djexplo schreef op vrijdag 26 maart 2010 @ 12:38:
Het geen verbinding krijgen van mssql_pconnect komt door:

[...]

Maar zou dat ook verklaren waardoor z'n enterprise manager een timeout krijgt?

[Guillome]

@Bram: ik probeer een pconnect. Wil dat niet, dan een gewone. Daarna niet nogmaals een pconnect, dat heb je niet goed gezien (of ik zie iets niet goed).

@CptChaos: meestal gaat ie bij 1 poging al goed hoor. Soms echter niet. Ik ga `t eens onderzoeken

Edit:
Bram, het vastlopen van Enterprice manager is bij de corrupte tabellen. Dat is waar dit topic over ging.
Waar het nu over gaat is waarom ik een dubbele heb, en dat is omdat pconnect soms niet verbind. Hetgeen jij quote gaat daar over

[ Voor 32% gewijzigd door Guillome op 26-03-2010 13:01 ]

[Creepy]

Bram® schreef op vrijdag 26 maart 2010 @ 12:58:
[...]


Maar zou dat ook verklaren waardoor z'n enterprise manager een timeout krijgt?

Als die pconnect de verbinding openhoudt en de MSSQL server z'n max aantal verbindingen heeft bereikt: ja

[Guillome]

code:

mssql.max_procs Unlimited   Unlimited

Phpinfo()...

[Creepy]

Guillome schreef op vrijdag 26 maart 2010 @ 13:04:

code:

mssql.max_procs Unlimited   Unlimited

Phpinfo()...

Ok, en het maximum aantal connecties dat MSSQL zelf toestaat is hoeveel?

[Guillome]

Ik zal het meteen navragen, dat kan ik zelf niet bekijken

[Bram®]

@guillome:

Sorry, ik had je code niet goed gelezen en niet gezien dat je naar twee verschillende databases probeert te connecten

[Guillome]

Had ik er ook wel even bij kunnen zetten zie ik nu

[arnob]

ik geloof nog steeds niet dat de tabellen corrupt zijn.
Je kan problemen krijgen bij het benaderen indien de tabellen exclusief gelocked zijn.
probeer eens exec sp_who of exec sp_who2 (sql2000? query analyzer) of het current activity overzicht in de sql ent manager. kolom 'blocked' toont de spid van de veroorzaker. evt commando 'kill' om die sessie te annuleren.

[Guillome]

Het was vanaf een bepaalde row. Als je scrolde tot row X, of CTRL+END dan hing hij.

Ik zal eens proberen wat je zegt

Edit: omg.... denk dat je gelijk hebt. Nu doen ze het weer
Vanaf gister tot vandaag waren ze onbereikbaar. Rare zaak. Komt dit mogelijk door pconnect?

[ Voor 40% gewijzigd door Guillome op 26-03-2010 14:54 ]

[arnob]

het systeem is opgebouwd om niet corrupt te raken (ACID)
Je zal een locking conflict gehad hebben. Een standaard dead-lock situatie zal door de server doorbroken worden maar vaak gebeurt er meer waardoor de sqlserver het niet afkapt. (live-lock bv)
Of het door de connect library komt is moeilijk te zeggen. Misschien andere defaults voor de time-out?
Andere locking strategie geforceerd door de library?
Je kan het met de current activity af en toe bekijken hoe het gaat. Het SQL dashboard kan ik aanraden maar ik weet zo niet of die ook op sql2000 werkt. (sql2005 wel, 2008 heeft iets ingebouwd maar niet zo mooi)
Je kan misschien eens op een test systeem met de SQL tracer/SQL profiler kijken hoe een connect van de verschillende libraries gedaan wordt.