Very slow loading on localhost (via. Uniform Server) I've setup Drupal to run successfully on a Uniform Server installation on my local machine, but it's really slow.  It's taking over 30 seconds to enable/disable modules, and around 3-10 seconds on most other pages.  This is becoming time prohibitive.

Things I've observed/tested:


PhpMyAdmin (running under the same server stack) doesn't seem to take any unnecessary time to load with any operations.
As per this guide, disabling my firewall (while LAN/WAN disabled) has no effect.
Modifying php.ini and my windows hosts file (also by that guide) have no effect.
Firefox settings seem to have no effect (including the one mentioned in that guide).


My next move is simply to try a different server stack, but I'm wonder if I have to.  Advice?
Well, for when I did run Windows last time with a webserver on it, I used Xampp, and it wasn't too slow out of the box. I found I still had to change portions of my.cnf to get it to run at a decent pace.

Several installs and jumps between Linux and Windows has made me realise that most of the Windows stacks I've come across have a lot to be desired performance wise and fiddling with my.cnf yields the best improvement.

Currently I use a 9 year old pc for most dev work, running Ubuntu server. It was painfully slow, but setting up MySQL caching to be a bit more reasonable and installing APC now has it running much, much faster than my quad core (with Xampp, admittedly no apc) at a mere 3 years of age. (The server only has 768mb of RAM).

My suggestion is to dive into my.cnf, though back it up first because if you get it set up wrong it may run much slower.

Alternatively get yourself set up with an Ubuntu server, made my life much easier (Though be prepared to lose several hours, maybe more if you are adverse to using a terminal) The Ubuntu Server guide walks you through pretty much everything you will need to do though.

As a disclaimer I have never used Uniform.

Edit from here on:

Relevant settings I use for my.cnf are:

[myslqd]
key_buffer              = 16M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
# I keep this low to limit max memory usage, with 2 or less people we don't get near this
max_connections         = 50
# table_cache is quite large compared to default because of the massive amount of tables 
# Drupal uses.
table_cache             = 512
# Increased for those large queries, though keep an eye on these queries exceeding this
# value on your production server/hosting.
query_cache_limit       = 3M
# Greatly increased due to the large numbers of queries Drupal does.
query_cache_size        = 32M
# Total size of InnoDB's buffer, larger is better, I keep it larger than the DB of the
# of the site I am currently working on.
innodb_buffer_pool_size = 128M
# This stops InnoDB flushing its log at every transaction, instead flushiong it once 
# per second. Can be detrimental to the last 1 or 2 seconds of data in case of a crash.
# Imo provides the largest boost on desktops due to their usually limited I/O capacity.
innodb_flush_log_at_trx_commit = 2


I no longer use myisam tables so I haven't played with myisam specific settings in there.

Overall the biggest bottleneck is hard drive access time so I keep as much in memory as possible, my dev server (Which is that ancient desktop box) has PATA drives so even writing to its miserable 8MB cache is slow. If your computer is low on I/O you need more caching, APC also makes a big difference in these cases.

Just keep in mind that you should compare the production environment settings to your dev ones to make sure that you stay within the production environment capabilities, though even on shared hosting with dismal caching and no APC, the presence of RAID usually makes up for it (Granted though that the host we use currently is the fastest one we have used, and some shared hosts are going to be slow no matter what you do.).

Also look at http://www.mysqlperformanceblog.com/ but also maybe avoid it because that is more geared towards dedicated database servers with obese amounts of RAM.