>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #238799. --> Reported by: [meitar](https://www.drupal.org/user/265715) >>> <p>I'm a new Drupal developer and am going through the docs to get my head around the project. I'm finding some places where I think I can add a lot of value by cleaning up bits of the documentation. Most notably, on the recent (and helpful!) "Best Practices" section regarding configuration Apache and PHP, which currently seems to simply have a copy-and-paste from a <code>httpd.conf</code> file, I suggest changing the content of the page to incorporate the following version:</p> <p>#### STARTING TO CLEAN UP #####<br> #### todo: mysql tuning section ####<br> #### markup layout and use &gt; &lt;</p> <p>These are some simple guidlines for setting up Drupal on a classic Linux-Apache-MySQL-PHP (LAMP) stack that provides a fair amount of security for the rest of your system.</p> <h2>PHP Configuration</h2> <p>To start, some common PHP configuration options can be optimized. On some systems, these settings may already be set, but it never hurts to add them yourself just in case.</p> <p>PHP settings can be controlled in a number of ways. If you have access to the <code>php.ini</code> configuration file (usually found at <code>/etc/php.ini</code>), you can simply edit this file to cause system-wide changes. If you'd prefer to make these changes just for your Drupal installation, however, the best place to do so is in your Drupal installation's <code>settings.php</code> file.</p> <ol> <li>First, increase PHP's memory limit to avoid getting out-of-memory errors when you begin to add a few modules. These errors may look something like this:<br> <blockquote><strong>Fatal error</strong>: Allowed memory size of 8388608 bytes exhausted (tried to allocate 30720 bytes) in <strong>/path/to/drupal/modules/system/system.module on line <strong>1022</strong></strong></blockquote> <p>. </p><ul> <li>In your <code>php.ini</code> file, include a line that reads: <code>memory_limit = 16M</code>. <strong>Or&hellip;</strong></li> <li>&hellip;in your <code>settings.php</code> file, include a line that reads:<br> <div class="codeblock"> <pre><span style="color: #000000"><span style="color: #0000BB">&lt;?php<br>&nbsp;ini_set</span><span style="color: #007700">(</span><span style="color: #DD0000">'memory_limit'</span><span style="color: #007700">, </span><span style="color: #DD0000">'16M'</span><span style="color: #007700">);<br></span><span style="color: #0000BB">?&gt;</span></span></pre></div> </li> </ul> </li> </ol> <h2>Apache Virtual Host Configuration</h2> <p>If you have access to your system's Apache configuration files (typically <code>/etc/httpd/httpd.conf</code> or <code>/etc/apache2/httpd.conf</code>), you can also make some simple changes to simplify Drupal's multisite configuration for subdomains.</p> <pre>ServerName example.com<br><br># Including a wildcard ServerAlias will direct all traffic to your end<br># users site and simplifies using Drupal's multisite configuration for<br># subdomains.<br><br>ServerAlias *.example.com<br><br># This path will vary depending on your system. If you are using debian<br># make sure you drop the default images alias. Leaving it can be very<br># annoying to users on shared servers.<br><br>DocumentRoot /var/www/example.com/public_html<br><br># Place the log where your end users can see them, and make sure they<br># are at the least readable to an end user.<br>#<br># Performance option:<br># You can move the Apache logs to another partition or drive to<br># get some small increases in disk i/o on heavily loaded servers.<br># You can symlink the log files to /var/www/example.com/logs/<br># to keep the persistent user interface, however it doesn't work in<br># chroot environments.<br><br>ErrorLog /srv/www/example.com/logs/error.log<br>CustomLog /srv/www/example.com/logs/access.log combined<br><br># Allow end users to manipulate their virtual hosts to their<br># hearts' content by enabling .htaccess files for them.<br><br>AllowOverride All<br><br># Since mod_php doesn't like you to respect su_exec, and safe_mode is just<br># too paranoid to be usable, restrict php to the proper vhost but to a level<br># above the DocumentRoot so users have some private file space for<br># .htpasswd, Drupal files, backups, etc.<br><br>php_admin_value open_basedir /var/www/example.com<br><br># Move PHP's temporary files into the open_basedir restricted space.<br><br>php_admin_value upload_tmp_dir /var/www/example.com/tmp<br><br># session.save path isn't really necessary for drupal since it<br># stores sessions in the database, but for general php enabled<br>#vhosts it keeps session data tied to each vhost.<br>php_admin_value session.save_path /var/www/example.com/tmp</pre><h2>MySQL Performance Optimization</h2> <p>Tweaking the configurations for your MySQL database server can give you a boost in performance. The MySQL configuration file is typically <code>/etc/my.cnf</code>.</p> <pre># big ol mysql.querycache(128M) (be aware of your systems memory limitations)<br>query_cache_size = 134217728<br><br># boost mysql max connections (min = (20*number of drupal sites))<br>set-variable=max_connections=512<br><br>eacclerator</pre>