Re: [PHP-DB] oracle pooling
On Tue, Dec 2, 2008 at 6:16 PM, Christopher Jones [EMAIL PROTECTED] wrote: Themis Vassiliadis wrote: On Tue, Dec 2, 2008 at 4:18 PM, Christopher Jones [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Oracle 11g DRCP support is available in PHP. See this whitepaper: http://www.oracle.com/technology/tech/php/pdf/php-scalability-ha-twp.pdf Change the connection string slightly, and set one new php.ini parameter to use it. Chris I think that DRCP is a work around solution. I disagree. It is a major technology feature that enables pooling for a wide variety of client programs. It is extremely scalable. The whitepaper shows results from a small, commodity computer handling 20,000 concurrent connections. Of course is much better than traditional connections as we had before 11G. But I think that is really possible to develop a new extension working like Java component Apache DBCP. This is a traditional pooling mechanism, where is defined in a xml file the pooling description and it is ensured that just applications behind Tomcat will use the pool. The advantage of DRCP is precisely that it is server side: all your mid-tier application servers share the one pool on the DB server. It becomes easier to add web server machines, and their configuration is simpler. So if imbedded in an extension, the pool will start just when apache starts, and will down when apache stops. And the whole pooling definition will be at the client side. The main problem with mid-tier multi-threaded pooling solutions is that PHP is mostly run single-threaded because some PHP extensions are not thread safe. Pooling is a solution created for web applications, the DRCP, if I'm not wrong, should be used from web and client applications like SQL Plus. They just need to select the TNSNAME key and use the pool. When the DRCP server pool is started, applications can choose to use it, or they can continue to use dedicated connections if they want. Chris -- Email: [EMAIL PROTECTED] Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/f8jad DRCP is really a big improvement. But for me it has a great holdback: the pool controlled in the server side isn't defined for a specific schema, so if we have an application server serving different connections demanding different credentials certainly the performance will be worse. Another big problem is that one application hosted in the web server can lock the pool completely is the demand for this application improve. In other hands if we work with traditional pooling, configured in the client side, we should define one pool for each aplication with his own credentials. The pool will never blocked by one system and for hosts with several credentials the performance will be better. The performance and availability will be insured. Of corse both are good solutions, each one for your specific purpose. -- Themis Vassiliadis
Re: [PHP-DB] oracle pooling
DRCP is really a big improvement. But for me it has a great holdback: the pool controlled in the server side isn't defined for a specific schema, so if we have an application server serving different connections demanding different credentials certainly the performance will be worse. Another big problem is that one application hosted in the web server can lock the pool completely is the demand for this application improve. In other hands if we work with traditional pooling, configured in the client side, we should define one pool for each aplication with his own credentials. The pool will never blocked by one system and for hosts with several credentials the performance will be better. The performance and availability will be insured. Of corse both are good solutions, each one for your specific purpose. You have to make a change to the php code (the tns definition) to use pooling - it's not going to use pooling just because you enable it. -- Postgresql php tutorials http://www.designmagick.com/ -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] oracle pooling
Themis Vassiliadis wrote: DRCP is really a big improvement. But for me it has a great holdback: the pool controlled in the server side isn't defined for a specific schema, so if we have an application server serving different connections demanding different credentials certainly the performance will be worse. Another big problem is that one application hosted in the web server can lock the pool completely is the demand for this application improve. Pooled servers are internally sub-partitioned by user. See figure 3 in http://www.oracle.com/technology/tech/php/pdf/php-scalability-ha-twp.pdf This allows maximum reuse of pooled users for similar connections. DRCP is perfectly suited for systems with several credentials. I agree that if each and every connection comes in as a separate user then the benefits of DRCP will be reduced. But is conceivable in some cases that you can still take advantage of the already running server processes. In other hands if we work with traditional pooling, configured in the client side, we should define one pool for each aplication with his own credentials. The pool will never blocked by one system and for hosts with several credentials the performance will be better. The performance and availability will be insured. The DRCP pool is efficient and doesn't require many servers to handle load. Of course, this is application dependent. The worst case is a temporary shortage of pooled servers. Requests will block until a pooled server is free. But you can set the maximum number of pooled servers as high as your system limitations allow. This ensures the DB is still able to process requests without being totally overloaded. When load does decrease, the pool will shrink. Of corse both are good solutions, each one for your specific purpose. I agree that each application architecture may perform better with one or other solution. If you get a chance to try DRCP, let me know your experience. Chris -- Email: [EMAIL PROTECTED] Tel: +1 650 506 8630 Twitter: http://twitter.com/ghrdFree PHP Book: http://tinyurl.com/f8jad -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
