Re: [PHP] PHP performance profiling

[TG]

- Original Message -
From: "Eric Butera" <[EMAIL PROTECTED]>
To: Gryffyn <[EMAIL PROTECTED]>
Cc: php-general@lists.php.net
Date: Tue, 18 Nov 2008 12:16:04 -0500
Subject: Re: [PHP] PHP performance profiling

> On Tue, Nov 18, 2008 at 10:11 AM, Gryffyn
> <[EMAIL PROTECTED]> wrote:
> > I did a search and didn't find anything really astounding sounding, so I
> > wanted to ask for some "live" recommendations from the crowd here.
> >
> > I was wondering if anyone had used FirePHP with Firebug or could 
recommend a
> > good profiling method for figuring out where the slow parts of your PHP
> > code are.
> >
> > I'm curious about solutions that don't require installing something on the
> > server side, since that's not usually an option with shared web hosting 
and
> > all.
> >
> > I used to love Zend Studio's server component along with the IDE, but it
> > doesn't help so much with shared web hosts where you can't install the
> > server component.
> >
> > Ideally, I'd love to see what segments of the code are running slow, but 
at
> > the very minimum, I want to see if it's the PHP code or the MySQL calls
> > that are slow.   I know I can just add my own statements in the code, but 
I
> > was hoping there was a more comprehensive solution available.
> >
> > Thanks in advance.
> >
> > -TG
> 
> If you cannot install stuff on your server, set yourself up a local
> dev environment.  You should really be doing this anyways.  One of the
> easiest ways to do this is to download a pre-made vmware player server
> application.  Or you could do the xampp thing.
> 
> Once you have that you can use xdebug [1] to profile your code.  It
> has a lot of various ways of profiling.  It doesn't require you
> modifying your code at all.  Then it generates these files that you
> can use kcachegrind/wincachegrind to see every single function your
> script calls, how long it took, etc.  There's also another tool to
> view these files called webgrind[2]
> 
> [1] http://www.xdebug.org/docs/profiler
> [2] http://code.google.com/p/webgrind/
> 

I'm not as worried about profiling the code itself as it's execution in it's 
final environment.  So setting up a test on my local machine isn't going to 
give me what I want.  It's a good idea, and I definitely use VMWare 
appliances for a few things (particulary testing in various browser 
versions that don't always like to be installed next to each other).

I forgot about xdebug and haven't checked out webgrind yet.  Thanks for the 
recommendations!

And thanks to Nathan for the other recommendations.

To get really good profiling feedback, control of the server is probably 
necessary.  But if there was something that got me close without messing 
with the server, I figured it was worth asking about.

-TG

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance profiling

[Eric Butera]

On Tue, Nov 18, 2008 at 10:11 AM, Gryffyn
<[EMAIL PROTECTED]> wrote:
> I did a search and didn't find anything really astounding sounding, so I
> wanted to ask for some "live" recommendations from the crowd here.
>
> I was wondering if anyone had used FirePHP with Firebug or could recommend a
> good profiling method for figuring out where the slow parts of your PHP
> code are.
>
> I'm curious about solutions that don't require installing something on the
> server side, since that's not usually an option with shared web hosting and
> all.
>
> I used to love Zend Studio's server component along with the IDE, but it
> doesn't help so much with shared web hosts where you can't install the
> server component.
>
> Ideally, I'd love to see what segments of the code are running slow, but at
> the very minimum, I want to see if it's the PHP code or the MySQL calls
> that are slow.   I know I can just add my own statements in the code, but I
> was hoping there was a more comprehensive solution available.
>
> Thanks in advance.
>
> -TG
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

If you cannot install stuff on your server, set yourself up a local
dev environment.  You should really be doing this anyways.  One of the
easiest ways to do this is to download a pre-made vmware player server
application.  Or you could do the xampp thing.

Once you have that you can use xdebug [1] to profile your code.  It
has a lot of various ways of profiling.  It doesn't require you
modifying your code at all.  Then it generates these files that you
can use kcachegrind/wincachegrind to see every single function your
script calls, how long it took, etc.  There's also another tool to
view these files called webgrind[2]

[1] http://www.xdebug.org/docs/profiler
[2] http://code.google.com/p/webgrind/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance profiling

[Richard Heyes]

> I'm curious about solutions that don't require installing something on the
> server side, since that's not usually an option with shared web hosting and
> all.

Since PHP runs on the server, as part of the webserver, I think it
will be inevitable that you'll need to install something on your
server.

-- 
Richard Heyes

HTML5 Graphing for FF, Chrome, Opera and Safari:
http://www.rgraph.org (Updated November 15th)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] PHP performance profiling

[Gryffyn]

I did a search and didn't find anything really astounding sounding, so I 
wanted to ask for some "live" recommendations from the crowd here.

I was wondering if anyone had used FirePHP with Firebug or could recommend a 
good profiling method for figuring out where the slow parts of your PHP 
code are.

I'm curious about solutions that don't require installing something on the 
server side, since that's not usually an option with shared web hosting and 
all.

I used to love Zend Studio's server component along with the IDE, but it 
doesn't help so much with shared web hosts where you can't install the 
server component.

Ideally, I'd love to see what segments of the code are running slow, but at 
the very minimum, I want to see if it's the PHP code or the MySQL calls 
that are slow.   I know I can just add my own statements in the code, but I 
was hoping there was a more comprehensive solution available.

Thanks in advance.

-TG

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RES: [PHP] PHP performance

[Thiago Pojda]

De: Richard Lynch [mailto:[EMAIL PROTECTED] 

#1
Get the code, install it on a box in the closet, run valgrind 
--callgrind

This will give you a stack trace of what gets called the MOST 
in your application.

Look for "tall" trees in the call graph, and fix those first.

#2
You can use 'ab' (apache benchmark) or similar to test it externally.

#3
You can also script things with Selenium IDE and then use 
Selenium remote control to run them repeatedly, for the 
end-user experience.

Don't let server non-access stop you from doing #1 though...





  Sweet!

  I'll be trying those tools, Richard. Thanks :)

  Installing xdebug is getting rougher than expected as it's a RHEL4AS, php
4.3.4 w/o php-devel and a screwed up gcc :/


  I'll let you know what worked for me.


  Thiago




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Richard Lynch]

#1
Get the code, install it on a box in the closet, run valgrind --callgrind

This will give you a stack trace of what gets called the MOST in your
application.

Look for "tall" trees in the call graph, and fix those first.

#2
You can use 'ab' (apache benchmark) or similar to test it externally.

#3
You can also script things with Selenium IDE and then use Selenium
remote control to run them repeatedly, for the end-user experience.

Don't let server non-access stop you from doing #1 though...

On Mon, March 3, 2008 11:09 am, Thiago Pojda wrote:
> Guys,
>
> I've been asked to build a performance report for a PHP app. I can't
> profile
> it using automated tools as I don't have full access to the server,
> only to
> the application itself.
>
> It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer
> with
> a Oracle 8i databse. The system also uses a VB.NET socket server for
> some
> data manipulation.
>
> As for migrating to PHP5 I think it's crucial, but I need facts that
> it
> really runs faster than PHP4. Anyone? :)
>
> Any ideas on what might be the bottleneck?
>
> Thanks guys
>
> Atenciosamente,
>
>
>   www.softpartech.com.br
>
>
> Thiago Henrique Pojda
> Desenvolvimento Web
> +55 41 3033-7676
> [EMAIL PROTECTED]
> Excelência em Softwares Financeiros
>
>
>


