Home > Archive > PHP Pear > October 2005 > Re: [PEAR-DEV] DB_DataObject performance
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: [PEAR-DEV] DB_DataObject performance
|
|
| Bertrand Mansion 2005-10-28, 6:58 pm |
| Olivier Guilyardi wrote:
>Hi,
>
>I've had successful experiences using DB_DataObject on corporate intranets=
,
with
>a few dozens of users. But I'm currently working on a website which may so=
on
>receive about 30000 hits a day (latest evaluation).
>
>Have any of you already used DB_DataObject on high traffic websites ?
>Is there any serious CPU and Memory usage benchmarks out there ?
>
>Here's the implementation choice I'm facing :
>- either use DB_DataObject which relies on DB, DB_Result, etc...
>- or code my own dataobjects which simply encapsulate mysql_* calls
>
>Wether I choose the first or second option, I'll stick with the "dataobjec=
t
>design pattern" as a way to encapsulate the sql code and other smart
behaviours.
DB_DO should be ok for high traffic sites. The bottleneck comes from PEAR D=
B but
it could be worse (for instance, Propel is not usable without a compiler ca=
che).
CRTX_DB is certainly faster as it uses PDO. That is if you use PHP 5 and li=
ve on
the edge. My experiences with PDO show that it is not as stable and consist=
ent
as it should be...
There is also my own solution, Phreez, but I am writing a lot of unit tests
right now and it is not ready for primetime.
Good luck,
--=20
Bertrand Mansion
http://www.mamasam.com - creative internet solutions
http://golgote.freeflux.net - my blog
| |
| Olivier Guilyardi 2005-10-28, 6:58 pm |
| Bertrand Mansion wrote:
> DB_DO should be ok for high traffic sites. The bottleneck comes from PEAR DB but
> it could be worse (for instance, Propel is not usable without a compiler cache).
Wondering how easy it would be to hack DB_DO in order turn all PEAR DB calls
into native mysql_* ones... Maybe that 10 stupid regex based instructions would
do the trick. And if well done, it could be applied to every new DB_DO release...
> CRTX_DB is certainly faster as it uses PDO. That is if you use PHP 5 and live on
> the edge. My experiences with PDO show that it is not as stable and consistent
> as it should be...
PHP4 is one of my customer's requirements.
> There is also my own solution, Phreez, but I am writing a lot of unit tests
> right now and it is not ready for primetime.
Actually, I've already started writing a custom (and sort of optimized)
DataObject base class. What _really_ interests me is the design pattern(s) that
using dataobjects force you to respect. But if possible I'd like to reuse such
stable libs as DB_DataObject.
Btw, never header of Novell Forge. Looks good. Good luck with Phreez.
--
og
|
|
|
|
|