[sylvain] r51072 - in silvadoccenter/trunk/source: . cluster
[email protected] Wed, 4 Sep 2013 11:43:35 +0200 (CEST)
| Newsgroups | gmane.comp.web.zope.silva.cvs |
|---|---|
| Message-ID | <[email protected]> |
Author: sylvain
Date: Wed Sep 4 11:43:35 2013
New Revision: 51072
Modified:
silvadoccenter/trunk/source/apache.rst
silvadoccenter/trunk/source/cluster/index.rst
silvadoccenter/trunk/source/cluster/memcached.rst
silvadoccenter/trunk/source/cluster/relstorage.rst
silvadoccenter/trunk/source/cluster/uploading.rst
silvadoccenter/trunk/source/getting-started-with-silva.rst
silvadoccenter/trunk/source/hosting.rst
silvadoccenter/trunk/source/uwsgi.rst
silvadoccenter/trunk/source/wsgi.rst
Log:
Various updates, details and clarifications.
Modified: silvadoccenter/trunk/source/apache.rst
==============================================================================
--- silvadoccenter/trunk/source/apache.rst (original)
+++ silvadoccenter/trunk/source/apache.rst Wed Sep 4 11:43:35 2013
@@ -17,10 +17,6 @@
go through Apache as well.
-.. note:: You are free to use other proxy software if they support
- rewriting of URLs. You can use `Nginx`_ or directly `Squid`_ if you
- want to do caching as well.
-
Configuring rewrite rules in Apache
-----------------------------------
@@ -147,9 +143,8 @@
equivalent of multiple rewrite rules inside a given site.
-.. _Nginx: http://nginx.org/
.. _Squid: http://www.squid-cache.org/
.. _mod_proxy: http://httpd.apache.org/docs/2.2/mod/mod_proxy.html
.. _mod_proxy_http: http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html
.. _mod_rewrite: http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html
-.. _silva.app.forest: http://infrae.com/download/silva_all/silva.app.forest
+.. _silva.app.forest: http://silvacms.org/getsilva/packages/silva_all/silva.app.forest
Modified: silvadoccenter/trunk/source/cluster/index.rst
==============================================================================
--- silvadoccenter/trunk/source/cluster/index.rst (original)
+++ silvadoccenter/trunk/source/cluster/index.rst Wed Sep 4 11:43:35 2013
@@ -3,14 +3,21 @@
Silva High-Availability Installation
====================================
-For sites with lots of traffic, only one Zope server to handle all the
-incoming requests might not be enough. You have to setup a cluster in
-this case. The cluster will be composed of a database server, multiple
-Zope servers using this database and of a load balancer that
-distributes the incoming traffic among the different Zope servers.
-
-Each of those components can be installed on separate servers, or on
-the same.
+For sites with lots of traffic, only one Silva server, with one
+processus might not be enough to handle all the incoming requests. You
+need to install a cluster in this case. The cluster will be composed
+of at least a database server, multiple Silva servers (with multiple
+processus) using this database, a load balancer or an HTTP frontend
+server or even an HTTP cache proxy that distributes the incoming traffic
+among the different Silva servers.
+
+Each of those components can be installed on different hardware
+servers, or on the same, depending on the expected load, the hardware
+and the degree of failover you wish to attain.
+
+The configuration of multiple Silva server and the various existing
+possibilities to distribute requests on them is described in
+:ref:`presenting-your-silva-site-to-the-world`.
Depending on your requirements, you can configure the database server
in two different ways:
@@ -22,8 +29,8 @@
relstorage
-Moreover, if you have more than one Zope server using the same database,
-you need to install and configure ``memcached`` for Silva:
+Moreover, if you have more than one Silva processus using the same
+database, you need to install and configure ``memcached`` for Silva:
.. toctree::
:maxdepth: 2
@@ -31,19 +38,6 @@
memcached
-As a load balancer in front, you can use:
-
-- Apache `mod_proxy_balancer`_,
-
-- `Pound`_,
-
-- `Squid`_,
-
-- `NGinx`_ and `uWSGI`_.
-
-- An hardware solution (usually expensive).
-
-
In case of large cluster, you can configure an upload server for files:
.. toctree::
@@ -51,19 +45,23 @@
uploading
+If you send lot of emails from Silva (notifications and such), we
+recommend you to use MaildropHost. This can be installed with the help
+of the recipe `infrae.maildrophost`_ in :term:`Buildout` (see
+:ref:`extending-and-customising-your-installation` for more
+information). MaildropHost works with the help of an additional
+processus to actually send the emails. If you have multiple Silva
+servers on the same physical server, only one MaildropHost processus
+is needed for the physical server.
Note about the date and time configuration
------------------------------------------
If you have multiple physical or virtual servers inside your cluster,
-we recommand you to properly configure each server so their time
+we recommend you to properly configure each server so their time
settings is properly synchronized with a common source. You can
enforce it on Unix by configuring an NTP server with
``ntpdate``. Failing to do so might creates problems with the default
authentication method used in Silva.
-.. _mod_proxy_balancer: http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
-.. _Squid: http://www.squid-cache.org/
-.. _Pound: http://www.apsis.ch/pound/
-.. _NGinx: http://nginx.org/
-.. _uWSGI: http://projects.unbit.it/uwsgi/
+.. _infrae.maildrophost: https://pypi.python.org/pypi/infrae.maildrophost
Modified: silvadoccenter/trunk/source/cluster/memcached.rst
==============================================================================
--- silvadoccenter/trunk/source/cluster/memcached.rst (original)
+++ silvadoccenter/trunk/source/cluster/memcached.rst Wed Sep 4 11:43:35 2013
@@ -4,7 +4,7 @@
===================================
Silva can use `memcached`_ as cache backend. It is required to use it
-as soon as you have more than one Zope servers hosting the same Silva
+as soon as you have more than one Silva servers hosting the same Silva
site (meaning you use :term:`ZEO` or RelStorage).
.. contents::
Modified: silvadoccenter/trunk/source/cluster/relstorage.rst
==============================================================================
--- silvadoccenter/trunk/source/cluster/relstorage.rst (original)
+++ silvadoccenter/trunk/source/cluster/relstorage.rst Wed Sep 4 11:43:35 2013
@@ -3,9 +3,9 @@
`Relstorage`_ let Zope stores its data into a SQL server.
-Multiple Zope instance can connect simultaneously to the same SQL
+Multiple Silva processus can connect simultaneously to the same SQL
database to use the same data, making possible it to distribute the
-requests among those multiple Zope instance. This creates an
+requests among those multiple Silva servers. This creates an
installation equivalent to one using ZEO, without ZEO.
If your SQL server support fail-over, you can have a full fail-over
@@ -21,7 +21,8 @@
We don't recommand to store the blobs inside the SQL server, but to
continue to store them on the filesystem, inside a directory that is
-shared among the various servers you have, if you have more than one.
+shared among the various servers you have, if you have more than
+one. NFS is efficiant way to do so.
.. warning::
@@ -104,9 +105,9 @@
.. warning::
We recommend to use a different memcache instance than the one used
- for Silva to cache RelStorage data. *All* Zope server connected
+ for Silva to cache RelStorage data. *All* Silva server connected
to the same SQL database should share the *same* memcached
- server.
+ instance.
.. _RelStorage: http://pypi.python.org/pypi/RelStorage
Modified: silvadoccenter/trunk/source/cluster/uploading.rst
==============================================================================
--- silvadoccenter/trunk/source/cluster/uploading.rst (original)
+++ silvadoccenter/trunk/source/cluster/uploading.rst Wed Sep 4 11:43:35 2013
@@ -5,10 +5,20 @@
======================================
You have the possibility to configure a separate server in order to
-upload files in Silva. This is usefull if you have a large setup
-and/or upload lot of files, since the upload will no longer interfer
-with the performances of the setup (since they can last long, this
-prevent them to block resources).
+upload files in Silva. This is useful if you have a large setup and/or
+upload a lot of files, since the upload will no longer interfer with the
+performances of the installation. Since those requests can last long,
+this prevent them to block resources.
The upload server is a small WSGI application. Like for Silva, you can
choose the WSGI server of your choice.
+
+
+.. note::
+
+ Because Nginx bufferize every upload in memory or temporary files,
+ we don't recommend to use it with the upload server, or to use the
+ `upload progress module`_. This module is compatible with Silva if
+ it is configured to generate a JSONP output.
+
+.. _upload progress module: http://wiki.nginx.org/HttpUploadProgressModule
Modified: silvadoccenter/trunk/source/getting-started-with-silva.rst
==============================================================================
--- silvadoccenter/trunk/source/getting-started-with-silva.rst (original)
+++ silvadoccenter/trunk/source/getting-started-with-silva.rst Wed Sep 4 11:43:35 2013
@@ -77,6 +77,11 @@
$ ./bin/paster serve deploy.ini status
+For obvious security reasons, we don't recommand to run Silva using a
+privileged user like ``root`` on Unix, but a regular non-privileged
+user. If you wish to start the server as such, we recommend you to use
+``sudo`` at all time.
+
Running in development mode
---------------------------
Modified: silvadoccenter/trunk/source/hosting.rst
==============================================================================
--- silvadoccenter/trunk/source/hosting.rst (original)
+++ silvadoccenter/trunk/source/hosting.rst Wed Sep 4 11:43:35 2013
@@ -1,12 +1,15 @@
-Presenting your Silva instance to the world
-===========================================
+.. _presenting-your-silva-site-to-the-world:
-Using ``bin/paster`` is fine for small installation. We recommand to
+Presenting your Silva site to the world
+=======================================
+
+Using ``bin/paster`` is fine for small installation. We recommend to
configure Apache in front of it in order to have a more user-friendly
-URL in order to access your Silva instance.
+URL in order to access your Silva server.
+
+For larger installation we recommend to use either `uWSGI`_ and
+`Nginx`_, or ``mod_wsgi``.
-For larger installation we recommand to use either uWSGI and NGinx, or
-``mod_wsgi``.
.. toctree::
:maxdepth: 2
@@ -15,3 +18,44 @@
uwsgi
wsgi
+
+You will probably want to rewrite the URL of your Silva in order to
+expose it to the public. In order to do so you can either use the Zope
+Virtual Host (see :ref:`zope-virtual_host_monster`) for small
+installations, or `silva.app.forest`_ for larger installations that
+will provides you with more flexibility.
+
+
+In case of large installations you might to install an HTTP cache in
+front of your Silva servers. Recommended possibilities are:
+
+- `Varnish`_,
+
+- `Squid`_.
+
+If you still have multiple Silva servers and do not wish to install a
+cache you will still need to install a load balancer in front of
+them. Recommended possibilities are:
+
+- Using `Nginx`_ and `uWSGI`_ in the previously proposed configuration
+ already provides this feature natively,
+
+- Apache `mod_proxy_balancer`_,
+
+- `Squid`_ or `Varnish`_,
+
+- `Pound`_,
+
+- An hardware solution (usually expensive).
+
+For large installations, you can refer to
+:ref:`silva-high-availability-installation` for more information.
+
+
+.. _mod_proxy_balancer: http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
+.. _Pound: http://www.apsis.ch/pound/
+.. _Varnish: https://www.varnish-cache.org/
+.. _Squid: http://www.squid-cache.org/
+.. _uWSGI: http://uwsgi-docs.readthedocs.org/
+.. _Nginx: http://nginx.org/
+.. _silva.app.forest: http://silvacms.org/getsilva/packages/silva_all/silva.app.forest
Modified: silvadoccenter/trunk/source/uwsgi.rst
==============================================================================
--- silvadoccenter/trunk/source/uwsgi.rst (original)
+++ silvadoccenter/trunk/source/uwsgi.rst Wed Sep 4 11:43:35 2013
@@ -2,9 +2,9 @@
=============================================================
You can install `uWSGI`_ and `Nginx`_ in order to serve your Silva
-site. This is recommanded way for large installations. In this setup
-you will have an `uWSGI`_ instance, that runs, and an `Nginx`_ server
-that connects to it.
+site. This is recommended way for large installations. In this setup
+you will have an `uWSGI`_ server that runs independently and an
+`Nginx`_ server that connects to it.
.. contents::
@@ -14,11 +14,13 @@
Because `uWSGI`_ must be compiled with the same Python interpreter
than the one used to install Silva, and that its configuration
contains all the paths to the various Python packages used by Silva,
-the best way to install it is to use Buildout. To do so, you need to
-be already familiar with Buildout. If you are not please read
-:ref:`extending-and-customising-your-installation` first.
-
-You can use the recipe `infrae.uwsgi`_ in order to install it:
+the best way to install it is to use :term:`Buildout`. To do so, you
+need to be already familiar with :term:`Buildout`. If you are not
+please read :ref:`extending-and-customising-your-installation` first.
+
+You can use the recipe `infrae.uwsgi`_ in order to install
+`Nginx`_. For instance in your buildout configuration file
+``buildout.cfg`` you can add:
.. code-block:: buildout
:linenos:
@@ -50,55 +52,63 @@
bind and listen on. The uWSGI socket defined on line 10 will be used
to interact with Nginx. The http socket defined on line 9 is
optional, but let you access your uWSGI server with your web
- browser.
+ browser if you define it.
- Line 11 and 12 ask uWSGI to load the Paster configuration generated
- by buildout, that is used if you start your instance the in a simple
- fashion (:ref:`starting-creating-silva-site`).
+ by buildout. This points to the same configuration file that is used
+ if you start your instance the in a simple fashion
+ (:ref:`starting-creating-silva-site`).
- Lin 13 and 14 defines the number of processus and threads you want
to use. If you want to use more than one processus, you need to
setup either a RelStorage or a ZEO server (see
- :ref:`silva-high-availability-installation`). Specify an higher
- number of threads won't improve at all the performances and might
- even reduce them.
+ :ref:`silva-high-availability-installation`). Specifying an higher
+ number of threads than what is given in this example won't improve
+ at all the performances and might even reduce them.
- Line 17 defines the option ``lazy`` which is critical in order to
- use the ZODB. **Not specifying this option might result in losing
- data**.
+ operate the ZODB. **Not specifying this option might results in
+ losing data**.
- Line 18 and 19 tells uWSGI to act as a daemon and go in the
background after it started. If you wish to run it as foreground
instead you can omit those two directives.
-You can specify here in the Buildout configuration any existing `uWSGI
-configuration option`.
+You can specify here in the :term:`Buildout` configuration any
+existing `uWSGI configuration option`.
Managing your uWSGI instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-You can start your `uWSGI`_ instance like this:
+You can start your `uWSGI`_ server like this:
.. code-block:: sh
$ bin/uwsgi parts/uwsgi/uwsgi.xml
-You can stop your `uWSGI`_ instance like this:
+You can stop your `uWSGI`_ server like this:
.. code-block:: sh
$ bin/uwsgi --stop var/instance/uwsgi.pid
+We recommend to run the server with an unprivileged user on Unix. If
+you wish to start `uWSGI`_ as *root*, you should either use ``sudo``
+or configure `uWSGI` to drop its privileges to a regular user after it
+started. In order to do so you can use the ``uid`` and ``gid`` options
+in the :term:`Buildout` part.
+
Installing and configuring Nginx
--------------------------------
-Unlike `uWSGI`_, we recommand to install `Nginx`_ using your system
-package manager, and not use Buildout in order to do it.
+Unlike `uWSGI`_, we recommend to install `Nginx`_ using your system
+package manager, and not use :term:`Buildout` in order to do it.
You can configure `Nginx`_ in order to redirect requests to `uWSGI`_,
-using the default module ngx_http_uwsgi.
+using the default module ngx_http_uwsgi. No custom built of `Nginx`_
+is needed.
.. code-block:: nginx
:linenos:
Modified: silvadoccenter/trunk/source/wsgi.rst
==============================================================================
--- silvadoccenter/trunk/source/wsgi.rst (original)
+++ silvadoccenter/trunk/source/wsgi.rst Wed Sep 4 11:43:35 2013
@@ -2,9 +2,9 @@
===============================================================
Silva now support WSGI. You can use Apache's ``mod_wsgi`` to directly
-serve it, without having it running in a different daemon and
+serve it, without having it running in a different processus and
redirecting requests to it. This is the recommend way to use Silva for
-medium-sized installations.
+medium-sized installations or if your prefer Apache over Nginx.
.. contents::
@@ -69,9 +69,10 @@
user ``username`` and group ``username`` the process is going to
run. These user **must** be the same non-privileged user that you
used to install Silva. The option ``threads`` defines the number of
- threads to use in each process. **You must not** configure more than
- 7 threads in any case. Finally the option ``maximum-requests`` renew
- our WSGI process every 10000 requests.
+ threads to use in each process. It is not recommanded to configure
+ more than 15 threads in any case, or performances might be severely
+ degraded. Finally the option ``maximum-requests`` renew our WSGI
+ process every 10000 requests.
- Line 7, defines the rewrite rule to trigger Zope VirtualHostMonster,
so that Zope generates URLs without the identifier ``mysite`` in