PHP Oracle ODBC trage response

[Vm1heA]

Ik heb op een P4 2600 met 1G ram en 60G diskstripe een Oracle DB met PHP en ODBC draaien.
Daarbij Coldfusion en MySQL.

Nu is het zo dat Coldfusion via ODBC heel snel data uitwerkt.
Maar PHP via ODBC niet, dan is ie traag en PHP draait als CGI waardoor ie vol loopt met php.exe modules in de tasklist.

PHP met Mysql doet het weer wel snel.

Even wat versies :
Win2k server SP4
PHP 4.3.6
Oracle 9 + ODBC driver die erbij hoort.
Coldfusion 4
IIS5

Op een andere server ( PII 350 met 256 MB ) doet ie het wel goed.
Maar daar draait NT4 op met SP6
IIS3 , Oracle 8.1 en PHP 4.3.3


Waarom is PHP zo langzaam met de database via ODBC en Coldfusion niet ?
En waarom werkt het op de ouwe bak wel snel en de nieuwe niet ?

Als er specifieke specs van PHP oid moeten komen dan zie ik de vraag wel komen.

[Verwijderd]

Ik denk dat het te maken heeft met de "interne" Named-Pipes configuratie, dit is de manier waarop je DB communiceert met je koppeling, hier kun je verschillende Tresholds aangeven waardoor e.e.a beter gaat presteren, je zou hier eens naar kunnen zoeken in het register van php. Suc6


kon het niet laten Collega..LOL prutsert

[Verwijderd]

Professional Networking & Servers -> Software Algemeen

[Vm1heA]

Kick

Weet niemand hier iets op ?

En ik vind dat deze toch bij PNS moet staan want heb meer van deze vragen daar gezien.

[Spider.007]

Vm1heA schreef op 05 juni 2004 @ 10:55:
Kick

Weet niemand hier iets op ?

En ik vind dat deze toch bij PNS moet staan want heb meer van deze vragen daar gezien.

PHP installatie problemen horen gewoon in SA Zie ook [q=http://gathering.tweakers.net/forum/list_messages/439616]• PNS is voor 'Advanced' vragen. Dat houd dus in, dat het een 'zwaar topic' moet zijn, wil het topic in PNS blijven. Om dit nog even te verduidelijken, hier wat dingen die sowieso al niet PNS zijn:
• Apache
• PHP
• MySQL
• IIS
• Een Windows98 PC die 1 uur per dag aanstaat
• Windows XP Prof. waar photoshop niet op wil installeren.

[elevator]

Controleer je ODBC instellingen even - en eventueel driver specifieke instellingen ook (registry - HKLM\Software\ODBC.ini e.d.) om te zien ofdat deze volledig hetzelfde is.

[Vm1heA]

Zal maandag eens gaan spitten in de registry of ik daar iets vind.

[Vm1heA]

Apache 1.3 geinstalleerd > geen verbetering.

PHP 4.3.3 erop gezet ipv 4.3.6 > geen verbetering.

ODBC in de registry nagekeken, zelfde waardes gevonden als de oude server.

1 sleutel was anders > HKLM\software\odbc\odbcinst.ini\Oracle ODBC Driver
"APILevel"="2" was op de nieuwe server 1, maar 2 haalde ook niks uit aan de performance.

Het is puur in de PHP modules waar het probleem zich voor doet, die staan niks te doen en te wachten lijkt het.

[Vm1heA]

Nog eens een test gedaan.
Het is de connectie opbouwen vanuit PHP naar ODBC lijkt het.
Zodra ik de DB open met odbc_connect('databasenaam','userame','pass') dan duurt het even voor de connectie opgebouwd is.
De query doet ie wel heel snel.

[justmental]

Is het aanloggen aan de database met een SQL*Net verbinding wel snel?

[Skaah]

Kun je dan niet beter persistent connecties gebruiken? (_pconnect)

[Vm1heA]

Persistent is niet mogelijk in dit geval omdat ik dan alles om moet bouwen aan scripts.
En dat zijn er nogal wat ( gok zo een 1000+ )

Op de oude server werkte het wel goed en dat was een slomere bak zelfs.

Heb nu zelfs DSNless geprobeerd, maar helaas , nog net zo traag.
PHP zelf is retesnel , maar zodra ie met ODBC aan de gang moet wacht ie op de connectie lijkt het.
Althans, met een script uitgeprobeerd, connectie maken > echo met text , dan duurt het zelfs even.
Query zelf is snel, daar ligt het niet aan.
Mysql is er wel snel op rechtstreeks en coldfusion is ook snel via odbc.

Php.exe zie je wachten in de tasklist tot de connectie klaar is.

@justmental:
En die SQL*Net verbinding maken , wat bedoel je ermee ?

[justmental]

Vm1heA schreef op 07 juni 2004 @ 14:51:
@justmental:
En die SQL*Net verbinding maken , wat bedoel je ermee ?

Bijvoorbeeld met SQL*Plus aanloggen aan de database.

[Vm1heA]

Ja dat doet ie wel retesnel.
Maar ODBC doet het ook snel met coldfusion.
Alleen PHP doet zo vaag, die wacht op de connectie.

[MarlonB]

Waarom in godsnaam een odbc connectie ? Alle kracht van oracle kapot maken, door er een microsoft product tussen te zetten

Je hebt helemaal geen ODBC connectie nodig. Beste en snelste wat je kan doen is de OCI-module installeren. Dan je tnsnames.ora opzetten om een bequeth connectie te maken, dan hoef je ook geen listener te draaien voor oracle.
Dit is een beetje tricky voor windows....ik zal straks even thuis de settings opzoeken. Ik heb hem zelf ook zo een tijdje aan het draaien gehad.

Indicatie response times:
ODBC : 6 sec
Bequeth: 0.8 sec


Example connect-string:
$tnssid = "(DESCRIPTION = (ADDRESS = (PROTOCOL = BEQ) (PROGRAM = /opt/oracle/product/9.2.0/bin/oracle) (ARGV0 = DBSID) (ARGS ='(DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))') ) (CONNECT_DATA = (SID = DBSID)))";

[djluc]

Vm1heA schreef op 07 juni 2004 @ 15:02:
Ja dat doet ie wel retesnel.
Maar ODBC doet het ook snel met coldfusion.
Alleen PHP doet zo vaag, die wacht op de connectie.

In ieders geval geen pconnect gebruiken, daar wordt het zeker niet sneller op in dit soort situaties.

Is het misschien een idee om even met microtime te kijken of inderdaad de functie om verbinding te maken de problemen veroorzaakt? Staat error_reporting verder op e_all en worden er niet allerlei errors in een log geschreven o.i.d.?

[Vm1heA]

Mja, dat is de stelling hier die ODBC koppeling.
Alles draait er nu al op en Oracle blijft zolang het betaalbaar is, zo niet gaat ie eruit.
Dan word het bijv MySQL.

Ik kan er niet omheen met die koppeling, alles is er al op geschreven, dus het moet zo blijven.

[pasz]

Waarom gebruik je dat brakke ODBC, als je ook "native" oracle functions tot je beschikking hebt ?

[Vm1heA]

djluc schreef op 07 juni 2004 @ 15:08:
[...]
In ieders geval geen pconnect gebruiken, daar wordt het zeker niet sneller op in dit soort situaties.

Is het misschien een idee om even met microtime te kijken of inderdaad de functie om verbinding te maken de problemen veroorzaakt? Staat error_reporting verder op e_all en worden er niet allerlei errors in een log geschreven o.i.d.?

Staat aan die reporting.
En ik heb een stuk script gemaakt waar alleen die connectie opbouwen in staat.
Daar wacht ie duidelijk op.
En als je F5 mept een aantal keer dan geeft ie een timeout op de PHP module als response. (30 secs)

[Vm1heA]

PaszWerken schreef op 07 juni 2004 @ 15:10:
Waarom gebruik je dat brakke ODBC, als je ook "native" oracle functions tot je beschikking hebt ?

Dat zeg ik net

[ Voor 52% gewijzigd door Vm1heA op 07-06-2004 15:12 ]

[justmental]

Deze al bekeken?
http://otn.oracle.com/sof...s/odbc/htdocs/ODBCFAQ.pdf
Op blz. 8 staan wat performance tips

[Vm1heA]

Het probleem zelf is Oracle niet.
Het is PHP met ODBC.
Waarom duurt het zo lang voor ie connectie heeft ?

[MarlonB]

Vm1heA schreef op 07 juni 2004 @ 18:20:
Het probleem zelf is Oracle niet.
Het is PHP met ODBC.
Waarom duurt het zo lang voor ie connectie heeft ?

Ik begrijp niet waarom je ODBC wil blijven gebruiken.....het is echt een simpele aanpassing om zonder ODBC te connecten....ergens in een php-page maak je een connectie naar de database, pas deze aan om rechtstreek naar de db te connecten, je hebt geen interface/listener nodig, omdat ze beiden op dezelfde machine draaien...

[Vm1heA]

Connecten is het probleem niet om dat aan te passen.
Maar nu komt het, alle scripts roepen met odbc_ de db aan.
Daar zit ik dus mee.
Dan zou het beteken dat ik de odbc_fetch_row en odbc_exec moet ombouwen naar een inlcude functie of zo.
Dan kan ik dus zo een 800 paginas ombouwen en dat zie ik niet zitten....

[Vm1heA]

justmental schreef op 07 juni 2004 @ 16:48:
Deze al bekeken?
http://otn.oracle.com/sof...s/odbc/htdocs/ODBCFAQ.pdf
Op blz. 8 staan wat performance tips

Ik ga toch eens aan de gang met deze tuningguide.
Kijken of daar iets in te timmeren is.

[Vm1heA]

Ik wil eens rechtsreeks naar Oracle connecten als het kan.
Dus met de PHP Oracle commando's.
Daarvoor heb ik wel 2 dll's nodig. Alleen kan ze nergens vinden.
Wie heeft voor mij deze 2 ddl's :
php_oci8.dll
lphp_oracle.dll

Zie ze her en der met google voorbij komen,maar de downloadsites zijn down of hebben ze niet meer.

[Vm1heA]

Laat maar zitten.....
Heb het probleem gevonden.
Het zal in Oracle zelf in de sqlnet.ora file

sqlnet.authentication_services = (nts) moest zijn (none)

Want ik authentiseer vanuit php zelf en vanuit coldfusion zelf.

Gevonden in de tuningguide van justmental.
Dank voor je guide die je gepost hebt

( intussen wel de hele server verknalt en opnieuw moeten inrichten omdat ik de MS patches eraf haalde en het register sloopte )

[ Voor 6% gewijzigd door Vm1heA op 09-06-2004 10:31 ]