php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #65078 opcache not enabled in embedded sapi / uwsgi
Submitted: 2013-06-21 00:15 UTC Modified: 2015-12-14 14:50 UTC
Votes:4
Avg. Score:4.5 ± 0.5
Reproduced:4 of 4 (100.0%)
Same Version:1 (25.0%)
Same OS:3 (75.0%)
From: info at icod dot de Assigned: rasmus (profile)
Status: Closed Package: opcache
PHP Version: 5.5.0 OS: linux 3.9.6
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: info at icod dot de
New email:
PHP Version: OS:

 

 [2013-06-21 00:15 UTC] info at icod dot de 
Description:
------------
Startup Failed 	Opcode Caching is only supported in Apache, ISAPI, FPM and FastCGI SAPIs 

uwsgi (my version 1.9.12)
http://projects.unbit.it/uwsgi/
uses the embed sapi to compile a php plugin
you can build plugins with different versions of php, good stuff.

you can use apc in php-5.4, one could use apc in php-5.5 but why?

the opcode cache is disabled because uwsgi is using the embedded sapi to build the plugin.

Test script:
---------------
<?php phpinfo(); ?>


Expected result:
----------------
Opcode Caching 	Enabled
Optimization 	Enabled

Actual result:
--------------
Opcode Caching 	Disabled
Optimization 	Disabled 
Startup Failed 	Opcode Caching is only supported in Apache, ISAPI, FPM and FastCGI SAPIs

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-06-21 00:17 UTC] info at icod dot de 
Server API 	uWSGI/php
 [2013-06-21 21:53 UTC] sixd@php.net 
You might want to get involved in this project: 
http://news.php.net/php.internals/67768
 [2014-01-28 02:55 UTC] hittingsmoke at gmail dot com 
Also getting this on PHP 5.5.8 with uwsgi 2.0.

Is this a PHP problem or a uwsgi problem?
 [2015-12-12 11:03 UTC] matthijs at stdin dot nl 
The project referenced two comments ago seems to be for enabling the opcache in the CGI and CLI SAPIs, which use a single process invocation for each request, so they need different ways of sharing and storing the cache.

However, UWSGI is a framework that uses persistent worker processes, using the embed SAPI. I don't know details about the forking behaviour of UWSGI, and it if fulfills the constraints for a shared OpCache, but even without sharing, caching opcodes within a single worker process would be useful.

I guess that always enabling the OpCache for the embed SAPI won't work - it could also be used in an one-off process, or without proper shard memory, etc. So I guess the proper fix for this is to provide an API that an embedding program can use to set up and enable the OpCache?
 [2015-12-14 12:51 UTC] matthijs at stdin dot nl 
I tried patching php to allow opcache to run inside uwsgi, by manually adding "uwsgi" to the list of enabled SAPIs (turns it that it used "uwsgi", not "embed" as I had expected). In any case, with that patch, things seem to run just fine. Performance increases to the expected level (compared with Apache and mod_php) and I haven't found any unexpected behaviour so far. Some tests (looking at phpinfo() generated by different uwsgi workers) suggests that the cache is properly shared between all uwsgi workers too).

It's trivial, but here's the patch I'm running with now:

--- a/ext/opcache/ZendAccelerator.c
+++ b/ext/opcache/ZendAccelerator.c
@@ -2434,6 +2434,7 @@ static inline int accel_find_sapi(TSRMLS
                "apache2filter",
                "apache2handler",
                "litespeed",
+               "uwsgi",
                NULL
        };
        const char **sapi_name;
 [2015-12-14 14:17 UTC] rasmus@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: rasmus
 [2015-12-14 14:17 UTC] rasmus@php.net 
Ok, added uwsgi to the list of supported SAPis in PHP 5.6 and 7. Thanks for verifying that it works.
 [2015-12-14 14:47 UTC] matthijs at stdin dot nl 
Awesome, thanks!

What PHP version can we expect this to be in? 5.6.16 is the current version, so I suspect that would be 5.6.17?
 [2015-12-14 14:50 UTC] rasmus@php.net 
No, sorry, 5.6.17 has already been tagged and RC1 released on Dec.10. This will be in 5.6.18.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sun Dec 22 11:01:30 2024 UTC