-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/from/lynch
Yeah, I get a buck. So?


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Jochem Maas]

Eric Butera schreef:

On Tue, Mar 4, 2008 at 5:51 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:

Eric Butera schreef:



...



--
 PHP General Mailing List (http://www.php.net/)
 To unsubscribe, visit: http://www.php.net/unsub.php




Hi Jochem,

This is probably true.  I was just referring to an old benchmark [1] I
had seen a few years ago.

Of course the biggest win will come from an opcode cache if that is a
possibility.

Just for the record I do use a db wrapper myself but I have weighed
the pros and cons of the situation and determined that it works for
me.  I have many low traffic sites so it makes sense to have a wrapper
that delays connections until they're used and such other little
tweaks.

I listen to peoples recoded talks from conferences and I've heard on
many occasions that on single apps they take out the db abstraction.
I wish I could cite references but it is out there if you want to dig
enough.


duh. ofcourse they do that. remove a layer of abstraction and win some speed.
it a game of dimishing returns, take the big target first - that's usually the
SQL queries, DB tuning. next step might be op-code caching, then data/output 
caching,
and if that's not enough (or you have enough iron in play to make the numbers 
add up)
you start to remove maintainability and/or abstraction from your code to win a 
few
cpu cycles.

php is web-glue, or for the purposes of my metaphor web-butter ... generally the
sandwich is mostly filled with something other than butter.



[1] http://phplens.com/lens/adodb/




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Eric Butera]

On Tue, Mar 4, 2008 at 5:51 AM, Jochem Maas <[EMAIL PROTECTED]> wrote:
> Eric Butera schreef:
>
>
> > On Mon, Mar 3, 2008 at 6:18 PM, Chris <[EMAIL PROTECTED]> wrote:
>  >>  > Just FYI, using ADODB will slow down the performance of your app.  Any
>  >>  > function calls cost against you and it all adds up.
>  >>
>  >>  If you remove it, then you remove functionality - so before you go and
>  >>  rip it out, check whether it's the bottleneck using xdebug.
>  >>
>  >>  I use an abstraction layer all the time and the benefits far outweigh
>  >>  the 'costs'.
>  >>
>  >>  --
>  >>  Postgresql & php tutorials
>  >>  http://www.designmagick.com/
>  >>
>  >
>  > Hi Chris,
>  >
>  > 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.
>  >
>  > 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.
>  >
>  > From my personal profiling most of my application time is spent in
>  > data access.  So the less layers you have there the faster it runs.
>
>  the adodb php layers are insignificant compared to the cost of the db 
> connection
>  and the round trip to retrieve data from the db. the significant application 
> time
>  you speak of is undoubtly spent at the database performing and retrieving the
>  data as opposed to measurable overhead caused by a [number of] wrapper 
> function[s].
>
>  high probability that SQL related tweaks (indexing, query restructuring, db 
> tuning)
>  will win you much, much more than removing any db abstraction layer
>
>
>  >
>  > But that is just my 2cents on it.  :)
>  >
>
>
>
>
> --
>  PHP General Mailing List (http://www.php.net/)
>  To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Hi Jochem,

This is probably true.  I was just referring to an old benchmark [1] I
had seen a few years ago.

Of course the biggest win will come from an opcode cache if that is a
possibility.

Just for the record I do use a db wrapper myself but I have weighed
the pros and cons of the situation and determined that it works for
me.  I have many low traffic sites so it makes sense to have a wrapper
that delays connections until they're used and such other little
tweaks.

I listen to peoples recoded talks from conferences and I've heard on
many occasions that on single apps they take out the db abstraction.
I wish I could cite references but it is out there if you want to dig
enough.

[1] http://phplens.com/lens/adodb/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: RES: [PHP] PHP performance

[Nathan Rixham]

Thiago Pojda wrote:

-Mensagem original-
De: Jochem Maas [mailto:[EMAIL PROTECTED] 
Eric Butera schreef:

On Mon, Mar 3, 2008 at 6:18 PM, Chris <[EMAIL PROTECTED]> wrote:
 > Just FYI, using ADODB will slow down the performance of your app.  
Any  > function calls cost against you and it all adds up.


 If you remove it, then you remove functionality - so before you go 
and  rip it out, check whether it's the bottleneck using xdebug.


 I use an abstraction layer all the time and the benefits far 
outweigh  the 'costs'.


 --
 Postgresql & php tutorials
 http://www.designmagick.com/


Hi Chris,

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.


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.

From my personal profiling most of my application time is spent in 
data access.  So the less layers you have there the faster it runs.


the adodb php layers are insignificant compared to the cost of 
the db connection and the round trip to retrieve data from the 
db. the significant application time you speak of is undoubtly 
spent at the database performing and retrieving the data as 
opposed to measurable overhead caused by a [number of] wrapper 
function[s].


high probability that SQL related tweaks (indexing, query 
restructuring, db tuning) will win you much, much more than 
removing any db abstraction layer



But that is just my 2cents on it.  :)




First of all, thanks for helping me out :)

The vb.net stuff does a lot of business and database stuff, it's
really tied up with the app. Actually I've no idea how it works internally,
all I know is that we send data strings via socket and it returns the
results the same way. It's kind of a black box. :/

I'm going for:
Tune SQL and move a lot of heavy queries directly to
procedures/functions in BD
Tune apache
Perhaps switch from PHP4=>5 (if I'm allowed to)
Try memchache

We had a talk with a sysadmin and tried installing xdebug in the
server, but it's a RHEL4AS w/o php-devel packages (phpize) and we can't find
a RPM for that anyone? :)


Thiago




if its a plesk box, save yourself the time [and the company your wages] 
and get a new rhel5 box (if you must stay rhel).


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RES: [PHP] PHP performance

[Thiago Pojda]

-Mensagem original-
De: Jochem Maas [mailto:[EMAIL PROTECTED] 
Eric Butera schreef:
> On Mon, Mar 3, 2008 at 6:18 PM, Chris <[EMAIL PROTECTED]> wrote:
>>  > Just FYI, using ADODB will slow down the performance of your app.  
>> Any  > function calls cost against you and it all adds up.
>>
>>  If you remove it, then you remove functionality - so before you go 
>> and  rip it out, check whether it's the bottleneck using xdebug.
>>
>>  I use an abstraction layer all the time and the benefits far 
>> outweigh  the 'costs'.
>>
>>  --
>>  Postgresql & php tutorials
>>  http://www.designmagick.com/
>>
> 
> Hi Chris,
> 
> 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.
> 
> 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.
> 
> From my personal profiling most of my application time is spent in 
> data access.  So the less layers you have there the faster it runs.

the adodb php layers are insignificant compared to the cost of 
the db connection and the round trip to retrieve data from the 
db. the significant application time you speak of is undoubtly 
spent at the database performing and retrieving the data as 
opposed to measurable overhead caused by a [number of] wrapper 
function[s].

high probability that SQL related tweaks (indexing, query 
restructuring, db tuning) will win you much, much more than 
removing any db abstraction layer

> 
> But that is just my 2cents on it.  :)
> 


