# Inclusion of PHP LiteSpeed SAPI in the standard PHP distribution? - Thread: https://externals.io/message/36453 - Original archive: https://news-web.php.net/php.internals/36453 - Started by George Wang on 2008-03-24T20:27:37+00:00 - Messages: 29 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/36453.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #36453 — George Wang — 2008-03-24T20:27:37+00:00 URL: https://externals.io/message/36453#36453 Hi, It has been over two years since the last time we wrote to the list to consider the inclusion of litespeed SAPI module in the stand PHP distribution. By that time, our code has been added to CVS repository under /pecl/litespeed, and I have been told that "if there is enough independent user demand for it and we are comfortable with the quality of the code, it will go in." In two years, we have been improving the SAPI module to a very stable state, and our user base has grown substantially, LiteSpeed is the top 10 web server in the world according to netcraft. http://survey.netcraft.com/Reports/200803/ I believe, besides the apache SAPI and fcgi SAPI, LiteSpeed SAPI is one of the top PHP SAPI being used in production environment. And LiteSpeed SAPI has the combination of best performance, configuration flexibility via .htaccess and enhanced security with SuEXEC. Right now, our users have to apply "LiteSpeed" patch to the PHP package manually, which is not convenient. We'd like to work closely with PHP community to have our LiteSpeed SAPI code included and continue to improve PHP performance and scalability. The latest source code has been checked in to http://cvs.php.net/viewvc.cgi/pecl/litespeed/ I am ready to help with any code changes required to meet PHP coding standard. Thanks, George Wang http://www.litespeedtech.com/ --- ## #36454 — Stanislav Malyshev — 2008-03-24T20:38:14+00:00 URL: https://externals.io/message/36453#36454 · In reply to: #36453 Hi! > I believe, besides the apache SAPI and fcgi SAPI, LiteSpeed SAPI is one > of the top PHP SAPI being used in production environment. And LiteSpeed > SAPI has the combination of best performance, configuration flexibility > via .htaccess and enhanced security with SuEXEC. I did not look into the SAPI yet, but if it works good and conforms to PHP project reqs (code standards, license, etc.) then I see no reason not to add it, provided the popularity data and the fact that we have much more exotic SAPIs in the core. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36455 — Rasmus Lerdorf — 2008-03-24T20:46:13+00:00 URL: https://externals.io/message/36453#36455 · In reply to: #36454 Stanislav Malyshev wrote: > Hi! > > > […] > > I did not look into the SAPI yet, but if it works good and conforms to > PHP project reqs (code standards, license, etc.) then I see no reason > not to add it, provided the popularity data and the fact that we have > much more exotic SAPIs in the core. Well, popularity-wise it has about 0.003% of the web server market. So I wouldn't put too much stock in that. We also have yet to ever see a user request for it. You are right though, that we have other really odd SAPIs in the core, but that is mostly a result of never having figured out how build a sapi module standalone. Most of these really do belong in pecl if we could solve the standalone issue. -Rasmus --- ## #36456 — Stanislav Malyshev — 2008-03-24T20:54:59+00:00 URL: https://externals.io/message/36453#36456 · In reply to: #36455 > You are right though, that we have other really odd SAPIs in the core, > but that is mostly a result of never having figured out how build a sapi > module standalone. Most of these really do belong in pecl if we could > solve the standalone issue. Right, but if we didn't solve it - why we have pi3web or webjames (what that is anyway?) and not litespeed? At least litespeed appears on the map. As for user request, I think server's vendor request is a user request, when PHP is concerned - why have PHP API on a server if not to use it? As soon as we have commitment from the support side - and I understand we have it here - I see no problem in having this SAPI. Of course, figuring out how to do SAPI in PECL is a solution too, but is anybody working on it? -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36461 — George Wang — 2008-03-24T21:55:29+00:00 URL: https://externals.io/message/36453#36461 · In reply to: #36455 > Well, popularity-wise it has about 0.003% of the web server market. > So I wouldn't put too much stock in that. We also have yet to ever > see a user request for it. As to user request, here is one :-) http://bugs.php.net/bug.php?id=42987 One of the reasons why did not receive much requests is that we tried our best to make it easier for our end users, including a pre-built PHP binary, tutorials, web GUI for building the PHP binary, etc. But it still requires extra devel-packages like autoconf, m4, etc. Best Regards, George --- ## #36465 — Thomas Seifert — 2008-03-24T22:23:52+00:00 URL: https://externals.io/message/36453#36465 · In reply to: #36455 Hi, Rasmus Lerdorf schrieb: > Well, popularity-wise it has about 0.003% of the web server market. So > I wouldn't put too much stock in that. We also have yet to ever see a > user request for it. beside all the other posts about it - regular users don't post requests that often to the internal lists as they are quickly hunted down ;). I'm one of these users who would really appreciate it if the LSAPI could get into the core to make it far easier to install and use. The SAPI has been supported for years without much trouble therefore I guess you can count on the support from Litespeed for their own product. Regards, thomas --- ## #36469 — Pierre Joye — 2008-03-25T00:09:29+00:00 URL: https://externals.io/message/36453#36469 · In reply to: #36453 Hi George, > It has been over two years since the last time we wrote to the list to > consider the inclusion of litespeed SAPI module in the stand PHP > distribution. By that time, our code has been added to CVS repository > under /pecl/litespeed, and I have been told that "if there is enough > independent user demand for it and we are comfortable with the quality > of the code, it will go in." I'm not a user of litespeed (lighttpd here) but it is a relatively well known server in the "lite" category (cherokee, lighttpd & co). I see no reason to reject it as long as they maintain it, +1 here :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36475 — Andi Gutmans — 2008-03-25T05:31:32+00:00 URL: https://externals.io/message/36453#36475 · In reply to: #36469 Litespeed != lighttpd In any case, we've always been pretty liberal about these kind of SAPI extensions in order to ensure out-of-the-box experience for our users. Esp. as litespeed are willing to support it and we have precedence of Web servers which are far less common I really don't think there's a good reason not to include it. It won't break other SAPI extensions... Btw, is this a multi-threaded SAPI or is it a FastCGI replacement? (i.e. multi-process). Just curious... Andi > -----Original Message----- > From: Pierre Joye [mailto:pierre.php@gmail.com] > Sent: Monday, March 24, 2008 5:09 PM > To: George Wang > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Inclusion of PHP LiteSpeed SAPI in the standard > PHP distribution? > > Hi George, > > On Mon, Mar 24, 2008 at 9:27 PM, George Wang > wrote: > > > […] > to > > […] > repository > > […] enough > > […] > quality > > […] > > I'm not a user of litespeed (lighttpd here) but it is a relatively > well known server in the "lite" category (cherokee, lighttpd & co). I > see no reason to reject it as long as they maintain it, +1 here :) > > Cheers, > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org --- ## #36481 — Pierre Joye — 2008-03-25T10:12:22+00:00 URL: https://externals.io/message/36453#36481 · In reply to: #36475 Hi Andi, > Litespeed != lighttpd I know, I only said that I'm a lighttpd user :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36497 — gwang@litespeedtech.com — 2008-03-25T14:05:52+00:00 URL: https://externals.io/message/36453#36497 · In reply to: #36475 > Btw, is this a multi-threaded SAPI or is it a FastCGI replacement? (i.e. > multi-process). Just curious... Like FastCGI PHP, PHP with LiteSpeed SAPI run out of server process in multi-process mode, the main difference to FastCGI SAPI is: Highly optimized protocol to avoid overhead. Built-in process manager to dynamically start/stop children processes base on current load. PHP configuration overridden via .htaccess Even though our LSAPI implementation should work well with multi-thread applications, we choose multi-process model because PHP is more reliable with multi-process. Best Regards, George Wang --- ## #36499 — Pierre Joye — 2008-03-25T14:15:36+00:00 URL: https://externals.io/message/36453#36499 · In reply to: #36497 Hi George > Highly optimized protocol to avoid overhead. > Built-in process manager to dynamically start/stop children processes > base on current load. > PHP configuration overridden via .htaccess As of php 5.3, it is possible to have a per directory configuration, either using the system php.ini or using a .htaccess-like php.ini (.user.ini). The concept is based on what you have in htscanner but in a much better way (same syntax than in any php.ini). The goal is to enable this feature in all SAPIs. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36511 — George Wang — 2008-03-25T17:11:32+00:00 URL: https://externals.io/message/36453#36511 · In reply to: #36499 Pierre, > As of php 5.3, it is possible to have a per directory configuration, > either using the system php.ini or using a .htaccess-like php.ini > (.user.ini). The concept is based on what you have in htscanner but in > a much better way (same syntax than in any php.ini). The goal is to > enable this feature in all SAPIs. > We do not use htscanner. LiteSpeed web server is fully compatible with Apache .htaccess configuration file, and we use a highly efficient htaccess cache to reduce the overhead of reload configuration in .htaccess for each request like what Apache does. PHP related configuration will be passed to PHP process through a IPC socket along with other request data. I am sure the new per directory configuration should work with LiteSpeed SAPI. However, if it needs to scan each directory repeatedly for each request, it will slow down PHP even further. Best Regards, George --- ## #36512 — Pierre Joye — 2008-03-25T17:28:51+00:00 URL: https://externals.io/message/36453#36512 · In reply to: #36511 > Pierre, > > > > […] > I am sure the new per directory configuration should work with LiteSpeed > SAPI. However, if it needs to scan each directory repeatedly for each > request, it will slow down PHP even further. It is cached using a user defined ttl. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36516 — Uwe Schindler — 2008-03-25T19:43:29+00:00 URL: https://externals.io/message/36453#36516 · In reply to: #36512 > > […] > in > > […] > > > […] > LiteSpeed > > […] > > It is cached using a user defined ttl. Hi Pierre, How do I enable another SAPIs for this per-dir ini files? How are they named? Found no documentation about it. I would like to upgrade my NSAPI module (Sun Webservers) for it. As Sun Webservers do not know .htaccess files, PHP is hard to configure for specific directories (it is possible, but you must map all ini entries as extra parameters in the php5_execute NSAPI call, which can be made per-dir, in the central config files). A per-dir config by "magic files" like ".php.ini" in script folder would be good. Is there a generic solution for SAPIs? Uwe --- ## #36517 — Pierre Joye — 2008-03-25T19:51:14+00:00 URL: https://externals.io/message/36453#36517 · In reply to: #36516 > > […] > > Hi Pierre, > > How do I enable another SAPIs for this per-dir ini files? How are they > named? Found no documentation about it. > I would like to upgrade my NSAPI module (Sun Webservers) for it. As Sun > Webservers do not know .htaccess files, PHP is hard to configure for > specific directories (it is possible, but you must map all ini entries as > extra parameters in the php5_execute NSAPI call, which can be made per-dir, > in the central config files). A per-dir config by "magic files" like > ".php.ini" in script folder would be good. > Is there a generic solution for SAPIs? Not yet sadly, it is on our todo for 5.3. It is now available only for fcgi but we have to provide for each sapi. We will then finally have one portable solution to configure PHP on a per directory basis. Any help is welcome, if you like to give it a try :) It should not be very hard to do it (sapi hook and move the common parts in php main code afair). I can give a hand too but definitively not in the next 2 weeks. But we have to finish it before end of April to be ready for 5.3 (~). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36518 — Jani Taskinen — 2008-03-25T19:55:44+00:00 URL: https://externals.io/message/36453#36518 · In reply to: #36516 Uwe Schindler kirjoitti: > > […] > > Hi Pierre, > > How do I enable another SAPIs for this per-dir ini files? How are they > named? Found no documentation about it. > I would like to upgrade my NSAPI module (Sun Webservers) for it. As Sun > Webservers do not know .htaccess files, PHP is hard to configure for > specific directories (it is possible, but you must map all ini entries as > extra parameters in the php5_execute NSAPI call, which can be made per-dir, > in the central config files). A per-dir config by "magic files" like > ".php.ini" in script folder would be good. > Is there a generic solution for SAPIs? The stuff is pretty generic, just check how it's done for sapi/cgi/cgi_main.c in function sapi_cgi_activate(). (IIRC :) I think I even put some comments in there.. --Jani --- ## #36519 — Uwe Schindler — 2008-03-25T20:13:49+00:00 URL: https://externals.io/message/36453#36519 · In reply to: #36518 > > […] > > The stuff is pretty generic, just check how it's done for > sapi/cgi/cgi_main.c in > function sapi_cgi_activate(). (IIRC :) > > I think I even put some comments in there.. Yes, looks good. Even the host-based config could be enabled by NSAPI. The code looks very generic and could be put directly into a generic SAPI function that runs after register_variables. You only need then _SERVER['DOCUMENT_ROOT'] (the length) and the script filename and HTTP_HOST/SERVER_NAME which is registered by every SAPI. One problem is in the per dir user config code: If one maps an alias for a directory containing the PHP scripts into his webserver config, the document root may not be a substring of the script file name, which would be a problem for the user config loading algorithm... You put the code into activate, but it may also be possible to do all this in the request startup I think...? I think we should discuss this in an extra thread. I would be happy to help with a generic solution (e.g. before script startup) and would help in implementing it! Uwe --- ## #36521 — George Wang — 2008-03-25T20:55:59+00:00 URL: https://externals.io/message/36453#36521 · In reply to: #36519 > but it may also be possible to do all this in the request startup I think...? > I don't like the idea to keep adding stuff in request startup, at least, please make it optional. The overhead for request startup and cleanup have becoming higher and higher, which make PHP become slower and slower, especially for simple request like a "Hello World" request, it put PHP into a less competitive position when benchmark with other scripting languages. I wish I could do something in that regarding in the future, at least for our LiteSpeed SAPI if others does not like it. Best Regards, George Wang --- ## #36522 — Pierre Joye — 2008-03-25T21:29:13+00:00 URL: https://externals.io/message/36453#36522 · In reply to: #36521 > > > […] > I don't like the idea to keep adding stuff in request startup, at least, > please make it optional. It is optional, it can be disabled completely. However the impact is not different than having a htaccess (or similar) and the cache makes it almost transparent. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #36523 — Uwe Schindler — 2008-03-25T21:47:42+00:00 URL: https://externals.io/message/36453#36523 · In reply to: #36521 > > […] > think...? > > […] > I don't like the idea to keep adding stuff in request startup, at least, > please make it optional. The overhead for request startup and cleanup > have becoming higher and higher, which make PHP become slower and > slower, especially for simple request like a "Hello World" request, it > put PHP into a less competitive position when benchmark with other > scripting languages. > > I wish I could do something in that regarding in the future, at least > for our LiteSpeed SAPI if others does not like it. The code in CGI is called in sapi_activate, which is called from php_request_startup() just before the scripts starts. In this stage you can choose the right config (e.g. from the cache) by using the script directory as entry in has table or something like that. You do not need to search for config files in a whole directory tree below DOCUMENT_ROOT and the script directory every time. Uwe --- ## #36565 — George Wang — 2008-03-26T20:07:56+00:00 URL: https://externals.io/message/36453#36565 · In reply to: #36461 OK, let's back to the topic, is there any conclusion on this topic yet? I certainly would like not to miss the release of 5.3 and ready to help with any issue. > As to user request, here is one :-) > > http://bugs.php.net/bug.php?id=42987 According to this ticket, this has been assigned to johannes, should I follow up with this ticket to get it going? His last update to the ticket is "I saw that some files use another license than PHP License and other refer to an outdated version. when bundling they should be licensed under the current PHP License 3.01." Our LSAPI library code has been license under BSD license, and there are other BSD licensed code get into PHP core, like PCRE, GD, etc. Is that really a concern? Do I have to change it to PHP license? Please let me know if there are other concerns. Thanks, George Wang --- ## #36566 — Stanislav Malyshev — 2008-03-26T20:15:09+00:00 URL: https://externals.io/message/36453#36566 · In reply to: #36565 Hi! > According to this ticket, this has been assigned to johannes, should I > follow up with this ticket to get it going? Johannes is the RM for 5.3, so he decides if/when it gets in. :) > Our LSAPI library code has been license under BSD license, and there are If extension and library are BSD, license shouldn't be any problem. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #36588 — johannes@php.net — 2008-03-26T23:30:18+00:00 URL: https://externals.io/message/36453#36588 · In reply to: #36565 Hi, > OK, let's back to the topic, is there any conclusion on this topic yet? > I certainly would like not to miss the release of 5.3 and ready to help > with any issue. I think it makes sense, you, as the server's vendor, supports it and whatever the exact usage number are there seem to be users who certainly benefit from it. > > […] > According to this ticket, this has been assigned to johannes, should I > follow up with this ticket to get it going? > His last update to the ticket is > > "I saw that some files use another license than PHP License and other refer > > to an outdated version. when bundling they should be licensed under the > current PHP License 3.01." > > > Our LSAPI library code has been license under BSD license, and there are > other BSD licensed code get into PHP core, like PCRE, GD, etc. Is that > really a concern? Do I have to change it to PHP license? Well, the idea is that all PHP-specific code is licensed under the same license terms. PCRE and GD are external libraries which live outside PHP's context and which are simply bundled. That's why the clear preference there is PHP License. Additionally it would nice to follow the PHP coding standards. Like always having { } after an if statement. This helps PHP developers who might (possibly) help fixing reported (simple) bugs or apply API changes. Other than that we, again, have our problem about what's the best way to "bundle" something from pecl. I guess the symlink on the CVS server is the best option we currently have... johannes --- ## #36622 — George Wang — 2008-03-27T19:11:17+00:00 URL: https://externals.io/message/36453#36622 · In reply to: #36588 Hi Johannes, Thank you for the quick reply. > Well, the idea is that all PHP-specific code is licensed under the same > license terms. PCRE and GD are external libraries which live outside > PHP's context and which are simply bundled. That's why the clear > preference there is PHP License. > OK, let me make some clarifications on this. the main SAPI code, lsapi_main.c, which is specific for PHP, has been licensed under PHP license. Other c source code are our generic LSAPI library, which will be used for all third parties integrations, those files are licensed under BSD license. I don't mind dual license those code under both BSD and PHP license if required as long as it won't prevent us from using the same code somewhere else under BSD license. > Additionally it would nice to follow the PHP coding standards. Like > always having { } after an if statement. This helps PHP developers who > might (possibly) help fixing reported (simple) bugs or apply API > changes. > No problem, will do. :-) If there is other requirements, please just let me know. > Other than that we, again, have our problem about what's the best way to > "bundle" something from pecl. I guess the symlink on the CVS server is > the best option we currently have... > I have no problem with moving or recreating that directory at the right place either. Thanks, George --- ## #36623 — Pierre Joye — 2008-03-27T19:19:30+00:00 URL: https://externals.io/message/36453#36623 · In reply to: #36622 Hi George, > Hi Johannes, > > Thank you for the quick reply. > > > > […] > OK, let me make some clarifications on this. > the main SAPI code, lsapi_main.c, which is specific for PHP, has been > licensed under PHP license. > Other c source code are our generic LSAPI library, which will be used > for all third parties integrations, those files are licensed under BSD > license. > > I don't mind dual license those code under both BSD and PHP license if > required as long as it won't prevent us from using the same code > somewhere else under BSD license. I don't think it is necessary. If you like to bundle the LSAPI library, it is perfectly fine to keep it under the BSD license. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/36453.md?page=2