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
Related
I recently ditched XAMPP on my Windows 10 machine and re-installed Apache (2.4), PHP 7 and MySQL manually (I followed the instructions given here in order to be able to switch between PHP versions easily).
Everything works fine, except that now when I make a change in a PHP file and hit Refresh in the browser, the change often doesn't appear immediately in the browser. No matter how hard I hit F5 (or Ctrl+F5), I still get the non-modified source code, and I have to wait a couple of minutes before those change are finally visible to the browser.
Needless to say, it's quite annoying when developing. And it didn't happen when I was using XAMPP.
So there seems to be some kind of cache somewhere, but I can't find where it is. I don't know if it's Apache or PHP, although I suspect it might be PHP, because the CSS or JS files are not affected by this problem (as far as I can tell).
Any idea what's causing this behavior and how to disable it?
EDIT: I did some more testing.
I created the simplest PHP file possible. Just:
<?php
echo 'test1';
I can confirm that the problem occurs even in this simple case (changing "test1" to "test2": the browser still shows "test1" for a while).
Opening the same page in another browser still shows the outdated code (test1 instead of test2).
Clearing the browser cache doesn't help.
So the problem doesn't seem to happen on the client side.
However, if I do the same test with an HTML file instead of a PHP file, then the problem doesn't occur. Any change done to that file is visible immediately in the browser (of course I'm still accessing this file via Apache, so http://localhost/some-path/test.html)
So the problem seems to affect only PHP files.
It seems the problem was caused by the OPCache module, which I had to enable in order to work on another (drupal 8) project.
In php.ini, the following line:
; How often (in seconds) to check file timestamps for changes to the shared
; memory storage allocation. ("1" means validate once per second, but only
; once per request. "0" means always validate)
opcache.revalidate_freq=60
Changing 60 to 1 (and restarting Apache) basically solved the problem.
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/
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
I have a strange problem: I have a PHP application that's working in all common browsers. But some pages are not fully loaded in IE8. If I look at the source code, it has been more ore less randomly cut off and half of the html source is missing, sometimes in the middle of a tag.
The strange thing is, it appears only on some IE-installations (in a big company), on others (I'd say the majority) it's working.
If I look up the apache error logs it says:
[notice] child pid 9393 exit signal Segmentation fault (11)
I don't know if it's related somehow, but how can the same page (called with the same parameters) work on one machine and not on another one (reproducable)?
I have not a single clue if it's some rendering problems in IE, if the browser is crashing internally or if the server really crashes and serving only half of the html source.
(Unfortunately I can't provide an example as it occurs on a web project yet to be released)
Update: I did some testing:
Upgraded Apache2, PHP5, libPHP5 on the Debian machine. Updated, activated, deactivated xdebug, mimicked the request header (user-agent) with apaches mod_header - still the same problem. Honestly I'm not sure, if the seg fault has something to do with the problem that IE only delivers half of the content.
Can this also be due to a virus scanner? Does anyone know of circumstances that IE only gets half the source code when there is no server error?
If your Apache logs say one of the worker processes segfaulted, it's not a client-side issue. No matter what the client does, it should not cause the server to crash.
The issue might be related to IE8, but only indirectly - IE8 could issue a different pattern of requests when visiting the page, or at the very least sends a different User-Agent string which the server might use to follow a different codepath.
Try upgrading your version of Apache. If that doesn't work, check for configuration errors in Apache, such as a bad extension module. If that doesn't do it, inspect your server hardware for flaws.
Sorry, no answer, bt if it were me I'd....
1) configure the php to do an auto-prepend (unless there's already one in place
2) write an include file to trap incomplete page loads (have a llok at ignore_user_abort, connection_status and register_shutdown_function)
If your code can detect occurrences of the problem, then its not related to the segfault.
You might also try installing mod_security which can log post vars and record a log entry at the start of a request - so you have some scope for investigating the segfaults.
After days of debugging (updated server software, moved to another machine and so on) we finally got the problem. It was a very old installation of the Novell Border Manager, some sort of proxy. The segmentation fault seems to be unrelated to this.
If anyone has similar problems, here are two related posts:
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&externalId=7007318&sliceId=1&docTypeID=DT_TID_1_1
http://forums.novell.com/novell-product-support-forums/access-manager-3/428004-access-manager-showing-partial-content-page-post2058485.html
I am calling a PHP-Script belonging to a MySQL/PHP web application using FF3. I run XAMPP on localhost. All I get is this:
Connection Interrupted
The connection to the server was reset while the page was loading.
The network link was interrupted while negotiating a connection. Please try again.
There are a number of possible solutions ... depends on the "why" ... so it ends up being a bit of trial and error. On a fresh install, that's tricky to determine. But, if you made a recent "major" change that's a place to start looking - like modifying virtual hosts or adding/enabling XDebug.
Here's a list of things I've used/done/tried in the past
check for infinite loops ... in particular looping through a SQL fetch result which works 99% of the time except the 1% it doesn't. In one case, I was using the results of two previous queries as the upper and lower bounds of a for loop ... and occasionally got a upper bound of a UINT max ... har har har (vomit)
copying the ./php/libmysql.dll to the windows/system32 directory (Particularly if you see Parent: child process exited with status 3221225477 -- Restarting in your log files ... check out: http://www.java-samples.com/showtutorial.php?tutorialid=1050)
if you modify PHP's error_reporting at runtime ... in certain circumstances this can cause PHP to degenerate into an unstable state if, say, in your PHP code you modify the superglobals or fiddle around with other deep and personal background system variables (Nah, who would ever do such evil hackery? ahem)
if you convert your MySQL to something other than MyISAM or mysqli
There is a known bug with MySQL related to MyISAM, the UTF8 character set and indexes (http://bugs.mysql.com/bug.php?id=4541)
Solution is to use InnoDB dialect (eg sql set GLOBAL storage_engine='InnoDb';)
Doing that changes how new tables are created ... which might slightly alter the way results are returned to a fetch statement ... leading to an infinite loop, a malformed dataset, etc. (although this change should not hang the database itself)
Other helpful items are to ramp up the debug reporting for PHP and apache in their config files and restart the servers. The log files sometimes give a clue as to at least where the problem might reside. If it happens after your page content was finished it's more likely in the php settings. If it's during page construction, check your PHP code. Etc. etc.
Hope the above laundry list helps somebody someday ... probably myself when I run into it again and come back here looking for "how the heck did I fix it last time?" ... :)
It's possible that your script could be caught in an infinite loop. If that doesn't apply, then I'd check the error logs like TimB suggested.
It sounds like the PHP script you're calling is failing without returning a valid response. Depending on the level of logging that you have set up, this should generate an error in the Apache logfile, which will give you some idea of the problem. I'm not familiar with XAMPP, but you should be able to find out where the logs are, and look for an error that occurred at the time you made your request to the PHP script.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
I solved this problem Upgrading the xampp\php\ext\xdebug\php_xdebug.dll
(changed to php xdebug v.2.0.5-5.3-vc9 )
I had the same problem and this is what i did.
I issued the http get command through php cli script, and as it turns out I had declared one class twice somewhere.
By the way , i use AMPPS on an mac
Hope this helps some one!
Try doing the request with Firebug enabled and see what info you can get out of that; I always find that using wget is helpful for seeing the raw HTTP interaction without worrying about Firefox's UI elements interfering.
If you are using certificates for ssl in Windows 2008 Server(iis 7) from old selfssl tool(iis 6), that is the problem. Sometimes Microsoft releases patches which can destruct all these old certificates. The solution is to generate them again.
copying libmysql.dll to apache\bin folder may help you overcome this strange error
Indeed this helped me to solve this problem
The connection to the server was reset while the page was loading.
Incase the issue is not working this did the trick for me.
1. I got a new zip directory for PHP and connected it with apache
2. I searched for the libmysql in the new php and inserted this to the apache/bin
its this libmysql.dll that is needed there and not the one form mySQL/bin.
ok at least thats the one that worked.
I experienced a very similar issue - which doesn't apply to the person who asked this question - but may be of help to others who are reading this page...
I had an issue where in certain cases PHP 5.4 + eAccelerator = connection reset. There was no error output in any log files, and it only happened on certain URLs, which made it difficult to diagnose. Turns out it only happened for certain PHP code / certain PHP files, and was due to some incompatibilities with specific PHP code and eAccelerator. Easiest solution was to disable eAccelerator for that specific site, by adding the following to .htaccess file
php_flag eaccelerator.enable 0
php_flag eaccelerator.optimizer 0
(or equivalent lines in php.ini):
eaccelerator.enable="0"
eaccelerator.optimizer="0"