First of all, thanks for helping me out :)

The vb.net stuff does a lot of business and database stuff, it's
really tied up with the app. Actually I've no idea how it works internally,
all I know is that we send data strings via socket and it returns the
results the same way. It's kind of a black box. :/

I'm going for:
Tune SQL and move a lot of heavy queries directly to
procedures/functions in BD
Tune apache
Perhaps switch from PHP4=>5 (if I'm allowed to)
Try memchache

We had a talk with a sysadmin and tried installing xdebug in the
server, but it's a RHEL4AS w/o php-devel packages (phpize) and we can't find
a RPM for that anyone? :)


Thiago



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Jochem Maas]

Eric Butera schreef:

On Mon, Mar 3, 2008 at 6:18 PM, Chris <[EMAIL PROTECTED]> wrote:

 > Just FYI, using ADODB will slow down the performance of your app.  Any
 > function calls cost against you and it all adds up.

 If you remove it, then you remove functionality - so before you go and
 rip it out, check whether it's the bottleneck using xdebug.

 I use an abstraction layer all the time and the benefits far outweigh
 the 'costs'.

 --
 Postgresql & php tutorials
 http://www.designmagick.com/



Hi Chris,

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.

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.

From my personal profiling most of my application time is spent in
data access.  So the less layers you have there the faster it runs.


the adodb php layers are insignificant compared to the cost of the db connection
and the round trip to retrieve data from the db. the significant application 
time
you speak of is undoubtly spent at the database performing and retrieving the
data as opposed to measurable overhead caused by a [number of] wrapper 
function[s].

high probability that SQL related tweaks (indexing, query restructuring, db 
tuning)
will win you much, much more than removing any db abstraction layer



But that is just my 2cents on it.  :)




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: RES: [PHP] PHP performance

[Chris]

I have a copy of the files and database, but setting it up is not that
simple. This vb.net is licensed and we don't have license for.

If I could profile the app I'd be more than happy, but that's not going to
happen anytime soon.


What does the vb.net stuff do? Is it the frontend (eg for data-entry) or 
is it used on the server-side of things?


Can you profile the php app separate to the vb.net stuff?


First step is usually the database.

Get adodb (either hack it or see if it has an on/off setting for this) 
to log all of your db queries and see if any are missing indexes or need 
attention.


--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Eric Butera]

On Mon, Mar 3, 2008 at 9:21 PM, Chris <[EMAIL PROTECTED]> 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.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Chris]

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/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Eric Butera]

On Mon, Mar 3, 2008 at 6:18 PM, Chris <[EMAIL PROTECTED]> wrote:
>
>  > Just FYI, using ADODB will slow down the performance of your app.  Any
>  > function calls cost against you and it all adds up.
>
>  If you remove it, then you remove functionality - so before you go and
>  rip it out, check whether it's the bottleneck using xdebug.
>
>  I use an abstraction layer all the time and the benefits far outweigh
>  the 'costs'.
>
>  --
>  Postgresql & php tutorials
>  http://www.designmagick.com/
>

Hi Chris,

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.

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.

>From my personal profiling most of my application time is spent in
data access.  So the less layers you have there the faster it runs.

But that is just my 2cents on it.  :)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Chris]

Just FYI, using ADODB will slow down the performance of your app.  Any
function calls cost against you and it all adds up.


If you remove it, then you remove functionality - so before you go and 
rip it out, check whether it's the bottleneck using xdebug.


I use an abstraction layer all the time and the benefits far outweigh 
the 'costs'.


--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Aschwin Wesselius]

Thiago Pojda wrote:

Guys,
 
I've been asked to build a performance report for a PHP app. I can't profile

it using automated tools as I don't have full access to the server, only to
the application itself.
 
It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with

a Oracle 8i databse. The system also uses a VB.NET socket server for some
data manipulation.
 
As for migrating to PHP5 I think it's crucial, but I need facts that it

really runs faster than PHP4. Anyone? :)
 
Any ideas on what might be the bottleneck?


Hi Thiago,

I think it depends on what the application does. You can't just point 
out a bottleneck just by saying which parts are used.


You can however put little timing functions here and there to measure 
which part of an application is taking too long.


Like this:

$s = microtime();

do_some_stuff();
do_some_more_stuff();

$f = microtime();

echo ($f - $s)."\n";

This is very simple benchmarking and you need a lot of these steps to 
really get some idea where the bottleneck could be. A good start would 
be nearby query execution and results another would be with file access 
or remote connections. Also good to investigate are huge loops, huge 
arrays that are iterated over etc.


Do this step by step so you are sure which part you are investigating. 
Otherwise you have 10 steps, 10 results and you don't know anymore where 
to look.


Good luck.

Aschwin Wesselius


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RES: [PHP] PHP performance

[Thiago Pojda]

-Mensagem original-
De: Eric Butera [mailto:[EMAIL PROTECTED] 


On Mon, Mar 3, 2008 at 12:09 PM, Thiago Pojda 
<[EMAIL PROTECTED]> wrote:
> Guys,
>
>  I've been asked to build a performance report for a PHP app. I can't 
> profile  it using automated tools as I don't have full access to the 
> server, only to  the application itself.
>
>  It's a PHP4 Object-Oriented app, which uses ADODB as abstraction 
> layer with  a Oracle 8i databse. The system also uses a VB.NET socket 
> server for some  data manipulation.
>
>  As for migrating to PHP5 I think it's crucial, but I need facts that 
> it  really runs faster than PHP4. Anyone? :)
>
>  Any ideas on what might be the bottleneck?
>
>  Thanks guys
>

Try and get a copy of the files and database, then set it up on 
your dev machine.  Then profile using Xdebug.

If you're looking for comparison numbers maybe look at:
http://sebastian-bergmann.de/archives/745-Benchmark-of-PHP-Branc
hes-3.0-through-5.3-CVS.html

Just FYI, using ADODB will slow down the performance of your 
app.  Any function calls cost against you and it all adds up.




I have a copy of the files and database, but setting it up is not that
simple. This vb.net is licensed and we don't have license for.

If I could profile the app I'd be more than happy, but that's not going to
happen anytime soon.

Thanks for those numbers, they'll be handy :)

ADODB removal will be studied, thanks for the hint!


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Eric Butera]

