Posted: 2013-12-06 01:38:18
How to make your WAMP run lightning fast again.
These steps to speed up your Apache, PHP, and MySQL web-server platform on Windows will work for any WAMP, including WAMP Server and XAMPP. But some of the directory and file paths used here are specific to WampDeveloper Pro (just substitute in the paths of your environment).
Edit the Windows Hosts file and remove the localhost to IPv6 loopback (::1) resolve/mapping.
Edit file –
Comment out the line by adding a ‘#’ in front:
# ::1 localhost
If “localhost” gets resolved to IP address “::1″, the request (when not able to find an IPv6 listening socket) will get routed back to IP address 127.0.0.1 (via timeout, fall-back, or some other mechanism), causing unnecessary delays for connections (e.g., typically anywhere from 1 second to 30 seconds).
Make sure that “localhost” is correctly mapped to the IPv4 loopback address “127.0.0.1” (…that this line is not commented out):
* The Windows Hosts file is usually set read-only, and requires Administrative permissions to edit. Some applications (SpyBot, ZoneAlarm, etc) can maintain an edit lock on this file, and Microsoft Defender (or Security Essentials) sometimes detects changes to this file that it thinks are malicious, and changes this file back to its original state. See how to unlock the Windows Hosts file.
Either unbind IPv6 from your network adapter (NIC card), or completely disable IPv6 on your system.
Problems with Windows and IPv6 have been known to add an additional half a second on the initial load-time of each request.
* Since IPv6 can be important to Windows, if this change does not resolve any issues (i.e., does not help to speed up WAMP), you should undo it.
Some Firewall and Anti-Virus software are known to significantly slow down Apache and MySQL, such as McAfee, Bit Defender, Avast, Norton, NOD32, Zone Alarm.
Try disabling those applications to see if it makes a difference (including the native Windows Firewall, Windows Defender, and Security Essentials).
If it does, open their settings, and add the httpd.exe and mysqld.exe paths to the list of excluded programs that should not be interfered with.
You might also want to exclude the PHP CLI and CGI binaries, and PHP’s DLL files…
* You’ll need to do this for each version of Apache and MySQL that you use.
Then exclude all the write-to paths (database files, log files, temp files, etc) used by Apache, MySQL, PHP, and any other tools and applications (including PHP scripts and frameworks such as CodeIgnitor)…
Exclude the MySQL Database directory from any checks.
Exclude WAMP’s Logs directory from any checks.
Exclude WAMP’s Temporary directory from any checks.
Change Windows Power Plan (also called Power Options, in Control Panel) from the default of “Balanced” (or “Power Saver”) to “High Performance”. “Balanced” restricts CPU Scaling. This can increase performance 50%.
Reset Winsock and TCP/IP back to their original state. Then reboot.
netsh winsock reset netsh int ip reset C:\resetlog.txt
* Run from an admin level command-line; right-click cmd.exe, select ‘Run as admin’.
Other software can attach filters to Winsock, and change the TCP/IP parameters, which causes Apache to stop responding to requests (with the problem manifesting as a slow page load, half page load, etc).
Make sure your system is not using old, invalid, non-working, and slow DNS Servers.
Wireless LAN adapter Wireless Network Connection: DHCP Server . . . . . . . . . . . : 192.168.1.1 DNS Servers . . . . . . . . . . . : 188.8.131.52 184.108.40.206 220.127.116.11
The above should list the DNS Servers assigned to you by your ISP (via DHCP), or display a list of public DNS Servers that are set via your Router or OS settings.
Flush Windows DNS Cache:
Slow response times for Chrome, Firefox, and IE can be indicative of –
A. Bad Proxy settings that are timing out:
Bypass proxy server for local addresses by creating Exceptions for your domain-names, and IP address 127.0.0.1.
B. Different plugins, and also phishing and malware protection settings:
Check your Browser’s active plugins, try disabling them. Check protection settings, exclude your domain-names.
C. Stale cache results:
Clear your Browser’s Cache. Also run Windows Disk Cleanup.
Apache maintains website access and error logs that can grow in size very quickly. PHP also has similar logs (if enabled via configuration).
Once Apache log files grow in size to above several 100 MB, performance issues can arise.
Also the Temp folder holds lots of session and temporary data files that don’t get properly cleaned up, which causes it’s own issues.
You can clear out the Log and Temp files like this –
Make sure Apache and MySQL are not running.
Open the command-line (run: cmd.exe).
Delete all the websites log files –
del /S C:\WampDeveloper\Logs\*log.txt
Delete all the temporary files –
del /S C:\WampDeveloper\Temp\*
Since this is a pure wildcard file-name delete (*), it will ask you if you want to delete all the files each time it finds a new sub-directory… As it prompts you, press the ‘y’ or ‘Y’ key, then press the ‘Enter’ key; or add in the /Q switch (del /S /Q …) to tell it not to prompt you at all.
The above will delete all the log files and all the temp files, within all the sub-directories. Make sure you do this carefully (that you are using the right paths)!
If you do this manually, make sure to never delete the directories and sub-directories, just the files in them.
Turn log buffering On. This will cause Apache to buffer logs for multiple requests instead of writing them out individually to the log file – and improve disk I/O on a heavily accessed web server.
* This should only be performed on a server that is nearing it’s I/O disk resource limits, as it does not offer much of an improvement anywhere else, and can make real-time debugging difficult.
Set the maximum number of free memory that every Apache thread is allowed to hold without attempting to give it back to the OS. Setting this value to 2048 KB (2MB) might prevent the Apache process from growing too large, as this will typically restrict its process max size to threads * MaxMemFree.
Decrease the default amount of Apache Worker threads that the Apache process creates on start-up to handle concurrent requests. Each Worker thread takes up system resources. The default number of 64-150 Worker threads under most WAMPs is too high.
Make sure EnableMMAP and EnableSendfile are not turned Off (they are On by default) as they use the OS’s abilities to speed up file access and delivery.
Make sure Win32DisableAcceptEx is not present in the configuration as it disables a faster way of accepting network connections on Windows (instead of AcceptEx() it uses accept()).
Under Apache 2.4, directive
Win32DisableAcceptEx has been replaced with the following configuration using the AcceptFilter directive:
AcceptFilter http none
AcceptFilter https none
* A warning for when using WAMP Apache 2.4 and IE9+… For some reason IE9+ requests (IE9 was the lowest version tested, it could also be an issue with IE8) will break under Apache 2.4 (but not under Apache 2.2). In my case, the first request from IE will usually not start nor complete, though subsequent requests will (but only when performed within a 3 second window after the first request). The only solution to this is to use the above ‘AcceptFilter … none’ configuration. Setting ‘KeepAlive On/Off’ makes no difference. The Apache error log shows this line: (OS 64)The specified network name is no longer available. : AH00341: winnt_accept: Asynchronous AcceptEx failed.
HostnameLookups should always be Off, as otherwise every request’s IP address will need to get resolved to a host or domain-name.
Always use IP address ‘127.0.0.1’ instead of ‘localhost’, host-name, or a domain-name to make a connection to MySQL. Not doing so can cause delay issues due to Host file problems, improper DNS, routing between IPv4 and IPv6, domain resolves, and time-outs.
In 99.9% of all set ups, MySQL runs on the same system the PHP scripts are connecting from, and is bound to (listening-on) 127.0.0.1… All PHP scripts should be making the connection to MySQL directly via IP 127.0.0.1.
Make sure your scripts’ (and webapps’) configuration files do so, and that the MySQL account they use has its Host: field set to 127.0.0.1 so that connection is allowed.
Example Wordpess configuration –
/** MySQL hostname */ define('DB_HOST', '127.0.0.1');
Example phpMyAdmin configuration –
/* Server parameters */ $cfg['Servers'][$i]['host'] = '127.0.0.1';
If a PHP script attempted to connect to MySQL via a host-name or a domain-name, that request would need to get resolved via DNS to an IP address, and that IP address would need to get routed back to a listening socket on the local system.
Also, if MySQL (and phpMyAdmin) will never be accessed from outside, you can disable MySQL’s DNS resolves and Host cache…
Edit my.ini, section [mysqld]:
*With this change, you’ll need to make sure all MySQL accounts are set to Host: 127.0.0.1
If your database access pattern is mostly read-only (less than 15% writes – typical for most webapps like WordPress), try using MyISAM tables. But if it’s write heavy, consider
using InnoDB tables.
Try updating the buffer sizes to 1/4 or 1/2 of your RAM –
For MyISAM tables (caches indexes only, not the data)
key_buffer_size = 256M
For InnoDB tables (caches both indexes and data)
innodb_buffer_pool_size = 512M innodb_log_file_size = 128M
innodb_log_file_size should be 1/4 of the innodb_buffer_pool_size value.
Changing the value of innodb_log_file_size will either cause MySQL to fail to start, or for the InnoDB Engine to not load. You’ll need to delete (or move out just in case) file(s) C:\WampDeveloper\Database\ib_logfile0 and ib_logfile1 (if it exists). This is a bit unclean, but if everything was flushed and shut down properly, should not be problematic.
The other settings I would not mess with. They hardly ever give anything more than marginal returns, or none at all.
Even the above mentioned settings will have diminishing results with increased values on the average system.
You’re mostly looking to update the existing settings (and not introduce new ones) to set the buffer-sizes of InnoDB and MyISAM to hold all indexes and data in memory as a percentage of your available RAM, and the log sizes as a percentage of the buffer sizes, and leaving everything else alone. As other settings are marginal, introduce complexity, are way too specific (and override good default and autos), or are just not good for the health of the Database.
The only other MySQL setting that can produce good performance gains – changes the way the above buffer is written out to the above log file, and how the whole thing is flushed to disk.
innodb_flush_log_at_trx_commit = 2
The default value of 1 is required for full ACID compliance. With this value, the log buffer is written out to the log file at each transaction commit and the flush to disk operation is performed on the log file. With a value of 0, any mysqld process crash can erase the last second of transactions. The log buffer is written out to the log file once per second and the flush to disk operation is performed on the log file, but nothing is done at a transaction commit. With a value of 2, only an operating system crash or a power outage can erase the last second of transactions. The log buffer is written out to the file at each commit, but the flush to disk operation is not performed on it. However, the flushing on the log file takes place once per second also when the value is 2. Note that the once-per-second flushing is not 100% guaranteed to happen every second, due to process scheduling issues.
Make sure php.ini has date.timezone set to a value. Otherwise PHP will attempt to figure out which data-time zone to use on every call to a date related function.
Surprisingly, an unset
date.timezone value has drastic performance implications.
Update php.ini’s realpath_cache_size to a much larger value from the default 16K.
realpath_cache_size = 1M
For this to work, open_basedir cannot be set, and safe_mode cannot be On. See – https://bugs.php.net/bug.php?id=52312
Updated the webapp’s MySQL user account (via /phpmyadmin) to change the “Host:” field from “localhost” to “127.0.0.1”.
Then update the webapp’s config file to reflect the change.
For example, edit Magento’s configuration file –
Update line –
Reset the internal rewrite-rules in
wp-options table by clearing the value via /phpmyadmin.
Refresh the entire WordPress database by Exporting it into an XML file via the Import/Export plugin. Then re-install WordPress (delete the WP database and access the WP website), and re-import the XML file via that same plugin.
Clear (truncate) the session table and watchdog table via /phpmyadmin.
Clear the Cache under: Drupal > Configuration > Development > Performance.
If your application utilizes memcached, and memcached is not installed, this can cause a very large delay in the loading of the first request due to the initial connection timeout.