[Pkg-owncloud-commits] [owncloud-doc] 23/36: add caching tip, than vs. then vs. that

[David Prévot]

This is an automated email from the git hooks/post-receive script.

taffit pushed a commit to branch master
in repository owncloud-doc.

commit d9d8d1ae5f4ae58db6560a34b2e0a6d5dc27a590
Author: Jörn Friedrich Dreyer <jfd at butonic.de>
Date:   Fri Aug 15 11:00:40 2014 +0200

    add caching tip, than vs. then vs. that
---
 developer_manual/general/performance.rst | 15 ++++++++-------
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/developer_manual/general/performance.rst b/developer_manual/general/performance.rst
index 971117a..ec7e9fa 100644
--- a/developer_manual/general/performance.rst
+++ b/developer_manual/general/performance.rst
@@ -11,14 +11,15 @@ Database performance
 --------------------
 The database plays an important role in ownCloud performance. The general rule is: database queries are very bad and should be avoided if possible. The reasons for that are:
 
-* Roundtrips: Bigger ownCloud installations have the database not installed on the application server but on a remote dedicated database server. The problem is that database queries than go over the network. This roundtrips can add up significantly if you have a lot of queries. 
+* Roundtrips: Bigger ownCloud installations have the database not installed on the application server but on a remote dedicated database server. The problem is that database queries then go over the network. These roundtrips can add up significantly if you have a lot of queries. 
 * Speed. A lot of people think that databases are fast. This is not always true if you compare it with handing data internally in PHP or in the filesystem or even use key/value based storages. So every developer should always double check if the database is really the best place for the data.
-* Scalability. If you have a big ownCloud cluster setup than you usually have several ownCloud/webservers in parallel and a central database and a central storage. This mean that everything that happens on the ownCloud/PHP side can parallelize and can be scaled. Stuff that is happening in the database and in the storage is critical because it only exists once and can't be scaled so easily.
+* Scalability. If you have a big ownCloud cluster setup you usually have several ownCloud/webservers in parallel and a central database and a central storage. This means that everything that happens on the ownCloud/PHP side can parallelize and can be scaled. Stuff that is happening in the database and in the storage is critical because it only exists once and can't be scaled so easily.
 
 We can reduce the load on the database by:
 
-1. Making sure that always an index is used.
+1. Making sure that every query uses an index.
 2. Reducing the overall numbers of queries.
+3. If you are familiar with cache invalidation you can try caching query results in PHP.
 
 There a several ways to monitor which queries are actually executed on the database.
 
@@ -26,13 +27,13 @@ With MySQL is is very easy with just a bit of configuration:
 
 1. Slow query log.
 
-If you put this into your my.cnf file than every query that takes longer than one second is logged to a logfile::
+If you put this into your my.cnf file, every query that takes longer than one second is logged to a logfile::
 
   log_slow_queries = 1 
   log_slow_queries = /var/log/mysql/mysql-slow.log 
   long_query_time=1 
 
-If a query takes over one second than we have a serious problem of course. You can watch it with `tail -f /var/log/mysql/mysql-slow.log` while using ownCloud.
+If a query takes more than a second we have a serious problem of course. You can watch it with `tail -f /var/log/mysql/mysql-slow.log` while using ownCloud.
 
 2. log all queries.
 
@@ -44,7 +45,7 @@ If you reduce the long_query_time to zero than every statement is logged. This i
 
 3. log queries without an index.
 
-If you increase the long_query_time to 100 and add log-queries-not-using-indexes than all the queries that are not using an index are logged. Every query should always use an index. So ideally there should be no output::
+If you increase the long_query_time to 100 and add log-queries-not-using-indexes, all the queries that are not using an index are logged. Every query should always use an index. So ideally there should be no output::
 
   log-queries-not-using-indexes
   log_slow_queries = 1
@@ -54,7 +55,7 @@ If you increase the long_query_time to 100 and add log-queries-not-using-indexes
 Measuring performance
 ~~~~~~~~~~~~~~~~~~~~~
 
-If you do bigger changes in the architecture or the the database structure you should always double check the positive or negative performance impact. There are a `few nice small scripts <https://github.com/owncloud/administration/tree/master/performance-tests>`_ than can be used for this.
+If you do bigger changes in the architecture or the database structure you should always double check the positive or negative performance impact. There are a `few nice small scripts <https://github.com/owncloud/administration/tree/master/performance-tests>`_ that can be used for this.
 
 The recommendation is to automatically do 10000 PROPFINDs or file uploads, measure the time and compare the time before and after the change.
 

-- 
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-owncloud/owncloud-doc.git