On Mon, Mar 3, 2008 at 12:09 PM, Thiago Pojda
<[EMAIL PROTECTED]> wrote:
> Guys,
>
>  I've been asked to build a performance report for a PHP app. I can't profile
>  it using automated tools as I don't have full access to the server, only to
>  the application itself.
>
>  It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with
>  a Oracle 8i databse. The system also uses a VB.NET socket server for some
>  data manipulation.
>
>  As for migrating to PHP5 I think it's crucial, but I need facts that it
>  really runs faster than PHP4. Anyone? :)
>
>  Any ideas on what might be the bottleneck?
>
>  Thanks guys
>
>  Atenciosamente,
>
>
>    www.softpartech.com.br
>
>
>  Thiago Henrique Pojda
>  Desenvolvimento Web
>  +55 41 3033-7676
>  [EMAIL PROTECTED]
>  Excelência em Softwares Financeiros
>
>
>

Try and get a copy of the files and database, then set it up on your
dev machine.  Then profile using Xdebug.

If you're looking for comparison numbers maybe look at:
http://sebastian-bergmann.de/archives/745-Benchmark-of-PHP-Branches-3.0-through-5.3-CVS.html

Just FYI, using ADODB will slow down the performance of your app.  Any
function calls cost against you and it all adds up.

[PHP] PHP performance

[Thiago Pojda]

Guys,
 
I've been asked to build a performance report for a PHP app. I can't profile
it using automated tools as I don't have full access to the server, only to
the application itself.
 
It's a PHP4 Object-Oriented app, which uses ADODB as abstraction layer with
a Oracle 8i databse. The system also uses a VB.NET socket server for some
data manipulation.
 
As for migrating to PHP5 I think it's crucial, but I need facts that it
really runs faster than PHP4. Anyone? :)
 
Any ideas on what might be the bottleneck?
 
Thanks guys

Atenciosamente,


  www.softpartech.com.br


Thiago Henrique Pojda
Desenvolvimento Web
+55 41 3033-7676
[EMAIL PROTECTED]
Excelência em Softwares Financeiros

 

Re: [PHP] PHP Performance and System Load

[Nathan Nobbe]

on the point of class size; i think this is more a design issue than a
performance issue.
i worked at a place where we had several files w/ classes that were several
thousand lines in size.
one i remember was over 6000 lines long.  personally i would never let
something grow that large,
but all im saying is we had large classes like that and the system wasnt
crawling.

-nathan

On 7/20/07, Larry Garfield <[EMAIL PROTECTED]> wrote:


On Friday 20 July 2007, Sascha Braun, CEO @ ejackup.com wrote:
> Dear People,

> The webserver does only contain the webspace filesystem structure as
> well as 5 line of PHP Code dummies, for every document in the content
> management system, to avoid the usage of mod_rewrite.

I inherited a CMS at work that did that.

Stop.  Now.  Use mod_rewrite.  You'll live longer and spend less on
hair-regrowth medication.

mod_rewrite is not itself a huge performance hit.  If you're on a
dedicated
server then you can move the mod_rewrite directive to the apache.conf file
and disable .htaccess files, which can give you a performance boost, but
if a
reasonably simple mod_rewrite is the difference that is killing your
server
then you need to rethink your server.  It's a minor issue.  You'll get a
better performance gain out of a slightly faster processor.

Your PHP coding style itself likely has little if any impact on
performance.
pre vs. post increment is going to be a tiny fraction of a percent
compared
to the time taken to parse code, hit the database, hit the disk, etc.

As others have said, benchmark benchmark benchmark.  As a general
guideline,
the big performance killers I've run in to include:

- Parsing.  Opcode cache is good, but if you can give it less to cache
that
helps, too.  You said you're already using autoload(), which helps, but
make
sure that you're not loading gobs of code that you don't use.  Even with
an
opcode cache, that will eat up RAM.

- SQL in loops.  Never do this.

- Cache pretty much everything that you get back from the database if you
can,
using a static variable.  (Not a global; a static variable local to a
function or method, or a private class variable.)  If you're loading
complex
objects, cache the fully prepared version.  That not only provides a
performance boost, but also provides you with a good
single-point-of-optimization because it's then much easier to shift that
from
a static variable or static array to a memcached storage.

- Limit your individual transfers.  Oft-forgotten, but remember that every
file the browser has to request is another HTTP hit on the server.  Even
if
the response from the server is "nope, no change", it's still an HTTP hit.
That can really hurt your effective performance, both on the server side
and
client side.  Merge your CSS and JS into as few files as reasonable, even
if
that means that you send more than you need to on the first page
request.  It
helps overall.  You can do that manually or automatically.  (Drupal, for
instance, auto-aggregates CSS and in the next version will auto-aggregate
JS,
too.  That's been a big performance boost.)  The same goes for image
files.

- Apropos of the last, Firebug!  The latest version has a great profiler
that
can show you how long each HTTP request takes.  You may find that you
spend
most of your browser-load time on things that don't involve PHP at all.

- EXPLAIN your SQL.  That is, the MySQL EXPLAIN command prefixed to any
SELECT
query will tell you how MySQL is going to parse and process it.  Odds are
good that adding a few well-placed keys/indexes will make your SQL an
order
of magnitude faster or more.  Also, watch out for filesort.  Any time a
query
has to do a filesort, it gets slow.  It always has to filesort if you are
doing a WHERE and ORDER BY that use fields in different tables.  Avoid
that
if you can.  Much more information in a MySQL group. :-)

Again, benchmark it from every direction you can.  Odds are, though, that
your
PHP code itself is not the bottleneck but the server configuration, SQL
server, HTTP traffic, etc. are where you're really dying.

Cheers.

--
Larry Garfield  AIM: LOLG42
[EMAIL PROTECTED]  ICQ: 6817012

"If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the
possession
of every one, and the receiver cannot dispossess himself of it."  --
Thomas
Jefferson

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Performance and System Load

[Larry Garfield]

On Friday 20 July 2007, Sascha Braun, CEO @ ejackup.com wrote:
> Dear People,

> The webserver does only contain the webspace filesystem structure as
> well as 5 line of PHP Code dummies, for every document in the content
> management system, to avoid the usage of mod_rewrite.

I inherited a CMS at work that did that.

Stop.  Now.  Use mod_rewrite.  You'll live longer and spend less on 
hair-regrowth medication.

mod_rewrite is not itself a huge performance hit.  If you're on a dedicated 
server then you can move the mod_rewrite directive to the apache.conf file 
and disable .htaccess files, which can give you a performance boost, but if a 
reasonably simple mod_rewrite is the difference that is killing your server 
then you need to rethink your server.  It's a minor issue.  You'll get a 
better performance gain out of a slightly faster processor.

Your PHP coding style itself likely has little if any impact on performance.  
pre vs. post increment is going to be a tiny fraction of a percent compared 
to the time taken to parse code, hit the database, hit the disk, etc.  

As others have said, benchmark benchmark benchmark.  As a general guideline, 
the big performance killers I've run in to include:

