Re: PHP performance
| From: | Eric Butera | Date: | Tue, 04 Mar 2008 02:26:30 +0000 |
| Subject: | Re: PHP performance | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-270893@lists.php.net to get a copy of this message | ||
On Mon, Mar 3, 2008 at 9:21 PM, Chris <dmagick@gmail.com> wrote:
>
> > These 'benefits' you talk about really only matter if you switch your
> > databases. If this app is written against Oracle and they never plan
> > to change it, then it isn't a bad idea to cut out that fat and just
> > deal with the native interface. Even writing wrapper functions that
> > are very basic that abstract mysql_query or mssql_query end up adding
> > a lot of overhead over lots of requests. Look at some of the PDO
> > benchmarks. It is slower than the native functions too because it is
> > just a wrapper.
>
> Using native functions all over the place, how would you log all the
> database queries that a page is running (especially if you don't have
> server-level access, only ftp access - ie a clients server on a shared
> host) ?
>
> Using wrapper functions/classes it's easy to add an error_log call in to
> the 'Query' method to see where everything comes from, and/or how long
> each query takes to run.
>
> Obviously that stuff is disabled by default but with a code change it's
> doing what you need.
>
>
> > Even further if you are writing an app where you care about
> > performance you should be writing your SQL to the point where it
> > really isn't portable using all the little vendor specific features so
> > that you get the most out of it.
>
> Depends on the app I guess, though I haven't seen an app that vendor
> specific (apart from anything to do with full text searching).
>
> Using xdebug is the first step to working out where your real bottleneck
> is - I highly doubt it'll be the wrapper class/functions.
>
> --
>
>
> Postgresql & php tutorials
> http://www.designmagick.com/
>
He said he can't use xdebug.