Part of the due diligence when offering a service such as a Subversion server involves capacity planning and performance tuning. Subversion doesn't tend to be particularly greedy in terms of server resources such as CPU cycles and memory, but any service can benefit from optimizations, especially when usage of the service skyrockets[60]. In this section, we'll discuss some ways you can tweak your Subversion server configuration to offer even better performance and scalability.
Generally speaking, the most expensive part of a Subversion server's job is fetching data from the repository. Subversion 1.6 attempted to offset this cost by introducing some in-memory caching of certain classes of data read from the repository. But Subversion 1.7 takes this a step further, not only caching the results of some of the more costly operations, but also by providing in each of the available servers the means by which fine-tune the size and some behaviors of the cache.
For svnserve, you can specify the size
        of the cache using the --memory-cache-size
        (-M) command-line option.  You can also
        dictate whether svnserve should attempt to
        cache content fulltexts and deltas via the
        boolean --cache-fulltexts
        and --cache-txdeltas options,
        respectively.
$ svnserve -d -r /path/to/repositories \
           --memory-cache-size 1024 \
           --cache-txdeltas yes \
           --cache-fulltexts yes
…
$
        mod_dav_svn provides the same degree of
        cache configurability via httpd.conf
        directives.
        The SVNInMemoryCacheSize,
        SVNCacheFullTexts,
        and SVNCacheTextDeltas directives may be
        used at the server configuration level to control Subversion's
        data cache characteristics:
<IfModule dav_svn_module> # Enable a 1 Gb Subversion data cache for both fulltext and deltas. SVNInMemoryCacheSize 1048576 SVNCacheTextDeltas On SVNCacheFullTexts On </IfModule>
So what settings should you use?  Certainly you need to
        consider what resources are available on your server.  To get
        any benefit out of the cache at all, you'll probably want to
        let the cache be at least large enough to hold all the files
        which are most commonly accessed in your repository (for
        example, your project's trunk directory
        tree).
| ![[Tip]](images/tip.png)  | Tip | 
|---|---|
| Setting the memory cache size to  | 
| ![[Note]](images/note.png)  | Note | 
|---|---|
| Currently, only repositories which make use of the FSFS backend data store make use of this data caching functionality. | 
Compressing the data transmitted across the wire can
        greatly reduce the size of those network transmissions, but
        comes at the cost of server (and client) CPU cycles.
        Depending on your server's CPU capacity, the typical access
        patterns of the clients who use your servers, and the
        bandwidth of the networks between them, you might wish to fine
        tune just how hard your server will work to compress the data
        it sends across the wire.  To assist with this fine tuning
        process, Subversion 1.7 offers
        the --compression (-c)
        option to svnserve and
        the SVNCompressionLevel directive
        for mod_dav_svn.  Both accept a value which
        is an integer between 0 and 9 (inclusive), where 9 offers the
        best compression of wire data, and 0 disables compression
        altogether.
For example, on a local area network (LAN) with 1-Gigabit connections, it might not make sense to have the server compress its network transmissions (which also forces the clients to decompress them), as the network itself is so fast that users won't really benefit from the smaller overall network payload. On the other hand, servers which are accessed primarily by clients with low-bandwidth connections would be doing those clients a favor by minimizing the overall size of its network communications.
[60] In Subversion's case, the skyrocketing affect is, of course, due to its cool name. Well, that and its popularity, reliability, ease of use….