- Parsing.  Opcode cache is good, but if you can give it less to cache that 
helps, too.  You said you're already using autoload(), which helps, but make 
sure that you're not loading gobs of code that you don't use.  Even with an 
opcode cache, that will eat up RAM.

- SQL in loops.  Never do this.  

- Cache pretty much everything that you get back from the database if you can, 
using a static variable.  (Not a global; a static variable local to a 
function or method, or a private class variable.)  If you're loading complex 
objects, cache the fully prepared version.  That not only provides a 
performance boost, but also provides you with a good 
single-point-of-optimization because it's then much easier to shift that from 
a static variable or static array to a memcached storage.  

- Limit your individual transfers.  Oft-forgotten, but remember that every 
file the browser has to request is another HTTP hit on the server.  Even if 
the response from the server is "nope, no change", it's still an HTTP hit.  
That can really hurt your effective performance, both on the server side and 
client side.  Merge your CSS and JS into as few files as reasonable, even if 
that means that you send more than you need to on the first page request.  It 
helps overall.  You can do that manually or automatically.  (Drupal, for 
instance, auto-aggregates CSS and in the next version will auto-aggregate JS, 
too.  That's been a big performance boost.)  The same goes for image files.

- Apropos of the last, Firebug!  The latest version has a great profiler that 
can show you how long each HTTP request takes.  You may find that you spend 
most of your browser-load time on things that don't involve PHP at all.

- EXPLAIN your SQL.  That is, the MySQL EXPLAIN command prefixed to any SELECT 
query will tell you how MySQL is going to parse and process it.  Odds are 
good that adding a few well-placed keys/indexes will make your SQL an order 
of magnitude faster or more.  Also, watch out for filesort.  Any time a query 
has to do a filesort, it gets slow.  It always has to filesort if you are 
doing a WHERE and ORDER BY that use fields in different tables.  Avoid that 
if you can.  Much more information in a MySQL group. :-)

Again, benchmark it from every direction you can.  Odds are, though, that your 
PHP code itself is not the bottleneck but the server configuration, SQL 
server, HTTP traffic, etc. are where you're really dying.

Cheers.

-- 
Larry Garfield  AIM: LOLG42
[EMAIL PROTECTED]   ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Performance and System Load

[Richard Lynch]

On Fri, July 20, 2007 2:25 am, Sascha Braun, CEO @ ejackup.com wrote:
> I developed a very large Application, which has at the moment strong
> performace problems, while pages are loaded.

Look into valgrind/callgrind to get an idea of where all your time is
being spent.

Optimizing something that is not taking any significant time pointless.

> At the moment I am trying to lower the number of filesystem calls as
> much as I can. I was able allready to lower the rate of filesystem
> calls from round about 260 calls, which normaly included database
> calls
> each time as well.
>
> Now a page loads with round about 36 Filesystem and database calls, so
> a improvement could really get established.

Whoa.

I'm assuming this helped a lot.

But, really, 36 filesystem calls seems kinda high to me...

> Now, as I might have imagined, the next problem is the object model of
> the application which was very flexible in the past two years. But now
> over time, for example the content management class grew up to 400 Kb
> which is for a web application hell of a lot.

Are you only imagining that the class size is the problem, or have you
some kind of evidence?

> But it seems it is the only class at that enormous size.
>
> I am using the PHP5 autoload functionality exclusive, so no other way
> of loading classes is getting used.
>
> No I started to come in mind of, splitting the cms class into smaller
> potions. Will it really improve the page load, or will the object ini-
> tialisations of the new appearing mass of classes have the same effect
> as a class, stored in the eaccelator cache with a memory consumtion
> round about 400 Kb?

I cannot begin to imagine how splitting it into a bunch of little
classes, each with an fstat for the autoload, is going to improve
things.

Rather the opposite, really.

And splitting it up in the cache will just give you a lot of little
numbers that add up to more than 400k due to overhead, so that doesn't
seem like a "win"...

> Another question is, that I started to include my application
> framework
> over a symlink placed in every webspace directory. I've read somewhere
> that linux needs time to resolve a symlinks target.

I would DEFINITELY look very carefully at this...

If the eaccelerator is unable to properly cache because of the
symlink, your accelerator may be serving no useful purpose...

It's also possible that the accelorator handles symlink just fine, but
anything not cached requires 2 fstats instead of 1.  That's definitely
a slow-down, but how MUCH of a slowdown, and whether it's relevant, is
unknown until you profile (see valgrind/callgrind paragraph at
beginning).

> Can this be a real performance issue? All datasets as well as images,
> modules and all application relevant informations are loaded from that
> symlinked place at the moment.

If all else fails, moving the images to a separate server is a common
way of lightening the load on a busy web-server.

It's generally pretty trivial in a well-designed application.

Actually, it's even pretty trivial in a badly-designed application,
usually.

> The webserver does only contain the webspace filesystem structure as
> well as 5 line of PHP Code dummies, for every document in the content
> management system, to avoid the usage of mod_rewrite.

I'm not sure what this means, though I'm going to hazard a guess that
you've got some kind of front-controller model where a 5-line PHP
script is pounded to figure out what other content to serve up.

While this is really nifty for a lot of reasons, it *DOES* mean that
you're hitting that 5-line script for every page hit, which is an
extra fstat call, unless your cache is working properly.

If the cache is working properly, it's fine.

If not, fix the cache, or consider a different model...

> It would be really wonderfull, to be able to discuss my questions with
> you people here :))

Before you do anything else, I stress again that using
valgrind/callgrind (or any profiling tool) to find your performance
bottleneck MUST be your first step.

Anything further work or even discussion is pretty pointless without
that.

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP Performance and System Load

[Sancar Saran]

Hi,

What is your desired performance level on what kind of hardware.

Have look memcached,

General performance tip do not include more than 10 files a page load.


I had CMS project too. Sometimes it uses 10 MB of php memory (generally uses 3 
mb of php memory). It uses Memcached in every way possible. Uses php Adodb 
for sql connection. Uses SQL based sessions. 

Except the external libs (adobs, php sniffer, phpmailer etc) no object method 
used. Also we had language, template support.

Generally be able to pump 5-7 pages per second on intel PII 350 mhz 320 mb ram 
IDE hdd. If I remove XSS detector (auto check for every member of  $_REQUEST 
array). It can reach 9 - 10 pages per second.

My Experiences
Looping around sql is bad.  Reading large flatfiles bad. 
Processing large texts are bad (Templating, Lots of preg replaces). 

If any of those operation was write once read many, store to memcached, then 
use it. 

Another simple performance tip.

