I had difficulty finding the newest version of php_apc.dll so I went ahead and compiled it myself. I had no issue getting it compiled using NTS v5.3.8. I had two separate files set up to test, one with a simple phpinfo() call on it and the other being the standard apc.php file that comes with the apc source files.
Strangely, when I would load the phpinfo() file it would work totally fine, but when I tried to access apc.php the webserver would hang until a timeout. I restarted the webserver, accessed apc.php and it worked just fine, but trying to go back to phpinfo() would cause the server to hang until timeout. It is probably worth noting that phpmyadmin and my own codeigniter application do not work period, even after a restart.
I have tried previous versions of apc with no luck; 5.3.5 with apc.stat = 0 works but I am in need of that feature as this is a development server, but I'm testing out some production type caching.
Noteworthy stuff:
Server is powered by Nginx 1.0.8 running PHP 5.3.8 (using fast-cgi). Everything works as intended with the exception of when apc is loaded.
You can download the php_apc.dll from http://downloads.php.net/pierre/
You can find there different versions of it.
Related
When I started my latest project I learned how to use the xdebug extension and I have been using it ever since. Now I am ready to spin up a server and go in to production with this project and my site doesn't fully work. The frontend pages seem to work, which are php based as well, but the backend endpoints that query the database and return some data to the frontend always are returning a 500 status code. So I attach xdebug and figure out how to run it remotely and the pages all start working without any code changes. I go in to the php.ini file and turn it back off and the pages continue to work. Since this is an AWS EC2 server, I delete the instance and create a new one running the same initialization scripts I wrote to install all the software and I get the exact same issue. The server doesn't work until I follow the xdebug install instructions and restart apache2. And like before even when I unattach the xdebug extension via the php.ini file, the code continues to work. Even after the system is rebooted it still continues to work so whatever is being fixed appears to be permanent.
What would building and attaching the xdebug extension, and restarting Apache2, do to the a LAMP stack that would make my code work, even after the extension has been turned off? My server is being built with scripts that run various apt-get install commands with no binaries provided by me as it all is community provided programs. Like clockwork it breaks every time I rebuild the machine until I apply the extension. I can automate that in to my build scripts if I have to, but it is driving me a bit nuts that I don't understand what is happening.
When the server sends a 500 error, normally you get an entry to the php_error.log. So first check this file. Maybe there is some difference in memory limits, max. post variables etc.
I would suggest you to try to find calls of any xdebug specific functions such as var_dump() or any prefixed by xdebug_ in your code:
https://xdebug.org/docs/all_functions
What would building and attaching the xdebug extension, and restarting Apache2, do to the a LAMP stack that would make my code work, even after the extension has been turned off?
Installing one piece of software can bring with it another. If you sudo apt install php-xdebug without php installed, it will install php.
I recently built XHP 1.5 from source, and installed it on an existing web server. The web server is running PHP 5.4.32, Apache 2.2.15 calling PHP using mod_php (not fastcgi), CentOS 6.5. All our existing PHP code (that doesn't rely on the new XHP syntax) still works great, including other extensions like Imagick, curl, and JSON.
Using a test file based on the XHP installation test:
<?php
echo "XHP!\n";
exit;
echo <a/>;
?>
This works as expected when run from the command line. (It prints XHP! then exits. The doesn't cause the parser to fail, but doesn't display either, since we're not loading in the dependencies.)
When I fetch this script through Apache, I get the error
Parse error: syntax error, unexpected '<' in /var/www/html/bloom/play.php on line 4
Getting phpinfo() via Apache shows that XHP is loaded, extension_loaded("xhp") through Apache returns true.
What could be causing XHP to work from the command line, but to not work (not even parse) when run via Apache?
One possible reason is a difference in versions of PHP, especially since you're building XHP from source. I've encountered similar odd behavior on a shared host that had multiple versions of PHP installed. Compare the PHP version reported by Apache (look at the phpinfo() output) against the version you're using at the command line php -v. If there's a difference, that could be one explanation for the problem you're having.
After looking into more detail for how my production server (not working) differed from my test servers (working) I discovered that all servers had APC 3.1.15 installed, but in production, APC's opcode cache was disabled in /etc/php.d/apc.ini:
# BAD NEWS
apc.enable_opcode_cache=0
As it happens, this is not what we wanted for unrelated performance reasons.
Turning on APC's opcode cache, by changing this line in /etc/php.d/apc.ini and restarting Apache caused XHP to immediately begin working:
# WORKING
apc.enable_opcode_cache=1
I've also been able to resolve the problem by uninstalling APC altogether (although that's not practical in my app).
That would also explain why it worked from the CLI and not from the web--all my servers have apc.enable_cli=0, so APC wouldn't interfere with XHP from the CLI.
I need to install large sites locally on two developers workstations. The sites are written in php5 with parts in Zend 1.10 and the database is MySQL. The production server runs on windows server 2003 . The sites are already running on windows vista on a development station and on windows 7 on another one.
On two workstations where i have to install (a windows xp and a windows 7), the same strange phenomenon occurs: after a few successfull requests apache freezes and no longer responds to any query. The site does not work until a reboot of Apache that takes quite a long time (> 30 seconds) . There is nothing in Windows Event Viewer or in the apache logs. Handle.exe tells me nothing and even freezes when apache starts to hang. Windows tasks manager shows nothing unusual. I have compared the host file , php.ini , httpd.conf and httpd.vhost.conf with stations that work without finding any difference.
The configuration includes mod_rewrite , mod_proxy , apc , memcached. Apache version is 2.2 and PHP 5.3.x (thread safe). The code is under version control, database and data directories are synchronized.
Not familiar with windows , I'm looking for tools or assumptions to solve this problem .
I provide some information about a temporary solution I applied. I noticed that a fraction of the php code was executed before Apache freezes.
Execution stops within a Zend Class, Zend_Validate_Ip in the setOptions method. At this time, the file is locked for writing and held by httpd.exe.
I found that this file was slightly different from the original version (Zend 1.11.11) : the require_once have been removed. This is an acceptable optimization recommended by the official documentation.
However, restoring the require_once in that file, the problem is solved. Apache no longer freezes and everything works. So there must be a problem with class loading but I do not understand exactly what it is.
Basic Info - Running WAMP 2.2 with PHP 5.4.3 and Apache 2.2.22 on Windows XP Pro 32 bit
My problem is that when I run a php script it will run just fine. Now if I change that script and re-run it, the page will never load and the script will become locked due to being used by another program. I have found that it is being used by the process httpd.exe, which if I use End Process (Which actually restarts it rather than stopping it) the original page will suddenly load and the new script will be ran. If I change it again it will do this same thing.
If I disable the PHP APC extension this problem doesn't happen, so it is caused by APC
I have tried using php_apc_3114_beta_php54.dll (renamed it to php_apc.dll) downloaded from http://dev.freshsite.pl/php-accelerators/apc.html "APC 3.1.14 beta for PHP 5.4" and apc_3113_beta_php54_vc9.dll (renamed it to php_apc.dll) the same place "APC 3.1.13 beta for PHP 5.4 vc9"
I would suggest to download PHP extensions from specific sites only. The extensions should be compiled for your specific PHP version and system (check for x86/x64 and thread-safe vs non-thread-safe). The best places to download correctly compiled extensions for windows are:
PHP for Windows:
http://windows.php.net/
http://downloads.php.net/pierre/
and Anindya's Blog:
http://www.anindya.com/tag/php/
http://www.mediafire.com/php-win64-extensions
EDIT: As mentioned below in my comment, have you tried using BOTH versions of APC (thread safe AND non-thread-safe) from the original site you linked to?
This does sound like some sort of threading issue...
I did myself a favor and did it all on Linux. Setting up my whole server and installing APC on Ubuntu was faster and smoother than just trying to insert APC in WAMP. After a few commands and a clean install it's working beautifully, I can't believe I didn't migrate to Linux sooner!
I'm hoping someone can help me with this, as I've kinda hit a wall. Here's the situation:
I'm currently setting up a knowledge base using MediaWiki. I'm using XAMPP to aggregate my tools. The site itself is working fine, and coming along nicely.
I'm now trying to set up a cache to speed things up. I've opted to use PHP APC, as it is recommended for MediaWiki. The troubles started here.
Current versions are:
PHP: 5.4.4
Apache: 2.4.2 (apache2handler)
SQL: 5.5.25a
XAMPP: 1.8.0
MediaWiki 1.19.1
I am currently using Windows, so the first issue I had was finding the correct php_apc.dll file for my PHP. I tried numerous versions unsuccessfully (with log errors stating the .dll cannot be found). I eventually was able to secure a version which seems to work, APC 3.1.14 for PHP 5.4, downloaded from http://dev.freshsite.pl/php-accelerators/apc.html. It is the TS version, as this option is enabled on my PHP.
Now, with this presumably correct version of APC, Apache is now able to start fine. phpinfo() also shows the APC extension as available. The problem is now that no pages on the wiki will load. Precise situation is that:
All pages on the Wiki do not load (IP/mediawiki/*)
Pages on XMAPP itself do seem to load correclt (IP/XAMPP/*).
Other utilities are not able to load either, (e.g. phpMyAdmin).
No error messages seem to be created either in apache logs or php logs. Now, I am by no means an expert on this.
I have confirmed that environment variables in Windows TMP and TEMP both point to the same folder (C:\WINNT\TEMP), on which I gave "everyone" full access rights.
Here is an image showing the phpinfo() for APC that I can see:
http://i.stack.imgur.com/hYHwP.png
Any ideas?
edit: I forgot to mention: there actually are 0kb sized files that seem to be related to APC being created under c:\winnt\temp. For instance, one of them is called ".apc.a02684".
This has come up previously on the MediaWiki Support Desk. MediaWiki apparently doesn't run under Apache 2.4.