Re: pear on heavy loaded sites
| From: | Ondrej Jombik | 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)