Most of for examples of php look like this
for($x=0;$x Dear People,
>
> I developed a very large Application, which has at the moment strong
> performace problems, while pages are loaded.
>
> At the moment I am trying to lower the number of filesystem calls as
> much as I can. I was able allready to lower the rate of filesystem
> calls from round about 260 calls, which normaly included database calls
> each time as well.
>
> Now a page loads with round about 36 Filesystem and database calls, so
> a improvement could really get established.
>
> Now, as I might have imagined, the next problem is the object model of
> the application which was very flexible in the past two years. But now
> over time, for example the content management class grew up to 400 Kb
> which is for a web application hell of a lot.
>
> But it seems it is the only class at that enormous size.
>
> I am using the PHP5 autoload functionality exclusive, so no other way
> of loading classes is getting used.
>
> No I started to come in mind of, splitting the cms class into smaller
> potions. Will it really improve the page load, or will the object ini-
> tialisations of the new appearing mass of classes have the same effect
> as a class, stored in the eaccelator cache with a memory consumtion
> round about 400 Kb?
>
> Another question is, that I started to include my application framework
> over a symlink placed in every webspace directory. I've read somewhere
> that linux needs time to resolve a symlinks target.
>
> Can this be a real performance issue? All datasets as well as images,
> modules and all application relevant informations are loaded from that
> symlinked place at the moment.
>
> The webserver does only contain the webspace filesystem structure as
> well as 5 line of PHP Code dummies, for every document in the content
> management system, to avoid the usage of mod_rewrite.
>
> It would be really wonderfull, to be able to discuss my questions with
> you people here :))
>
> Best Regards,
>
>
> Sascha

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] PHP Performance and System Load

[Sascha Braun, CEO @ ejackup.com]

Dear People,

I developed a very large Application, which has at the moment strong
performace problems, while pages are loaded.

At the moment I am trying to lower the number of filesystem calls as
much as I can. I was able allready to lower the rate of filesystem
calls from round about 260 calls, which normaly included database calls
each time as well.

Now a page loads with round about 36 Filesystem and database calls, so
a improvement could really get established.

Now, as I might have imagined, the next problem is the object model of
the application which was very flexible in the past two years. But now
over time, for example the content management class grew up to 400 Kb
which is for a web application hell of a lot.

But it seems it is the only class at that enormous size.

I am using the PHP5 autoload functionality exclusive, so no other way
of loading classes is getting used.

No I started to come in mind of, splitting the cms class into smaller
potions. Will it really improve the page load, or will the object ini-
tialisations of the new appearing mass of classes have the same effect
as a class, stored in the eaccelator cache with a memory consumtion
round about 400 Kb?

Another question is, that I started to include my application framework
over a symlink placed in every webspace directory. I've read somewhere
that linux needs time to resolve a symlinks target.

Can this be a real performance issue? All datasets as well as images,
modules and all application relevant informations are loaded from that
symlinked place at the moment.

The webserver does only contain the webspace filesystem structure as
well as 5 line of PHP Code dummies, for every document in the content
management system, to avoid the usage of mod_rewrite.

It would be really wonderfull, to be able to discuss my questions with
you people here :))

Best Regards,


Sascha

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Matthew Runo]

Well, across the sites that are on our server at the moment we are 
seeing an average increase in PHP execution speed of 244% (I just ran a 
test). According to Zend if everyone of our clients were to use partial 
page caching and the like, we'd be seeing closer to a 1000% (10x) 
speedup.

Quabbo.com is currently being redesigned to offer more information on 
partial page caching and the other improvements that ZPS allows such as 
it's new php download server plugin. I'd also like to get it designed 
with CSS rather than tables.

It's not hard to add in partial page caching code to a PHP driven site, 
but people just don't want to do it when they can get a decent boost 
from just being under the Zend Performance Suite's umbrella effects.

Matthew Runo
http://www.quabbo.com
Quabbo Internet Services
The only host with the Zend Performance Suite!
On Aug 10, 2004, at 3:47 PM, Ed Lazor wrote:
Your tag line caught my attention - have any specs on performance 
boosts
provided by Zend?

The only host with the Zend Performance Suite!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

Your tag line caught my attention - have any specs on performance boosts
provided by Zend?

> The only host with the Zend Performance Suite!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Matthew Runo]

This is a great tip. Thanks! I've added it to my folder of "tips to 
speed up PHP".

Matthew Runo
http://www.quabbo.com
Quabbo Internet Services
The only host with the Zend Performance Suite!
On Aug 10, 2004, at 3:07 PM, Curt Zirzow wrote:
* Thus wrote Ed Lazor:
Any recommendations on how to make PHP run faster?
To help figure out which queries are running slow there is the
php.ini setting:
  mysql.trace_mode=On
Using this will have the php library analyze your queries and if
any of them do table scans php will issue a warning about it, which
can be very helpful finding out where you need indexes.

I have a script pulling a lot of data from MySQL and generating 
reports and
spitting out data (flush) as it's processing so I can see what's 
going on.
It was taking around 10 seconds to process each order.  I reduced the 
total
number of orders being processed.  I expected the script to take less 
time
because there were fewer orders to process, but I was surprised to 
discover
that time spent processing each order also reduced almost in half.  I
figured PHP's memory limit per script at 8mb might be the bottleneck, 
so I
upped it to 128, restarted apache, and reran the script.  Increasing
available memory had no effect.

Its hard to say blindly where the bottle-neck is though.
Curt
--
First, let me assure you that this is not one of those shady pyramid 
schemes
you've been hearing about.  No, sir.  Our model is the trapezoid!

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance [solution]

[Jason Davidson]

woohoo indexes kick a$$.. at the expense of mem though :)

J
"Ed Lazor" <[EMAIL PROTECTED]> wrote: 
> 
> I added more indexes.  The 20 minute report just took 40 seconds *grin*
> 
> Thanks Everyone,
> 
> Ed
> 
> 
> > -Original Message-
> > From: Curt Zirzow [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 10, 2004 3:07 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: [PHP] PHP performance
> > 
> > * Thus wrote Ed Lazor:
> > > Any recommendations on how to make PHP run faster?
> > 
> > To help figure out which queries are running slow there is the
> > php.ini setting:
> > 
> >   mysql.trace_mode=On
> > 
> > Using this will have the php library analyze your queries and if
> > any of them do table scans php will issue a warning about it, which
> > can be very helpful finding out where you need indexes.
> > 
> > >
> > >
> > >
> > > I have a script pulling a lot of data from MySQL and generating reports
> > and
> > > spitting out data (flush) as it's processing so I can see what's going
> > on.
> > > It was taking around 10 seconds to process each order.  I reduced the
> > total
> > > number of orders being processed.  I expected the script to take less
> > time
> > > because there were fewer orders to process, but I was surprised to
> > discover
> > > that time spent processing each order also reduced almost in half.  I
> > > figured PHP's memory limit per script at 8mb might be the bottleneck, so
> > I
> > > upped it to 128, restarted apache, and reran the script.  Increasing
> > > available memory had no effect.
> > >
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance [solution]

[Ed Lazor]

I added more indexes.  The 20 minute report just took 40 seconds *grin*

Thanks Everyone,

Ed


> -Original Message-
> From: Curt Zirzow [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 10, 2004 3:07 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP] PHP performance
> 
> * Thus wrote Ed Lazor:
> > Any recommendations on how to make PHP run faster?
> 
> To help figure out which queries are running slow there is the
> php.ini setting:
> 
>   mysql.trace_mode=On
> 
> Using this will have the php library analyze your queries and if
> any of them do table scans php will issue a warning about it, which
> can be very helpful finding out where you need indexes.
> 
> >
> >
> >
> > I have a script pulling a lot of data from MySQL and generating reports
> and
> > spitting out data (flush) as it's processing so I can see what's going
> on.
> > It was taking around 10 seconds to process each order.  I reduced the
> total
> > number of orders being processed.  I expected the script to take less
> time
> > because there were fewer orders to process, but I was surprised to
> discover
> > that time spent processing each order also reduced almost in half.  I
> > figured PHP's memory limit per script at 8mb might be the bottleneck, so
> I
> > upped it to 128, restarted apache, and reran the script.  Increasing
> > available memory had no effect.
> >

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Alex Hogan]

