PHP Application Development Services: What happens at the end of a PHP script?

You can monitor PHP script with New-Relic. This doesn’t happen every time, but still the average is 400ms for the page but sometimes the scripts take 60 seconds. But in New Relic, the delay period appears to be happening after all the code has run. There are many other queries that comes under PHP Application Development services and Laitkor can answer all.

PHP Application development - Laitkor

AT THE END OF A PHP SCRIPT

1.  The very first query arising is, if the 60.59s timestamp is before you do any database work, or after? If it is after, you have got a concurrency problem.  Talking about PHP, you might be using MySQL, and if you are using MyISAM tables you are going to get table-level locks when someone does a write to the table- perhaps someone’s doing a long update/ terrible query and it is just totally locking down the table. If that is the case, identify the long running query, and find out what is wrong with it, or flip over to InnoDB tables, so you at least get row-level locks.

2.  The ‘code’ that is taking 60s (not necessarily be 60s but it is often more than that)is after the last line of code in the script. The only thing logged after that is a database query to write to the session. That query takes 0.001 seconds and is to an InnoDB table. The problem also was occurring before you move to using database sessions.

3.  The last line of code is logged as finishing at 0.168s. The New relic logs “Application code” which finishes at 60.226 seconds. There is something happening after the last line of code that is taking 60 seconds. Your database transaction is being committed after the write, then your HTTP connection is being closed, and then whatever New Relic does for each probe. And logging to New Relic and your PHP script to find out.

4.  That code would be executed after your script exits. Another thing that can happen after your code is done is destructors being called. All “delays in code” happen while code is running. Otherwise, there would be no code to cause the delay. New Relic isn’t telling you where exactly the slowdown is occurring, bit it is telling you a lot about where it isn’t.

You need to dig deeper to isolate it.

5.  Here are few of the idea to follow:

•    Run in a debugger with breakpoints set in various places, observing when they hit.
•    Long timestamps liberally and look for big time gaps
•    Check PHP/web server log files for clues.
•    Execute the same query in a MySQL client to see if it is the query itself that is slow.
•    Remove code by trial-and-error. First, remove the entire session handler. If that fix it, add a little more.
•    Go on Google and look into all the PHP ‘magic’ functionality that would enable code to run in after-hooks, shutdown functions, or any other.

PHP does stuff after the script has finished, such as destructors, shutdown functions and session write close. You can look for the insight as to what those other things are since you are not yet using destructors or shutdown functions.

Share: