docs: tweak formatting of the performance page - replace the odd numbered list with sections

docs/usage/performance.rst

@@ -4,43 +4,54 b''
 Optimizing Kallithea performance
 ================================
 
-When serving a large amount of big repositories, Kallithea can start
-performing slower than expected. Because of the demanding nature of handling large
-amounts of data from version control systems, here are some tips on how to get
-the best performance.
+When serving a large amount of big repositories, Kallithea can start performing
+slower than expected. Because of the demanding nature of handling large amounts
+of data from version control systems, here are some tips on how to get the best
+performance.
 
-Follow these few steps to improve performance of Kallithea system.
+
+Fast storage
+------------
 
-1.  Kallithea is often I/O bound, and hence a fast disk (SSD/SAN) is
-    usually more important than a fast CPU.
+Kallithea is often I/O bound, and hence a fast disk (SSD/SAN) and plenty of RAM
+is usually more important than a fast CPU.
 
-2. Increase cache
+
+Caching
+-------
 
-    Tweak beaker cache settings in the ini file. The actual effect of that
-    is questionable.
+Tweak beaker cache settings in the ini file. The actual effect of that is
+questionable.
 
-3. Switch from SQLite to PostgreSQL or MySQL
+
+Database
+--------
 
     SQLite is a good option when having a small load on the system. But due to
     locking issues with SQLite, it is not recommended to use it for larger
-    deployments. Switching to MySQL or PostgreSQL will result in an immediate
-    performance increase. A tool like SQLAlchemyGrate_ can be used for
-    migrating to another database platform.
+deployments.
+
+Switching to MySQL or PostgreSQL will result in an immediate performance
+increase. A tool like SQLAlchemyGrate_ can be used for migrating to another
+database platform.
+
 
-4. Scale Kallithea horizontally
+Horizontal scaling
+------------------
 
-    Scaling horizontally can give huge performance benefits when dealing with
-    large amounts of traffic (many users, CI servers, etc.). Kallithea can be
-    scaled horizontally on one (recommended) or multiple machines.
+Scaling horizontally means running several Kallithea instances and let them
+share the load. That can give huge performance benefits when dealing with large
+amounts of traffic (many users, CI servers, etc.). Kallithea can be scaled
+horizontally on one (recommended) or multiple machines.
 
     It is generally possible to run WSGI applications multithreaded, so that
-    several HTTP requests are served from the same Python process at once. That
-    can in principle give better utilization of internal caches and less
-    process overhead.
+several HTTP requests are served from the same Python process at once. That can
+in principle give better utilization of internal caches and less process
+overhead.
 
-    One danger of running multithreaded is that program execution becomes much
-    more complex; programs must be written to consider all combinations of
-    events and problems might depend on timing and be impossible to reproduce.
+One danger of running multithreaded is that program execution becomes much more
+complex; programs must be written to consider all combinations of events and
+problems might depend on timing and be impossible to reproduce.
 
     Kallithea can't promise to be thread-safe, just like the embedded Mercurial
     backend doesn't make any strong promises when used as Kallithea uses it.
@@ -65,7 +76,9 b' 4. Scale Kallithea horizontally'
       that will separate regular user traffic from automated processes like CI
       servers or build bots.
 
-5. Serve static files directly from the web server
+
+Serve static files directly from the web server
+-----------------------------------------------
 
 With the default ``static_files`` ini setting, the Kallithea WSGI application
 will take care of serving the static files found in ``kallithea/public`` from