Connection pooling für PHP

Hi @ all,

also zur vorgeschichte. Ich habe ein Projekt auf dem Tisch in dem ein Kunde seine Webpräsenz mit ca. 4 Mio. PI’s/Tag, die aktuell in Perl und Postgresql ist, auf PHP5(OO, Zend Framework) und Postgresql übersetzt haben will. Dazu möchte er Connection Pooling einsetzten.

Ich persönlich kenne Connection Pooling nur von Java. Deswegen habe ich mich die letzten Tage bereits durch google gwühlt und zwei Möglichkeiten herausgefunden. Die erste nennt sich SQLRelay. Diese Software funktioniert auch sehr gut, was pooling an geht, aber Sie arbeitet nicht mit dem Zend zusammen.

Die zweite Möglichkeit nennt sich pgpool. Das Tool arbeitet sehr gut mit Zend zusammen aber das Pooling funktioniert nicht so wie ich mir das vorgestellt habe. Ich hatte mir das Pooling so viorgestellt, dass beim Start des Dienstes ein gewisse menge an Pools aufgebaut werden. Wenn dann später mehr pools benötigt werden, baut der Dienst weitere auf. Diese beendet der Dienst dann Automatisch nach einer gewissen Zeit des nicht verwendens wieder. Mit meiner aktuellen Konfiguration baut der Dienst die Connection erst auf wenn ich eine Anfrage starte und dann auch nur bis zu einenm bestimmten Limit(Was auch nicht schlecht ist). Aber beendet Sie nicht automatisch. Ich habe es nur hinbekommen das er alle nach einer gewissen Zeit wieder schließt. Kann mir jemand helfen die Konfiguration richtig hin zu bekommen?

Hier meine Konfiguration:

#
# pgpool configuration file
#

# Host name or IP address to listen on: '*' for all, '' for no TCP/IP
# connections
listen_addresses = 'localhost'

# Port number for pgpool
port = 5433

# Unix domain socket path.  (The Debian package defaults to
# /var/run/postgresql.)
socket_dir = '/var/run/postgresql'

# Host name where PostgreSQL server is running on.  '' means localhost
# using Unix domain socket.
backend_host_name = ''

# port number PostgreSQL server is running on
backend_port = 5432

# Unix domain socket path for the backend.  (The Debian package defaults
# to /var/run/postgresql.)
backend_socket_dir = '/var/run/postgresql'

# Host name where secondary PostgreSQL server is running on.  '' means
# localhost using Unix domain socket.
secondary_backend_host_name = ''

# Port number secondary PostgreSQL server is running on.  0 means no
# secondary PostgreSQL.
secondary_backend_port = 0

# Number of pre-forked child processes
num_init_children = 4

# Number of connection pools allowed for a child process
max_pool = 2

# If idle for this many seconds, child exits.  0 means no timeout.
child_life_time = 0

# If idle for this many seconds, connection to PostgreSQL closes.
# 0 means no timeout.
connection_life_time = 0

# If child_max_connections connections were received, child exits.
# 0 means no exit.
child_max_connections = 10

# Logging directory (more accurately, the directory for the PID file)
logdir = '/var/run/postgresql'

# Replication mode
replication_mode = false

# Set this to true if you want to avoid deadlock situations when
# replication is enabled.  There will, however, be a noticable performance
# degration.  A workaround is to set this to false and insert a /*STRICT*/
# comment at the beginning of the SQL command.
replication_strict = true

# When replication_strict is set to false, there will be a chance for
# deadlocks.  Set this to nonzero (in milliseconds) to detect this
# situation and resolve the deadlock by aborting current session.
replication_timeout = 5000

# Load balancing mode, i.e., all SELECTs except in a transaction block
# are load balanced.  This is ignored if replication_mode is false.
load_balance_mode = false

# Load balance weight for master and secondary.  The actual weight is
# calculated by weight_master divided by weight_secondary.  For
# example both
#
# weight_master = 10 and weight_secondary = 5
# weight_master = 4 and weight_secondary = 2
#
# are regarded as the master having double the weight compared to the
# secondary.  Master and secondary have the same weight in the default.
weight_master = 0.5
weight_secondary = 0.5

# If there is a data mismatch between master and secondary, start
# degeneration to stop replication mode.
replication_stop_on_mismatch = false

# Semicolon separated list of queries to be issued at the end of a session
reset_query_list = 'ABORT; RESET ALL; SET SESSION AUTHORIZATION DEFAULT'

# If true print time stamp on each log line.
print_timestamp = true

# If true, operate in master/slave mode.
master_slave_mode = false

# If true, cache connection pool.
connection_cache = true

# Health check timeout.  0 means no timeout.
health_check_timeout = 20

# Health check period.  0 means no health check.
health_check_period = 0

# Health check user
health_check_user = 'nobody'

# If true, automatically lock table with INSERT statements to keep SERIAL
# data consistency.  An /*INSERT LOCK*/ comment has the same effect.  A
# /NO INSERT LOCK*/ comment disables the effect.
insert_lock = false

# If true, ignore leading white spaces of each query while pgpool judges
# whether the query is a SELECT so that it can be load balanced.  This
# is useful for certain APIs such as DBI/DBD which is known to adding an
# extra leading white space.
ignore_leading_white_space = false

# If true, print all statements to the log.  Like the log_statement option
# to PostgreSQL, this allows for observing queries without engaging in full
# debugging.
log_statement = true

Konfigurationshilfe: pgpool-II README


Ich muss es so hinbekommen, dass beim Start des Dienstes 3 Verbindungen aufgebaut werden und diese auch immer fest zur verfügung stehen. Weiterhin soll der Dienst bei z.B. 4 gleichen Zugriffen weitere Connections aufbauen und diese dann nach 15 Sek. des nicht verwendens wieder geschlossen werden. Das Schließen der zusätzlichen Connections darf natürlich nicht die 3 Connections, vom Start des Dienstes, beeinflussen.

Hat hier vielleicht noch jemand eine Idee wie ich das Problem glöst bekomme?

Schon einmal danke im Voraus!


Sebastian

Das ist Sache deiner Applikation

Weiterhin soll der Dienst bei z.B. 4 gleichen Zugriffen weitere Connections aufbauen und diese dann nach 15 Sek. des nicht verwendens wieder geschlossen werden. Das Schließen der zusätzlichen Connections darf natürlich nicht die 3 Connections, vom Start des Dienstes, beeinflussen.

Also ich haben mich noch nie mit pg_pool beschäftigt (mangels Notwendigkeit), aber wie kommst du auf den Trichter, dass ungenutzte Connections nicht geschlossen werden? (Dem ist so eigentlich nicht)

Ich würde mal tippen, dass du entweder einen PConnect durchführst (PERSITENT COINNECION) oder deine Connection in der APP nicht schließt …(auch eigentlich Sache der Applikation).

Was für n DB Abstraction Layer verwendest du?

Grüße Jochen