Updated Running a public or community server (markdown)

Running-a-public-or-community-server.md

@@ -2,7 +2,7 @@
 
 This document is about running Friendica servers for relatively large numbers of people, not about private servers for yourself and five to ten friends. If you are only setting up a server for yourself and your family or friends, you may find some interesting information in this how-to - but you can largely disregard warnings on issues like system overload. 
 
-_In essence, people running personal servers will understand Friendica better after reading this document - but it's only a must-read for those intending to set up much larger sites._
+_In essence, people running servers for up to ten (or so) users will understand Friendica better after reading this document - but it's only a must-read for those intending to set up much larger sites._
 
 That's because running a public or community Friendica server requires special consideration of every step. The effects of anything you decide are multiplied by the number of members you have - meaning that even minor issues for personal servers become big deals for public or community sites. 
 
@@ -644,13 +644,13 @@ There are a few options which do not yet have a section in the admin panel.  Unf
 
 Every time you see a spike in your RAM and CPU use, poller is running.  The really big spikes are when the poller is polling Facebook.
 
-If you followed the install instructions in install.txt, your cronjob will look like this:
+If you followed the install instructions in install.txt, your cronjob will look something like this:
 
 > */10 * * * *	cd /var/www/mywebsite; /usr/bin/php include/poller.php
 
 This makes poller.php run every ten minutes.  This is about right for a private site but a community server can only dream of polling so quickly.  Decreasing the regularity of your poller has obvious negative consequences - content that has to be polled (RSS feeds, Facebook, Email) arrives less often, but running it less often means you're not using all your RAM all the time.
 
-Exactly what number you should set this to varies by your users.  In my personal experience, you should initially set it up it to run ever 15 minutes initially.   By the time you have about 50 users, you should be polling around once every thirty minutes, and once an hour by the time you have a hundred users.
+Exactly what number you should set this to varies by your users.  You might initially set it up it to run ever 15 minutes initially.   By the time you have about 50 users, you should be polling around once every thirty minutes, and once an hour by the time you have a hundred users.
 
 To change the interval, simply change the value 10.  For example, to make the poller run every half hour:
 
@@ -660,25 +660,25 @@ or every hour:
 
 > */60 * * * *	cd /var/www/mywebsite; /usr/bin/php include/poller.php
 
-A feature related to this is the poller lockfile.  It used to be that poller could take half an hour or even more to run on a large public server.  This lead to the possibility that you could have two instances running at the same time...which made it take even longer, so a third started running, then a fourth, and you could quickly run out of RAM.   This has been mitigated very well recently, and doesn't happen like it used to, nevertheless, it's still a good idea to have a lockfile in place to stop multiple instances of poller running.
+A feature related to this is the poller lockfile.  It used to be that poller could take half an hour or even more to run on a large public server.  This led to the possibility that you could have two instances running at the same time... which made it take even longer, so a third started running, then a fourth, and you could quickly run out of RAM.   This has been mitigated very well recently, and doesn't happen the way it used to. Nevertheless, it's still a good idea to have a lockfile in place to stop multiple instances of poller running.
 
 To use a lockfile, add a line like this to your .htconfig.php file
 
 > $a->config['system']['lockpath'] = "/path/to/lockfile";
 
-This is a directory, not a file, and must be writeable by the webserver.  If you need a clearer example, I create a directory called "lockfile" in my Friendica root directory, and then use:
+This is a _directory, not a file_, and must be writeable by the webserver.  If you need a clearer example, the next line assumes the existence of a _directory_ called "lockfile" in the Friendica root directory:
 
 > $a->config['system']['lockpath'] = "/var/www/mydomain/lockfile";
 
 **Other .htconfig.php settings**
 
-Most of these settings are self-explanatory, and have equivalents in the admin panel.  It is very important that you don't change settings here _and_ in the admin panel, as this can have unpredictable results.  For each setting, use one or the other.
+Most of these settings in this section of .htconfig.php are self-explanatory, and have equivalents in the admin panel.  It is very important that you don't change settings here _and_ in the admin panel, as this can have unpredictable results.  For each setting, use one or the other.
 
-The only other important setting is for your maximum daily registrations.  You can add a line that looks like this to restrict the number of users who can join in one day:
+The only really important setting here is for your maximum daily registrations.  You can add a line that looks like this to restrict the number of users who can join in one day:
 
 > $a->config['system']['max_daily_registrations'] = 123;
 
-where 123 is the number of users you'll allow per day.  This probably doesn't matter for community servers, or servers that require approval, but it's essential for public servers.  I had one user sign up, and then invite twenty friends.  They all activated Facebook, and had over 500 friends each.  Result, crippled server for everyone else.  Had `max_daily_registrations` been set to 5 or 10, that would never have happened.  Use this setting or you _will_ be hit like this eventually.
+where 123 is the number of users you'll allow per day.  This probably doesn't matter for community servers, or servers that require approval, but it's essential for open public servers.  One admin once had one user sign up and then invite twenty friends.  They all activated Facebook, and had over 500 friends each.  Result: a crippled server for everyone else.  Had `max_daily_registrations` been set to 5 or 10, that would never have happened.  Use this setting or you _will_ be hit like this eventually.
 
 
 If you look through your .htconfig.php file, you'll find another example setting with empty fields:
@@ -686,7 +686,9 @@ If you look through your .htconfig.php file, you'll find another example setting
 >// If enabled, all items are cached in the given directory
 >$a->config['stem']['itemyscache'] = "";
 
-Do not be tempted to use this setting.  It does the job intended by the author, but is still relatively untested by public servers, as yet, largely untested by public servers.
+Do not be tempted to use this setting.  It does the job intended by the author, but is still relatively untested by public servers.
+
+If you are running a public server listed on friendica. com, the following setting may be attractive.
 
 >$a->config['info'] = "foo";