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/
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
Stanislav Malyshev wrote:
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.
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
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
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
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
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
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.
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?
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
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
Hi George,
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.
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,
Hi Pierre,
I also prefer BSD license as well, Johannes will make the final call, if
he think that it is a show stopper, I will dual-license it.
I have updated lsapi_main.c to address the "{ } after an if statement"
issue on the other day. If there is anything need to be taken care,
please just let me know.
Hopefully it will appear in the nightly build soon. :-)
Thanks,
George
Pierre Joye wrote:
Hi George,
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.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,
Hi Johannes,
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.
I have updated the license to have it dual-licensed under PHP and BSD
licenses.
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.
The code has been updated to follow the PHP coding standards in regard
of using { }, if there is any other issue, please let me know, I will
fix it ASAP.
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...
Either a symlink or moving the directory physically to where other SAPI
code are should work. I can check in the code to a different location if
need.
Please let me know if anything I can help. :-)
Thanks,
George
Hi George,
Either a symlink or moving the directory physically to where other SAPI
code are should work. I can check in the code to a different location if
need.Please let me know if anything I can help. :-)
Derick just copied it on the CVS server to php-src/sapi/litespeed and
gave you karma, please make a checkout of the PHP tree and test if all
works, then do a "cvs rm" on the old files in PECL so that's cleaned.
Thanks,
johannes
Hi Johannes,
Derick just copied it on the CVS server to php-src/sapi/litespeed and
gave you karma, please make a checkout of the PHP tree and test if all
works, then do a "cvs rm" on the old files in PECL so that's cleaned.
That's great! Thanks for the update.
Checkout a copy of php-src/sapi/litespeed, looks good. Also did the "cvs
rm" on the old files.
If anything else I can help, please just let me know.
Thanks,
George
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
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,
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 gwang@litespeedtech.com
wrote: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,
Hi Andi,
Litespeed != lighttpd
I know, I only said that I'm a lighttpd user</shameless lightty ad> :)
Cheers,
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
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,
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
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.
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,
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.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.
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
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.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.
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,
Uwe Schindler kirjoitti:
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.
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.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
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..
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
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
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.
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,
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.
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