> Did you try a curveball when throwing the processors into the box?

Processors like sliders...
Can't lay off 'em.., can't hit 'em. 


alex hogan
*
The contents of this e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom it is addressed. The 
views stated herein do not necessarily represent the view of the company. If you are 
not the intended recipient of this e-mail you may not copy, forward, disclose, or 
otherwise use it or any part of it in any form whatsoever. If you have received this 
e-mail in error please e-mail the sender. 
*

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

Ooo ahhh, thanks Curt =)

> -Original Message-
> To help figure out which queries are running slow there is the
> php.ini setting:
> 
>   mysql.trace_mode=On
> 
> Using this will have the php library analyze your queries and if
> any of them do table scans php will issue a warning about it, which
> can be very helpful finding out where you need indexes.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

Thanks Vail, I'll check that out.

-Ed


> -Original Message-
> If your problem is with a long running MySQL Query, and many of mine have
> been, I would suggest you read
> 
> http://dev.mysql.com/doc/mysql/en/Optimizer_Issues.html
> 
> Your objective is to make sure that all your database queries avoid the
> deadly "table scan" as a part of their query plan.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

> Lot of good that did.  I just threw 8 socket 7 AMD processors into a
> box, and PHP isn't even the slightest bit faster.

Did you try a curveball when throwing the processors into the box?

-Ed

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[Curt Zirzow]

* Thus wrote Ed Lazor:
> Any recommendations on how to make PHP run faster?

To help figure out which queries are running slow there is the
php.ini setting:

  mysql.trace_mode=On

Using this will have the php library analyze your queries and if
any of them do table scans php will issue a warning about it, which
can be very helpful finding out where you need indexes.

> 
>  
> 
> I have a script pulling a lot of data from MySQL and generating reports and
> spitting out data (flush) as it's processing so I can see what's going on.
> It was taking around 10 seconds to process each order.  I reduced the total
> number of orders being processed.  I expected the script to take less time
> because there were fewer orders to process, but I was surprised to discover
> that time spent processing each order also reduced almost in half.  I
> figured PHP's memory limit per script at 8mb might be the bottleneck, so I
> upped it to 128, restarted apache, and reran the script.  Increasing
> available memory had no effect.
> 

Its hard to say blindly where the bottle-neck is though.


Curt
-- 
First, let me assure you that this is not one of those shady pyramid schemes
you've been hearing about.  No, sir.  Our model is the trapezoid!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

Good point Jay.  Luckily the server has dual 2.4gh xeon's with 2gig of ram
*grin*

> -Original Message-
> [snip]
> Any recommendations on how to make PHP run faster?
> [/snip]
> 
> A multiple CPU box. (It's a legitimate answer!)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Ed Lazor]

> -Original Message-
>This may have already been addressed, but did you index any key fields?

I do have some indices created, but I'll check to see if there are more than
can boost things.

Thanks =)

Ed

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP performance

[John Nichel]

Jay Blanchard wrote:
[snip]
Any recommendations on how to make PHP run faster?
[/snip]
A multiple CPU box. (It's a legitimate answer!)
Lot of good that did.  I just threw 8 socket 7 AMD processors into a 
box, and PHP isn't even the slightest bit faster.

--
John C. Nichel
ÜberGeek
KegWorks.com
716.856.9675
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Vail, Warren]

If your problem is with a long running MySQL Query, and many of mine have
been, I would suggest you read

http://dev.mysql.com/doc/mysql/en/Optimizer_Issues.html

Your objective is to make sure that all your database queries avoid the
deadly "table scan" as a part of their query plan.

Good Luck,

Warren Vail


-Original Message-
From: Jay Blanchard [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, August 10, 2004 12:16 PM
To: Ed Lazor; [EMAIL PROTECTED]
Subject: RE: [PHP] PHP performance


[snip]
Any recommendations on how to make PHP run faster?
[/snip]

A multiple CPU box. (It's a legitimate answer!)

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Matthew Sims]

> [snip]
> Any recommendations on how to make PHP run faster?
> [/snip]
>
> A multiple CPU box. (It's a legitimate answer!)

I usually add more gerbils to my spinning wheel.

-- 
--Matthew Sims
--

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Jay Blanchard]

[snip]
Any recommendations on how to make PHP run faster?
[/snip]

A multiple CPU box. (It's a legitimate answer!)

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] PHP performance

[Alex Hogan]

[snip]
>  I figured PHP's memory limit per script at 8mb might be the 
> bottleneck, so I upped it to 128, restarted apache, and reran 
> the script.  Increasing available memory had no effect.
[/snip]

This may have already been addressed, but did you index any key fields?




alex hogan
*
The contents of this e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom it is addressed. The 
views stated herein do not necessarily represent the view of the company. If you are 
not the intended recipient of this e-mail you may not copy, forward, disclose, or 
otherwise use it or any part of it in any form whatsoever. If you have received this 
e-mail in error please e-mail the sender. 
*

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] PHP performance

[Ed Lazor]

Any recommendations on how to make PHP run faster?

 

I have a script pulling a lot of data from MySQL and generating reports and
spitting out data (flush) as it's processing so I can see what's going on.
It was taking around 10 seconds to process each order.  I reduced the total
number of orders being processed.  I expected the script to take less time
because there were fewer orders to process, but I was surprised to discover
that time spent processing each order also reduced almost in half.  I
figured PHP's memory limit per script at 8mb might be the bottleneck, so I
upped it to 128, restarted apache, and reran the script.  Increasing
available memory had no effect.

 

MySQL is taking most of the cpu while running the script, but I figured I'd
make sure to boost PHP as much as possible before going to the MySQL list
for MySQL performance tips.

 

Thanks,

 

Ed

 

Re: [PHP] php performance

[Brent Baisley]

It doesn't sound like you've testing to see where the bottleneck is. I 
would first recommend inserting some microtime() commands into you PHP 
code, like around your queries and blocks of PHP code. This will tell 
you what is taking the longest time and will point you in the right 
direction.
Next I would look in your MySQL logs to see if you have slow queries or 
find out what MySQL is spending it's time on.


