Optimising Grandad
For some time now, I have been concerned at the slow loading of Head Rambles.
There have been complaints of timeouts and load times running into the minutes, and that is not good.
During the week, I decided to make a concerted effort to get to the bottom of the problem.
The problem has to lie in one (or more) of several areas –
- Plugins
- Embedded third party code
- The database
- Unwieldy theme coding
In order to be able to carry out tests without disrupting the site, I created a new site from scratch. I then imported the theme from the live site and tried to import the database. The latter was a rather tricky operation, and the tables were extremely large. The comments table alone ran to 10Mb, which must say something, though I’m not sure what? Also there are a lot of obscure characters in the database that parse correctly in the live site, but not the copy. That is something that has to be investigated.
The new site is at http://grandad.ie if anyone is interested.
I have started work on a new theme for it, which is trimmed down to the bare necessities. There is still some work to be done on it, so don’t complain about broken graphics just yet……
I have removed all embedded code and there are no plugins activated yet.
Both sites seem to be loading fairly quickly at the moment, which is annoying. Perhaps you can tell me differently?
And if anyone has any idea on those strange characters (“don’t” instead of “don’t” for example) I would be very grateful.
I’m assuming you imported the database via SQL instead of WordPress?
From the headrambles dashboard export your entries to a file.
Then setup grandad.ie from scratch again and import the entries you downloaded.
I tried that, Robert. There is a limit on an import file size of 5Mb and the exported file is 22.4Mb! Any workaround for that?
The last issue, the “don’t” instead of “don’t” issue, is a character set thing. UTF-8 allows characters to take up more than one byte (since there’s over 100000 different ones), whereas latin-1 assumes every letter is one byte. So if you display a UTF-8 string as if it were Latin-1, instead of seeing the single character you see each byte individually.
You have to make sure that you connect to MySQL using the same encoding both times, and that the database and tables all have the same character set. It’s possible that, if you’re using two different machines, that they use different character sets by default.
Hope that makes some sense 🙂
For the too-large file issue, can you upload a zipped version?
I assume you’ve checked that the character sets are set the same for the old and the new databases?
If your using a VPS, install PHPMyAdmin and you’ll be able to select the encoding via the drop down list.
Andrew: The first thing I thought of when I saw those characters was the encoding. Both however are set to UTF-8. This is what has me baffled!
As for the too large file – it won’t recognise a zipped file. It has to be XML. 🙁
Welcome Darragh! Both are on the same VPS and phpMyAdmin is installed. The coding, as I said is the same on both.
Update:
I tweaked the .htaccess file and managed to copy the contents across using the XML export/import. The problem persistes!!
Ah that explains why you’re not coming up in my reader!
Have you tried just calling a man who charges too much to do it for you?
I do that with everything.
Head Rambles being about the same age as my effort I would have to believe that your WP DB tables originally started out as Latin-1 like mine did. And when I had to rebuild JT I did some hunting around and found out that going into my MySQL DB tables and dumping them all using an UTF8 format wasn’t enough. I ended up having to manually convert each table to UTF8 as well which I actually accomplished on the old site before I cleaned things up and imported them over to the new site (and more cleaning before going live).
This is Alex King’s post where I got the instructions from (not only from the post itself but I had to read down the comments as well before I understoof what to do).
http://alexking.org/blog/2008/03/06/mysql-latin1-utf8-conversion
Not that you’ll want to start mucking around again but this can be done on a live site, you just have to take it down for a bit during the re-import when your done converting.
Of course if you’ve already done this…please disregard.