Re: pear on heavy loaded sites

From: Date: Thu, 21 Nov 2002 02:42:27 +0000
Subject: Re: pear on heavy loaded sites
References: 1  Groups: php.pear.dev php.pear.general 
Request: Send a blank email to pear-general+get-2793@lists.php.net to get a copy of this message
Maxim, 03:40:53 21. november 2002 (stvrtok) Greetings. > 1. let developer (who writes directly script codes) manage directly > fetch() function, deciding when reading one rows and another and so on. > this means, if developer do some time-spending operations during a > fetch-cicle, db connection wait with result set stored in B (mysql > buffer). > 2. fetch result set directly into a class object, fetching internally all > result set in an array-object. when developer starts fetch cicle, results > are stored internally in a class object, so mysql connection doesn't > required to be persistent and let buffers free. at least, results are > stored internally by php db buffer (?), but i prefer A goin' slow, than B. > i find out that the 2nd way is better when you have many db connections, > since The main advantage of first aproach is, that you can process rows earlier than RDBMS will finish your query. The RDBMS may be still retrieving result data or sorting result and your script, since it does not wait for last record, can simultaneosly process them, even also send generated partial HTML to client. Note that using this way, sending partial HTML data can cause write() or similar syscall invocation (TCP/IP packet send), thus output buffering is recommended. See John Lim's article about optimalizations for more information about this issue (I forgot URL, but somewhere at phpLens.com). =Nepto= ____________________________________________________________________________ "Be conservative in what you do, be liberal in what you accept from others." (RFC 793: Transmission control protocol; chapter 2.10. Robustness Principle)

« previous php.pear.general (#2793) next »