On Thursday, January 23, 2003, at 04:42 PM, arch wrote:

I'm running php4 on apache on linux. I'm having performance problems 
with
php getting data from the mysql database.
--
Brent Baisley
Systems Architect
Landover Associates, Inc.
Search & Advisory Services for Advanced Technology Environments
p: 212.759.6400/800.759.0577


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php performance

[John Wells]

Chris,

Can we see your test code?

John

arch said:
> Nope. It's tested with a typical client/server setup, as in a real use
> case.
>
>
> "Chris McCluskey" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
> .
> I'm going to ask the really stupid question... Is mysql, php, apache
> running on the same box as the box you are using to test from?
>
> -Chris
>
> -Original Message-
> From: arch [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, January 23, 2003 1:42 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP] php performance
>
>
> I'm running php4 on apache on linux. I'm having performance problems
> with php getting data from the mysql database. With one user at a given
> instant, performance is fine, even with the massive size of the data
> table. But when do very rudimentary load testing (basically, opening a
> few browser and performing the same requests), the performance is awful.
> I suppose the issue is with mysql, but I can't be sure.
>
> What are some solutions to performance issues such as these? I've
> already done mysql indexing, which is how I got the current level of
> performance. But again, performance is unsatisfactory with just a few
> simultaneous requests.
>
> Thanks in advance.
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] php performance

[arch]

Nope. It's tested with a typical client/server setup, as in a real use case.


"Chris McCluskey" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]..
.
I'm going to ask the really stupid question... Is mysql, php, apache
running on the same box as the box you are using to test from?

-Chris

-Original Message-
From: arch [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 23, 2003 1:42 PM
To: [EMAIL PROTECTED]
Subject: [PHP] php performance


I'm running php4 on apache on linux. I'm having performance problems
with php getting data from the mysql database. With one user at a given
instant, performance is fine, even with the massive size of the data
table. But when do very rudimentary load testing (basically, opening a
few browser and performing the same requests), the performance is awful.
I suppose the issue is with mysql, but I can't be sure.

What are some solutions to performance issues such as these? I've
already done mysql indexing, which is how I got the current level of
performance. But again, performance is unsatisfactory with just a few
simultaneous requests.

Thanks in advance.



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] php performance

[Chris McCluskey]

I'm going to ask the really stupid question... Is mysql, php, apache
running on the same box as the box you are using to test from?

-Chris

-Original Message-
From: arch [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, January 23, 2003 1:42 PM
To: [EMAIL PROTECTED]
Subject: [PHP] php performance


I'm running php4 on apache on linux. I'm having performance problems
with php getting data from the mysql database. With one user at a given
instant, performance is fine, even with the massive size of the data
table. But when do very rudimentary load testing (basically, opening a
few browser and performing the same requests), the performance is awful.
I suppose the issue is with mysql, but I can't be sure.

What are some solutions to performance issues such as these? I've
already done mysql indexing, which is how I got the current level of
performance. But again, performance is unsatisfactory with just a few
simultaneous requests.

Thanks in advance.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] php performance

[arch]

I'm running php4 on apache on linux. I'm having performance problems with
php getting data from the mysql database. With one user at a given instant,
performance is fine, even with the massive size of the data table. But when
do very rudimentary load testing (basically, opening a few browser and
performing the same requests), the performance is awful. I suppose the issue
is with mysql, but I can't be sure.

What are some solutions to performance issues such as these? I've already
done mysql indexing, which is how I got the current level of performance.
But again, performance is unsatisfactory with just a few simultaneous
requests.

Thanks in advance.



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP-Performance

[Michael J. Pawlowsky]

Get in touch with Zend. I bet they have benchmarks with their optimizer engine.
http://www.zend.com/

Cheers,
Mike



*** REPLY SEPARATOR  ***

On 03/01/2003 at 3:56 PM Fatih Üstündað wrote:

>Do you know any resource about php performance?
>
>I wonder that can I use php+apache+oracle for a web site
>serving to many clients ( such as 10.000 ) at the same time?




--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHP-Performance

[Khalid El-Kary]

Performance related issues depend on too many factors infact, however, PHP 
is known to be fast in itself (as an apache module), oracle is also known to 
be fast just like MySQL, but still it depends on what your app will do with 
the database, and how would you manage both your database and application in 
order to get good performance, one of the most important sides, is your 
hardware, single server, multiple servers, dual processors or more? , and so 
on ... your connection?

However PHP, Oracle, Apache, Linux (prefered) is a good group.

Regrads,
Khalid Al-kary

Do you know any resource about php performance?

I wonder that can I use php+apache+oracle for a web site
serving to many clients ( such as 10.000 ) at the same time?


Fatih Üstündað
Yöre Elektronik Yayýmcýlýk A.Þ.
0 212 234 00 90


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



_
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] PHP-Performance

[Fatih Üstündağ]

Do you know any resource about php performance?

I wonder that can I use php+apache+oracle for a web site
serving to many clients ( such as 10.000 ) at the same time?


Fatih Üstündað
Yöre Elektronik Yayýmcýlýk A.Þ.
0 212 234 00 90


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] php & performance

[Michal Dvoracek]

Hello,

what is better syntax (for perfomance option, not code-style)
e.g. html code out of php tags





text




or

';
while (...)
$table .= ''.$something.'text';
$table .= '';
?>

Thank you.

Regards,
Michal Dvoracek  [EMAIL PROTECTED]


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] php performance (was: Single/Double Quotes)

[Gerard Samuel]

Thanks for the pointers...

Another quick ?.

Im rewriting a rather large script, and I read somewhere that an 
application would run slightly faster if you drop out of php to display 
html.
So like





If the application is rather large, does the constant jumping in and out 
of php slow it down?
Or if you use *echo* with single quotes to display literal meanings like
echo '';
suffice??

That should be it.
Thanks

Miles Thompson wrote:

> This should work ...
> $result=mysql_query("SELECT book FROM TAB_AUTHORS  WHERE aid = '$aid'");
> 
> When PHP sees the single quotes around the $aid it evaluates it to the 
> value stored in the variable.
> Your first example connntained $aid within a set of double quotes, thus 
> it was treated as a literal.
> 
> Hope this helps - Miles Thompson
> 
> At 09:08 AM 12/12/2001 -0500, Gerard Samuel wrote:
> 
>> Im tring to rewrite some code to use single/double quotes correctly (as
>> correct as can be).
>>
>> If I use
>> $result=mysql_query('SELECT book FROM ' . TAB_AUTHORS . " WHERE aid =
>> $aid");
>> I get an mysql error.  That should be correct, if I understand it right.
>>
>> But if I use
>> $result=mysql_query('SELECT book FROM ' . TAB_AUTHORS . " WHERE aid =
>> '$aid'");
>> it works.
>>
>>
>> So what I need to know is that do I have to ride the fine thin line for
>> correctness and speed???
>>
>>
>> -- 
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>> To contact the list administrators, e-mail: [EMAIL PROTECTED]
> 
> 
> 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]