Nell'installazione
quando è utile mettere PERSISTENT DATABASE CONNECTION?
quando no?
grazie
su persistent connection
Moderatore: mod Generali
HO CAPITO VAGAMENTE che PERSISTENT CONNECTION =on è utile quando il tempo per stabilire un link con il db è lungo, altrimenti non vale la pena.
beccatevi questo pezzo di manuale PHP
Persistent connections are SQL links that do not close when the execution of your script ends. When a persistent
connection is requested, PHP checks if there’s already an identical persistent connection (that remained open from
earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An ’identical’ connection is a connection that
was opened to the same host, with the same uname and the same password (where applicable).
People who aren’t thoroughly familiar with the way web servers work and distribute the load may mistake persistent
connects for what they’re not. In particular, they do not give you an ability to open ’user sessions’ on the same SQL
link, they do not give you an ability to build up a transaction efficently, and they don’t do a whole lot of other things. In
fact, to be extremely clear about the subject, persistent connections don’t give you any functionality that wasn’t
possible with their non-persistent brothers.
Why?
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 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.
If persistent connections don’t have any added functionality, what are they good for?
The answer here is extremely simple – efficiency. Persistent connections are good if the overhead to create a link to
your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of
database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the
SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections
help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every
time it processes a page that requires connecting to the SQL server. This means that for every child that opened a
persistent connection will have its own open persistent connection to the server. For example, if you had 20 different
child processes that ran a script that made a persistent connection to your SQL server, you’d have 20 different
connections to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded
by persistant child connections. If your database has a limit of 16 simultaneous connections, and in the course of a
busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which
do not allow the connections to shut down (such as infinite loops), a database with only 32 connections may be rapidly
swamped. Check your database documentation for information on handling abandoned or idle connections.
An important summary. Persistent connections were designed to have one-to-one mapping to regular connections. That
means that you should always be able to replace persistent connections with non-persistent connections, and it won’t
change the way your script behaves. It may (and probably will) change the efficiency of the script, but not its behavior!
beccatevi questo pezzo di manuale PHP
Persistent connections are SQL links that do not close when the execution of your script ends. When a persistent
connection is requested, PHP checks if there’s already an identical persistent connection (that remained open from
earlier) - and if it exists, it uses it. If it does not exist, it creates the link. An ’identical’ connection is a connection that
was opened to the same host, with the same uname and the same password (where applicable).
People who aren’t thoroughly familiar with the way web servers work and distribute the load may mistake persistent
connects for what they’re not. In particular, they do not give you an ability to open ’user sessions’ on the same SQL
link, they do not give you an ability to build up a transaction efficently, and they don’t do a whole lot of other things. In
fact, to be extremely clear about the subject, persistent connections don’t give you any functionality that wasn’t
possible with their non-persistent brothers.
Why?
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 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.
If persistent connections don’t have any added functionality, what are they good for?
The answer here is extremely simple – efficiency. Persistent connections are good if the overhead to create a link to
your SQL server is high. Whether or not this overhead is really high depends on many factors. Like, what kind of
database it is, whether or not it sits on the same computer on which your web server sits, how loaded the machine the
SQL server sits on is and so forth. The bottom line is that if that connection overhead is high, persistent connections
help you considerably. They cause the child process to simply connect only once for its entire lifespan, instead of every
time it processes a page that requires connecting to the SQL server. This means that for every child that opened a
persistent connection will have its own open persistent connection to the server. For example, if you had 20 different
child processes that ran a script that made a persistent connection to your SQL server, you’d have 20 different
connections to the SQL server, one from each child.
Note, however, that this can have some drawbacks if you are using a database with connection limits that are exceeded
by persistant child connections. If your database has a limit of 16 simultaneous connections, and in the course of a
busy server session, 17 child threads attempt to connect, one will not be able to. If there are bugs in your scripts which
do not allow the connections to shut down (such as infinite loops), a database with only 32 connections may be rapidly
swamped. Check your database documentation for information on handling abandoned or idle connections.
An important summary. Persistent connections were designed to have one-to-one mapping to regular connections. That
means that you should always be able to replace persistent connections with non-persistent connections, and it won’t
change the way your script behaves. It may (and probably will) change the efficiency of the script, but not its behavior!