I have been tasked with setting up a website on various environments for different stages of evaluation (dev/test/staging/etc).
On our staging environment however, it seems there is some difference preventing the PHP script from finishing, so the page is never delivered to the browser.
I'm wondering if there is a way I can output to log some sort of stack trace or backtrace upon cutting the connection, or is there some other method to find out what exactly PHP is doing at any given point in the script's life cycle?
It's a Drupal site, so it involves a lot of code I'm not familiar with, and could take hours to sprinkle die; commands throughout to see where the script is loading to.
I understand I should probably be looking at the differences in environments, however all should have very similar configuration (Ubuntu 11.04) and the staging environment seems entirely happy to serve other PHP sites whilst this particular site is refusing to finish. If anything this staging site has more resources available that other environments which are not having problems.
UPDATE: Sorry all, found the problem in the end. The staging environment was on a VLAN that was not permitted to access itself via public IP, and for whatever reason (still confused about this) it was trying to access itself as part of the page load and never completing the request. Setting a hosts file entry for 127.0.0.1 fixed the issue.
Debugging an issue like this step-by-step using a tool like xDebug is an option, but will probably take a long time -- finding where to put the breakpoints is going to be on about the same level as working out where to put die statements around the code. The debugger option is a better way of doing it, but won't save much in comparison, when you have a problem like this where you have an unknown blocker somewhere in large amounts of unknown code.
But xDebug also has a profiler tool which can show you what functions were called during the program run, how long they took, and highlight where the bottlenecks are. This will probably be a better place to start. Just configure xDebug to generate a profiler trace, and then use kCacheGrind to view the trace in a graphical environment.
If your program is getting stuck in a loop or something specific is taking a long time to complete, this will pinpoint the problem almost straight away; you'll be able to see exactly which function is taking the time, and what the call chain looks like to get to it.
It's quite possible that once you've seen that, you'll be able to find the problem just by looking at the relevant code. But if you can't, you can then use xDebug's step-thru debugger to analyse the function as it runs and see what the variables are set to to see why it's looping.
xDebug can be found here: http://www.xdebug.org/
Use xDebug.
Its very easy to install and use.
it has few options like breakpoints and step by step to track status of PHP script before finishes loading
and you can download xDebug from here http://www.xdebug.org/
step by step tutoril for set up xdebug is availble at sachithsays.blogspot.com/
Related
I recently started web development. The course I took was to install WAMP and start developing right away. I used an atom text editor, this -combined with wamp- proved to be a very fast way to write client-side code(HTML, CSS, Javascript).
But when I started to write serverside PHP things got a little messy. I should probably explain my site's structure here.
I keep separate PHP, CSS, javascript files for every page on the client side, for the server side a have 2 different types of PHP files:
Files that only perform a specific operation on the database(For example returning "5 more answers"). These are always called by AJAX requests.
Files that load the page for the first time. These are only used when the user opens the page for the first time, they do necessary database queries and return the page. Later requests always go to the 1st type of PHP files.
Now regarding my problem. I debugged until now by printing variables to the screen with var_dump() or echoing. But this started to become too slow as the data I work with grew. I wonder if there is a way of debugging which will let me but a breakpoint in one of my PHP files. Then, when I open it on the browser, on the localhost I created using WAMP, will let me go through the PHP file step by step.
I have been dealing with this issue for 3 days, I tried to make it work with Eclipse IDE but couldn't find a way. Also, there seems to be no tutorials or Q&A on the internet regarding the issue.
Breakpoint debugging opens a whole new world, and is the natural step after var_dump() debugging. Not only does it speed up development, but it provides much more information about your code, as you can step through each line and see what values have been set at each step, and how they evolve as your program executes its code. This means you can track the entirety of the values at different stages with one run - imagine tracking all variables at each point using var_dump()!
Although choosing an IDE is a personal decision based on personal taste, i strongly recommend you try out PhpStorm. If you can get a student licence go for it.
PhpStorm has extensive documentation & tutorials on all features in the IDE, debugging is no exception:
https://www.jetbrains.com/help/phpstorm/configuring-xdebug.html
https://www.youtube.com/watch?v=GokeXqI93x8
I don't know of a specific solution to your issue. I'm not exactly sure what you're doing but as a quick tip, I find add the following snippet to the top of the file useful as it will highly error more easily rather than browser just say nope.
error_reporting(E_ALL);
ini_set('display_errors', 'On');
Hope this help you a bit.
I tried out what's recommended in comments and answers. I first tried Netbeans. To be fair it disappointed me. Download kept getting stuck at 100%, even for different versions. When I stopped downloading and went ahead to create a php project, there was missing parts I guess. I couldn't even manage to create a php project. But that might just be me not being able to do it.
Then I followed #leuquim's answer and #Alex Howansky's comment and downloaded PHPStorm. And I got it to work in no more than 20 minutes. I downloaded it with a student's licence. For people who want to use PHPStorm with WAMP here's a Youtube tutorial:
https://www.youtube.com/watch?v=CxX4vnZFbZU
One thing to note in the video is that, maker of the video chooses PHP Web Application in the Run Configurations. That has been changed to PHP Web Page.
I'm a self taught programmer and I consider PHP one of my strongest languages. There are undoubtedly some things I don't do correctly though, since I'm not in the field and I've never had anyone leaning over my shoulder telling me about better ways.
The most cumbersome thing to me about php is debugging code. It's not too bad when I'm writing a script called with AJAX or php code inside of a webpage, because I can simply output values directly to the page. When I'm writing code without a client side though, I currently resort to outputting my debug info to the error_log. I have to navigate to it (which sometimes is a task in itself, refreshing directories to make it show up, etc), check whatever value I outputted to it, then open up my script and start working again.
I feel like there might be a better way, so I thought I'd ask. Is there a trade secret that can shave some seconds off whenever I need to know how many rows a query returns or if a path has been constructed correctly?
My development environments are Coda on my MacBook and Zend on my PC. I work on everything remotely. Nearly all my code requires the server environment to run correctly.
Update
After writing this, I just realized I could actually make a webpage using WebSockets that acted as an output window. Then import a file into each script with a function that pushed output to the webpage. Hmm... I really like this idea actually.
OS: Windows 7 - 64 bit
PHP: Standalone php.exe (PHP ver 5.5)
PHPStorm
Version: 10.0.1
All the advice I see on getting past the 502 Gateway error in PhpStorm involve just making sure you've got your Interpreter and executable set. I'm using the standalone php.exe (http://windows.php.net/download#php-5.5 VC11 x86 Thread Safe (2015-Oct-01 01:25:56)) and have everything set to PHP 5.5
I am honestly confused why I'm still getting 502 errors.
I've run it multiple times, and it did run once (there were no changes from instances before or after) which I found profoundly odd, but only for one page load and it was not a repeatable occurrence.
Edit: Realized one difference when I opened up another project to compare to. The one time it did work, the right-click context menu looked different. The other project is debugging just fine. What makes the difference? What gives? Both projects are using the same interpreter.
... Also found that going back to the working project, the additional context menu item disappeared.
Edit 2: Still problem hunting... found that certain files will run right when I start PHPStorm and will have that context menu. Other files, however, won't at startup of PHPStorm. If I I try to debug a file without the addtional menu, the server will give 502 and then the "good" files won't have the extra menu. If I start with one that has the extra context menu first, it will run, although if I follow with one doesn't, the first file ceases working. I feel like I'm making "progress" but I am also getting more confused, especially since each of these times I try to run a different file, it asks me "[x] is a single-instance run configuration. Are you sure you want to stop the running one?" At which point I click "Stop and Rerun". I would figure that the ones giving 502 wouldn't have anything carrying over to the "good" files if things are stopped and rerun... but that appears to not be the case.
Edit 3:
Wondered if maybe my interpreter setup might be bad, so I grabbed securewamp ( http://securewamp.org/en/ ), got the portable version, setup, used default setup with xdebug added on (this version: php_xdebug-2.4.0rc1-5.4-vc9.dll) and exact same problem.
I'm even at a loss of additional things to check.
Edit 4: Extra sure that it's something in PHPStorm now. One of the php files that wasn't ever working, I opened directly with the php.exe and it worked fine. It has to be some setting in phpstorm that I"m missing, or some broken function.
Edit 5: Following a trail of potential causes, tried the Run > Validate Debugger tool. Path and URL left to default (no reason to change them), and attempt to vlaidate results in "Please check that web path to validation script is correctly configured" and lists my directory.
Edit 6: Validation was only picking up on 127.0.0.1 because that's what SecureWAMP was running on. Turning off its server results in "failed to execute validation script: 'Connection refused: connect'.
Edit 7: As pointied out by LazyOne, my files in the first image are two different filetypes (php and html). I have done it with .php files on both sides, I just grabbed two of the files I was currently working in for the screenshot. Here's an example of one of the php's.
Edit 8: I think I'm finally getting a solid pattern to when it works and when it doesn't.
The context menu thing was a red herring. Ones without a submenu will work just fine when conditions are met.
A. A file that works (so far no pattern noticed yet for working files vs nonworking, in fact, one working and one nonworking file have the exact same code) must be selected.
B. Cannot, under any condition, "Stop and Rerun" a file as this will cause the file to hit bad gateway afterwards.
C. You can't open up a nonworking file. If you do, current server hangs and will continue to hang until a "stop and rerun" is run on a different file, after which all open files will get the bad gateway error. Opening a non-working file will cause currently working files to get the bad gateway error.
D. To get working files working again after C or D requires restarting system.
Edit 9:
Was fiddling around with the validate debugger configuration tool, and finally got it to give me a different answer (feel silly for it, actually, just had to include the targeted directory in the url to the validation script even though I thought the site was hosting straight from that directory. Oh well. Anyway, had one error, not sure if it's the cause of my issues or not, but will research it.
Edit 10:
Adding to php.ini to address above error...
xdebug.remote_enable=1
Edit 11: No real benefit seen from the added line.
Edit 12: Posting requested screenshot of browser
Edit 13: Updates to the EAP (10.0.2) version of phpStorm. It appears the same result so far, although now at least the console is showing me the error too instead of just the webpage. Also tried running completely through SecureWAMP's apache server only to find out there's something blocking me from changing away from the default htdocs directory.
FWIW, I think this could be as simple as a timing-out problem.
My environment is very similar to the OPs, Win764, PhpStorm 10.0.4, PHP 5.5.27.
I have some F3 automated tests where I see the 502 Bad Gateway error frequently when I run the test code 'in the browser' using one of the little icons in the toolbar that floats to the upper right of my code. (See image below.)
For some of my test pages, the error seems to be first-time-only. Run once, fails, run again, works ok. Others seem to require 2 or 3 runs before they will work. But I have a couple that I've never seen work in the browser.
OTOH, if I right-click in the code window for any of these pages and debug, the code runs fine whether I let it run all the way through or walk it line by line.
Clearly, my tool setup is not wrong. Some tests can and do run from the browser every time.
What I THINK is happening is that the likely-to-fail tests execute fairly heavy db queries. And my php interpreter is aggressively timing out my requests when I run them in the browser.
But, each time a page runs and times out, one or more of its queries gets cached and the next time I run it, the page is faster. Eventually, for the ones that will run at all, enough of the db work is cached so the page can get in under the wire and finish before the time limit.
So that's my theory. What I haven't found is where and how to change the interpreter timeout interval. That is, the timeout interval when run from PhpStorm. I do already have
max_execution_time = 300
in my php.ini file and can see that it is set when I use phpinfo(). But I have to believe that it is getting overridden when the interpreter is run from PhpStorm.
Update -- possible fix: So even though my php.ini file has that max_execution_time setting, I tried looking at my php interpreter settings as described on this PhpStorm support page, steps 1 and 2. There my max_execution_time was 0. So, I added a setting for it using the UI on that page to be the same 300 I have in my php.ini. (Then I closed and re-opened PhpStorm -- a big of old-programmer paranoia.) So far, I've seen one bad gateway message on my 'worst' page but even it ran the second time. The others seem to all be running to completion. I'll do some watchful waiting and see if this 'fix' does me any good long term.
(And, before anyone feels compelled to point it out: Yes, caching queries is a terrible idea for automated tests. Gotta fix that -- but only after I figure out how to extend the interpreter timeout so my tests can succeed without caching.)
This does not directly answer the question, but might be useful to people stumbling on the 502 Bad Gateway error.
Another way of getting a 502 Bad Gateway error is when a php scripts emits too much errors/warnings/notices. I had a script that was generating thousands of notices because of uninitialised variables that would lead to the 502 Bad Gateway error.
One solution is to fix the php code generating those notices or alternatively, disabling notice reporting in the php.ini file by adding & ~E_NOTICE to the error_reporting setting.
For example
error_reporting=E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE
UPDATE 1:
After doing an strace on the server, I have discovered that the mmap's process is taking 90% of this processing time. I've discoverd that 1 of the pages is taking a minute to load.
So I found this link:
PHP script keeps doing mmap/munmap
It possibly shows the same problem. However, I don't understand what the anwer means by correctly disabling the php error handlers?
ORIGINAL QUESTION:
How do I check for bottle necks on my web server when loading a specific web page which is being served by my server?
For some reason, a couple of pages on my site have become very slow, and I am not sure where the slowness is happening.
Screenshot from Chrome Dev Tools:
Click here to enlarge:
So basically, I need to find out what is taking this section to long to load? Client Side web tools can't seem to break this down?
Xdebug: Profiling PHP Scripts - pay attention to KCacheGrind tool or, alternatively, you can use Advanced PHP debugger apd_set_pprof_trace() function and pprofp to process generated data file.
Derick Rethans (author of Xdebug) released quite a nice article today called What is PHP doing?
It covers the strace that you've already done, but also shows you how you can use a custom .gdbinit to get the actual php function name that is causing the problem.
Of course you have to run your script from the command line with gdb, so I hope that your problem is reproducible in this way.
mmap is for creating a memory mapped view of a file.
If it really is the error handler causing it, I'd guess that your script is generating a lot of errors (which you are trying to log), maybe a NOTICE for an undefined index in a loop or something).
Check the log file (is anything being logged at all?), check permissions on the log file if nothing is logged, also double check what your error reporting level is set to.
var_dump(ini_get('error_reporting') & E_NOTICE); - Non-zero if you are reporting notices.
error_reporting(E_ALL & ~E_NOTICE); - Turn off reporting notices.
I would suggest looking into Xdebug profiling. The other two answers deal with client side loading issues but if your bottleneck is server side it won't become apparent from the use of those tools.
You may also want to look into the database queries that are being run to serve the pages in question. You could be missing an index somewhere which would explain a recent slowness with specific pages as your database tables grow in size.
I would extract those queries and run them using MySQL EXPLAIN (assuming you are using MySQL) to see if there is slowness there.
Using an application such as Fiddler or YSlow Firefox addin will help identify slow loading elements in your website. This should make any issues apparent.
http://fiddler2.com/fiddler2/
https://addons.mozilla.org/en-US/firefox/addon/yslow/
Hope this helps
Page Speed for Chrome is also an option:
https://developers.google.com/speed/docs/insights/using_chrome
Oh my goodness. I never thought that I will need to ask you this. But unfortunately yes, I need to!
I have a PHP written script of my own that uses ffmpeg-php. And ffmpeg-php is a bastard. For some input it works ok, but for some it crashes my whole PHP and server throws Internal Server Error 500. I've tried several times to update ffmpeg-php, ffmpeg itself and so on, but when for some input it works in version 0.5 in 0.6 it wont work. And what i need is be sure that rest of the script will be processed correctly. And now it does not, because when it comes to run toGDImage() on movie frame I have Internal Server Error 500 and no feedback why from any source.
So for peace of mind of my users I decided that I need to isolate this part of script that messes with ffmpeg-php. I need a way to assure that if something will go terribly wrong in this part, it rest will go on.
Try catch does not work because this is not a warning, nor a fatal error, it is a horrible server-disaster. So what are your suggestions?
I think about putting this script into another file called ffmpeg-php-process.php and call it via HTTP and read result, if it is Internal Server Error 500 - I will know that it was not ok.
Or are there any other, more neat ways to isolate disaster scripts in PHP?
Ps. Don't write that I need to diagnose or debug or find the source of the error. I'm not a damn beginner and I'm not a ffmpeg dev to mess in it's code, I need to make my users safe now, and it's everything that i care now.
If you're getting a 500 error, it's because an exception of some sort is being thrown at a level lower than that of PHP itself. Unless your code is spinning into some kind of infinite loop or hitting a recursion limit (and especially since it worked with version 0.5), there's a good chance that ffmpeg or ffmpeg-php is crashing and taking the instance of PHP that launched it down with it.
Frankly, there's nothing you can do from PHP.
Your best bet would be, since you've already got access to the server, to write the script in question using a language like Python. There's a ton of ffmpeg python plugins, so you shouldn't have a difficult time setting that up at all. Call your Python script from PHP and pull in the output from a file. What this will do is isolate PHP from your script failing. It'll also get you away from ffmpeg-php (which, at least to me, seems like an unholy combination).
If you're dead-set on using PHP (which I don't recommend), you can launch another PHP script using php-cli from your outward-facing PHP script and do the work from there (as you would with Python). Again, I highly recommend that you avoid this.
Hope this helps!
You could spawn a new process containing your php-ffmpeg script. There are some functions to do that: proc_open() as instance.
The documentation has a not bad example about it:
http://php.net/proc_open
I have something similar going with a convoluted, large, bulky legacy php-email system I support. When it got apparent that the email system was becoming it's own beast, we split it off as its own virtual server entirely. There's no separation like PHYSICAL separation. And hey, virtual servers are cheap....
On the plus side, you can start, restart, and generally destroy the separate server with little affect on the rest of your code. It may also have improved backup implications (isolate media and logic) Since going this route, we've not ever taken the main application server down.
However, it does create a connection challenge as now rather than working local you're going to have your server talking to another separated by at the very least a bit of wire in the same cabinet (hopefully)