PDA

Visualizza versione completa : PHP+Apache + connessioni permanenti al DB


EcHo2K
11-05-2001, 16.33.27
vi propongo questo estratto dalle faq di php...

-----

This has to do with the way web servers work. There are three ways
in which your web server can utilize PHP to generate web pages.


The first method is to use PHP as a CGI "wrapper". When run this
way, an instance of the PHP interpreter is created and destroyed for
every page request (for a PHP page) to your web server. Because it
is destroyed after every request, any resources that it acquires (such
as a link to an SQL database server) are closed when it is destroyed.
In this case, you do not gain anything from trying to use persistent
connections -- they simply don't persist.


The second, and most popular, method is to run PHP as a module
in a multiprocess web server, which currently only includes
Apache. A multiprocess server typically has one process (the parent)
which coordinates a set of processes (its children) who actually do
the work of serving up web pages. When each request comes in from a a
client, it is handed off to one of the children that is not already
serving another client. This means that when the same client makes
a second request to the server, it may be serviced by a different
child process than the first time. What a persistent connection does
for you in this case it make it so each child process only needs
to connect to your SQL server the first time that it serves a page
that makes us of such a connection. When another page then requires
a connection to the SQL server, it can reuse the connection that
child established earlier.


The last method is to use PHP as a plug-in for a multithreaded web server. Currently this is only theoretical -- PHP does not
yet work as a plug-in for any multithreaded web servers. Work is
progressing on support for ISAPI, WSAPI, and NSAPI (on Windows),
which will all allow PHP to be used as a plug-in on multithreaded
servers like Netscape FastTrack, Microsoft's Internet Information
Server (IIS), and O'Reilly's WebSite Pro. When this happens, the
behavior will be essentially the same as for the multiprocess model
described before.

-----

ditemi se le mie conclusioni sono giuste...nel caso di PHP+Apache il pconnect apre una connessione permanente per OGNI singolo processo che Apache lancia vero??

quindi e' facile se un server e' sotto un forte carico che Apache lanci molti processi, la machina si potrebbe ritrovare con molte connessioni permanenti aperte delle quali solo una piccolissima parte utilizzate...

ho testato con uno script che mi sono fatto, e le conclusioni mi sembrano giuste...voglio provare con IIS per vedere se si comporta in maniera diversa...

comunque per ora il consiglio e' evitate le pconnect, almeno con apache...come sono realizzate ora in PHP non hanno molto senso perche' servono per ridurre il carico sul server del DB, ma molto facilmente quando si usa Apache lo portano a livelli piu' alti...mah...

EcHo2K
11-05-2001, 16.44.55
ebbene si, con IIS tutto cio' non si verifica, infatti IIS e' monolitico, non si spezzetta come Apache.

Questo mi porta a pensare che il sistema delle connessioni permanenti si PHP si basi sul PID del processo che chima lo script...devo indagare...

quipo.it
11-05-2001, 17.54.32
Non c'entra niente, ma ho sentito oggi che la Debian è tornata al PHP3 perché con PHP4+Apache (solo su Debian) c'era un bug terribile... di più nin so, per ora...

newuser
13-05-2001, 08.56.35
E' un problema un pò oscuro.

Il nodo dovrebbe essere nella diversa gestione delle attività tra i WS.

Apache è descritto come multiprocess server, ossia non sembra in grado di aprire un nuovo thread per ogni istanza richiesta al server di database. Può invece aprire un nuovo processo al di fuori del propio spazio di indirizzamento e prenderne il controllo.

Quindi una volta portata a termine la query il nuovo processo così generato può essere eliminato, come avviene nelle cgi, oppure può essere mantenuto "in vita" in modo da essere utilizzato per richieste successive... Perchè?

Potrebbe essere (forse) un sistema per gestire il load balancing, con l'amministratore che si fa carico di gestire attraverso gli script il numero massimo di istanze al motore di database, evitando il sovraccarico del server a causa di un numero troppo elevato di processi contemporanei.

In ogni caso il problema è alla radice, ossia nel modo in cui l'interprete Perl gestisce le connessioni. Passando per l'api di Apache, al pari di isapi e nsapi, non ci dovrebbero essere difficoltà, a parte la creazione stessa del programma (in C). E'comunque strano che non sia indicata questa possibilità.

IIS e NWS, attraverso le loro api, supportano le richieste in-process, ma dovrebbero comportarsi nello stesso modo utilizzando uno script Perl; nuovo processo e nuova allocazione di risorse. A meno che l'implementazione dell'interprete non sia diversa...

Se (tolgiamo il se, mettiamo siccome) ho detto qualche stupidaggine, chiedo scusa in anticipo! Ciao.

Etabeta
13-05-2001, 12.18.53
sarebbe bello fare un porting di iis per linux :D :D :D

l'altro giorno leggevo di un programma che fa il contrario...adatta programmi per linux per win....mah...

EcHo2K
14-05-2001, 17.40.28
mi sono fatto una pippa mentale stupida...il punto e' che si php collega ogni connessione al DB direttamente con il processi di apache che l'ha aperta, pero' e' anche vero che in httpd.conf posso definire il numero minimo e massimo di processi contemporanei che apache deve girare, come altresi' posso definire il timeout delle connessioni permaneti.
Il problema quindi e' molto minore rispetto alla situazione precedente, resta il fatto che l'implementazione delle connessioni permanenti in php lasci un po a desiderare, dovrebbe esistere sempre una sola connessione permanente aperta, o la limite il numero impostato in qualche varibile di configurazione, altrimenti il concetto di connection pooling va a farsi friggere...