nlopess Wed Jun 16 08:22:33 2004 EDT
Modified files:
/phpdoc/en language-snippets.ent
/phpdoc/en/faq installation.xml
/phpdoc/en/install/unix apache2.xml
Log:
move that apache compat stuff to a gaq entry, so that windows users will also read it
http://cvs.php.net/diff.php/phpdoc/en/language-snippets.ent?r1=1.97&r2=1.98&ty=u
Index: phpdoc/en/language-snippets.ent
diff -u phpdoc/en/language-snippets.ent:1.97 phpdoc/en/language-snippets.ent:1.98
--- phpdoc/en/language-snippets.ent:1.97 Wed Jun 16 07:11:19 2004
+++ phpdoc/en/language-snippets.ent Wed Jun 16 08:22:33 2004
@@ -1,4 +1,4 @@
-<!-- $Revision: 1.97 $ -->
+<!-- $Revision: 1.98 $ -->
<!-- Keep 'em sorted -->
@@ -354,8 +354,8 @@
<!-- Snippets for the installation section -->
<!ENTITY warn.apache2.compat '<warning><para>Do not use Apache 2.0.x
-and <literal>PHP</literal> in a production environment neither
-on Unix nor on Windows.</para></warning>'>
+and PHP in a production environment neither on Unix nor on Windows. Read also the
+<link linkend="faq.installation.apache2">FAQ entry</link></para></warning>'>
<!ENTITY note.apache.slashes '<note><simpara>Remember that when adding
path values in the Apache configuration files on Windows, all backslashes
http://cvs.php.net/diff.php/phpdoc/en/faq/installation.xml?r1=1.28&r2=1.29&ty=u
Index: phpdoc/en/faq/installation.xml
diff -u phpdoc/en/faq/installation.xml:1.28 phpdoc/en/faq/installation.xml:1.29
--- phpdoc/en/faq/installation.xml:1.28 Tue Jun 1 15:50:44 2004
+++ phpdoc/en/faq/installation.xml Wed Jun 16 08:22:33 2004
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.28 $ -->
+<!-- $Revision: 1.29 $ -->
<chapter id="faq.installation">
<title>Installation</title>
<titleabbrev>Installation</titleabbrev>
@@ -19,6 +19,86 @@
</para>
<qandaset>
+ <qandaentry id="faq.installation.apache2">
+ <question>
+ <para>
+ Why shouldn't I use Apache 2 in a production environment?
+ </para>
+ </question>
+ <answer>
+ <para>
+ The following answer is based in this modified excerpt of a mail
+ by Rasmus Lerdorf.
+ </para>
+ <para>
+ Apache 2 is a complete rewrite and a complete architecture change from
+ Apache 1. It is not like going from PHP 3 to PHP 4 or from PHP 4 to PHP 5.
+ There is a lot of code that is common, and certainly the base architecture
+ of PHP has not changed for years. So comparing Apache 1 vs. Apache 2 to
+ PHP 4 vs. PHP 5 makes no sense. The architecture has been proven over
+ the years and the code, while somewhat unwieldy in places, is a known
+ entity. PHP from the very early days was designed against this basic
+ Apache 1 architecture and works extremely well running under it.
+ </para>
+ <para>
+ The major feature that draws people to Apache 2 is threading. On Windows
+ where most basic libraries are, and must be, threadsafe, Apache 2 does
+ actually make sense and it would be good to work out the kinks on that
+ platform. However, on UNIX there are a lot of basic libraries where
+ thread safety is an unknown. And this is not about PHP extensions, it is
+ about 3rd-party libraries underneath PHP's hundreds of extensions.
+ Whether any one 3rd-party library is threadsafe is really hard to
+ determine. There are a lot of variables involved, including which OS,
+ which version of the OS, which libc, which version of that libc and on
+ some platforms even the compiler flags used to compile these things. And
+ to make it even more fun, tracking down a thread safety problem is damn
+ well near impossible. Hundreds of people may well state that
+ Apache+PHP+ext/foo works perfectly for them, but maybe they are only
+ getting about a million hits a day. Then another user comes along who
+ gets 100 million hits a day and uses a fast dual-cpu machine and
+ everything blows up because now suddenly the window for some tiny race
+ condition has been made much larger due to the faster cpu speeds, the
+ second cpu and the higher frequency of requests. And the bug report we
+ get from this user will be something along the lines of:
+ </para>
+ <para>
+ <quote>
+ It don't work sometimes. Most of the times it works fine, but then
+ every now and then it just don't. The error is different each time
+ and I have no idea how to reproduce it, but fix it right away!!!
+ </quote>
+ </para>
+
+ <para>What can we do about these?</para>
+ <para>
+ There are a number of (fixable) technical reasons Rasmus does not think
+ Apache2+PHP is a good idea in a production environment, but setting
+ those aside it really boils down to one simple concept:
+ </para>
+ <para>
+ PHP is glue. It is the glue used to build cool web applications by
+ sticking dozens of 3rd-party libraries together and making it all appear
+ as one coherent entity through an intuitive and easy to learn language
+ interface. The flexibility and power of PHP relies on the stability and
+ robustness of the underlying platform. It needs a working OS, a working
+ web server and working 3rd-party libraries to glue together. When any of
+ these stop working PHP needs ways to identify the problems and fix them
+ quickly. By making the underlying framework more complex by not having
+ completely separate execution threads, completely separate memory
+ segments and a strong sandbox for each request to play in, a feet of
+ clay is introduced into PHP's system.
+ </para>
+ <para>
+ Using the prefork mpm with Apache 2 to avoid the threading is possible,
+ and yes using a standalone fastcgi mechanism to avoid the threading,
+ too, but then defining characteristic of the web server of choice are
+ avoided. At this point in its development, Rasmus still maintains that
+ one is better off simply sticking with Apache1 for serving up PHP pages
+ with the one caveat that Apache 1 sucks pretty badly on Windows.
+ </para>
+ </answer>
+ </qandaentry>
+
<qandaentry id="faq.installation.phpini">
<question>
<para>
http://cvs.php.net/diff.php/phpdoc/en/install/unix/apache2.xml?r1=1.2&r2=1.3&ty=u
Index: phpdoc/en/install/unix/apache2.xml
diff -u phpdoc/en/install/unix/apache2.xml:1.2 phpdoc/en/install/unix/apache2.xml:1.3
--- phpdoc/en/install/unix/apache2.xml:1.2 Wed Jun 16 07:11:20 2004
+++ phpdoc/en/install/unix/apache2.xml Wed Jun 16 08:22:33 2004
@@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
-<!-- $Revision: 1.2 $ -->
+<!-- $Revision: 1.3 $ -->
<sect1 id="install.unix.apache2">
<title>Apache 2.0 on Unix systems</title>
<para>
@@ -7,89 +7,7 @@
of PHP on Unix systems.
</para>
- <warning>
- <para>
- Do not use Apache 2.0.x and <literal>PHP</literal> in a production
- environment neither on Unix nor on Windows. The reasoning behing
- that is explained thoroughly in this modified excerpt of a mail
- by Rasmus Lerdorf.
- </para>
-
- <para>
- Apache2 is a complete rewrite and a complete architecture change from
- Apache1. It is not like going from <literal>PHP3</literal> to
- <literal>PHP4</literal> or from <literal>PHP4</literal> to PHP5.
- There is a lot of code that is common, and certainly the base architecture
- of PHP has not changed for years. So comparing Apache1 vs. Apache2 to
- <literal>PHP4</literal> vs. <literal>PHP5</literal> makes no sense.
- The architecture has been proven over the years and the code, while
- somewhat unwieldy in places, is a known entity. PHP from the very
- early days was designed against this basic Apache1 architecture and
- works extremely well running under it.
- </para>
-
- <para>
- The major feature that draws people to Apache2 is threading. On Windows
- where most basic libraries are, and must be, threadsafe, Apache2 does
- actually make sense and it would be good to work out the kinks on that
- platform. However, on UNIX there are a lot of basic libraries where
- thread safety is an unknown. And this is not about <literal>PHP</literal>
- extensions, it is about 3rd-party libraries underneath
<literal>PHP's</literal>
- hundreds of extensions. Whether any one 3rd-party library is threadsafe is
- really hard to determine. There are a lot of variables involved, including
which
- OS, which version of the OS, which libc, which version of that libc and on
- some platforms even the compiler flags used to compile these things. And
- to make it even more fun, tracking down a thread safety problem is damn
- well near impossible. Hundreds of people may well state that
- Apache+<literal>PHP</literal>+ext/foo works perfectly for them, but maybe
- they are only getting about a million hits a day. Then another user comes
- along who gets 100 million hits a day and uses a fast dual-cpu machine and
- everything blows up because now suddenly the window for some tiny race
- condition has been made much larger due to the faster cpu speeds, the
- second cpu and the higher frequency of requests. And the bug report we
- get from this user will be something along the lines of:
- </para>
-
- <para>
- <note>
- It don't work sometimes. Most of the times it works fine, but then
- every now and then it just don't. The error is different each time
- and I have no idea how to reproduce it, but fix it right away!!!
- </note>
- </para>
-
- <para>What can we do about these?</para>
-
- <para>
- There are a number of (fixable) technical reasons Rasmus does not think
- Apache2+<literal>PHP</literal> is a good idea in a production environment,
- but setting those aside it really boils down to one simple concept:
- </para>
-
- <para>
- <literal>PHP</literal> is glue. It is the glue used to build cool web
- applications by sticking dozens of 3rd-party libraries together and making
- it all appear as one coherent entity through an intuitive and easy to learn
- language interface. The flexibility and power of <literal>PHP</literal>
relies
- on the stability and robustness of the underlying platform. It needs a
working
- OS, a working web server and working 3rd-party libraries to glue together.
- When any of these stop working <literal>PHP</literal> needs ways to identify
- the problems and fix them quickly. By making the underlying framework more
- complex by not having completely separate execution threads, completely
- separate memory segments and a strong sandbox for each request to play
- in, a feet of clay is introduced into <literal>PHP's</literal> system.
- </para>
-
- <para>
- Using the prefork mpm with Apache2 to avoid the
- threading is possible, and yes using a standalone fastcgi mechanism to avoid
- the threading, too, but then defining characteristic of the web server of
- choice are avoided. At this point in its development, Rasmus still maintains
- that one is better off simply sticking with Apache1 for serving up
- <literal>PHP</literal> pages with the one caveat that Apache1 sucks pretty
badly
- on Windows.
- </para>
- </warning>
+ &warn.apache2.compat;
<para>
You are highly encouraged to take a look at the
