[UPHPU] script timers

Mac Newbold mac at macnewbold.com
Fri Feb 16 15:23:52 MST 2007


Today at 3:13pm, Daniel said:

> I tried disabling the output buffering.  All that does is displays the
> page in sections if the page is too big.  I put timers before
> includes, and after the page is displayed.  I can be on the same
> script and one time I could get <1 second and I could refresh and it
> takes 3-5 seconds to load.  If I click refresh multiple times the page
> takes multiple seconds to load.
> There are times when I click a button and in the status bar of the
> browser it says: Connecting to <server name> and sits.  I believe it
> is a networking issue.

Don't be quite so sure... I think that's also what a browser does when it 
has sent the request and is waiting for a reply, though it depends how far 
it gets into the request.

If you suspect a network issue near to where you are (your network), try 
it from somewhere else. If you suspect one on or near the server, anywhere 
will give you similar results.

Try using wget or curl to request the URL in question from the server 
itself (i.e. log into the server with ssh, run wget <URL> or curl <URL>) 
and see if that is fast or slow. If it is slow, then the problem is not 
your network, it's the PHP code, apache, or your database [queries].

Mac

> On 2/16/07, Mac Newbold <mac at macnewbold.com> wrote:
>> Today at 10:25am, Dave Smith said:
>> 
>> > First, be sure to disable any output buffering. Then, use logging on the
>> > server side to do time stamping. Write timestamps to a file on disk as 
>> the
>> > PHP script executes. Lastly, start looking at your Apache (or whatever 
>> web
>> > server) logs, and see if there are any errors there that could be causing 
>> the
>> > problem. It's most likely a problem with the web server itself, and not 
>> your
>> > PHP code.
>> 
>> That's great advice. The error_log() function comes in really handy for
>> that. If you're looking for good places to add the timers, here are some
>> ideas:
>> 
>> 1. Before and after database queries, especially big ones
>> 2. Before and after loops with many iterations
>> 3. Inside a loop with fewer iterations
>> 4. As close as possible to the start and end of the script
>> 5. Before and after any include() or require() calls
>> 6. Before and after any function or method calls that might be significant
>> 
>> If you start out up at the top with something like this:
>> 
>> $timechk=0; error_log("timecheck $timechk: ".date()); $timechk++;
>> 
>> Then sprinkle these throughout your code:
>> 
>> error_log("timecheck $timechk: ".date()); $timechk++;
>> 
>> They're easy to find and comment out or remove later if you want. If you
>> want to make them easily reusable, set up a variable called $PROFILE or
>> something, that is 0 or 1, then use this instead:
>> 
>> if ($PROFILE) { error_log("timecheck $timechk: ".date()); $timechk++; }
>> 
>> Then you can turn them all on or off at once, turn some of them on, etc.
>> 
>> Once you've got all the timechecks in place, you can see where the big
>> gaps are, and investigate why they're so big by narrowing down the space
>> between checks if necessary. If you wanted to get more fancy, you could
>> have the script check the difference between the checkpoint times, and
>> only tell you about ones that were above 0.2 seconds or something. It also
>> can be helpful to add extra output at each checkpoint so that it tells you
>> where it is, rather than just uniquely numbering each of them.
>> 
>> Most of the time when I've done this, it turns out to be a database query
>> that is either doing the wrong join or is missing an index in the database
>> that would speed it up immensely. Sometimes it is a loop that is iterating
>> way more than you intended, or other stuff. Dave is right about the
>> server: check memory usage on the server while the script is running. The
>> default memory limit for a PHP script is 8MB, but if you've bumped that
>> higher, you may be using up all the physical RAM so that it is swapping to
>> disk in a nasty thing called thrashing, which will kill your performance.
>> 
>> Thanks,
>> Mac
>> 
>> > Daniel wrote:
>> >> There is serious latency from the time someone pushes a button on our
>> >> webpages and the time the following page is displayed.  I would like
>> >> to know how to pin point the bottle neck.  We date stamped the second
>> >> page at the beginning of the script and at the end and subtracted the
>> >> two times to get a sub-second period.  For some reason the page takes
>> >> a few seconds to come up.  Where could there be a bottle neck and how
>> >> can we find out exactly where it is?
>> 
>> --
>> Mac Newbold             MNE - Mac Newbold Enterprises, LLC
>> mac at macnewbold.com      http://www.macnewbold.com/
>> 
>> _______________________________________________
>> 
>> UPHPU mailing list
>> UPHPU at uphpu.org
>> http://uphpu.org/mailman/listinfo/uphpu
>> IRC: #uphpu on irc.freenode.net
>> 
>

--
Mac Newbold		MNE - Mac Newbold Enterprises, LLC
mac at macnewbold.com	http://www.macnewbold.com/


More information about the UPHPU mailing list