This week I purchased a OCZ Vertex 2 SSD drive for my laptop, a Lenovo ThinkPad T61p. After replacing the old HDD, I was greeted by the following error message, just after the BIOS screen:
ERROR
2100: HDD0 (Hard Disk Drive) initialization error (1)
That does not sound good. Anyway, I searched around and found one simple advice:
Don’t use the ThinkPad HDD cage and the corresponding anti-shock bumpers. The problem lies with the physical connection of the SSD. I inserted the SSD without the bumpers and the bracket and voilà : It worked flawlessly.
The SSD does not need shock-protection from the rubber bumpers, but in order to stabilise the drive I put some padding at the end of the SSD, so there is no stress on the connectors.
I was not pleased with the results of my database tweaks. So I looked further to improve the performance of this blog and stumbled upon XCache. Developed by the same people that created lighttpd, XCache is a PHP opcode cacher that greatly improves WordPress performance.
Using the same Java program I used in my previous tests, I queried the website 500 times and packed the data into a graph. This is what showed up:
Now that is what I am talking about! The query time is nearly three times as fast as before.
I am still looking into other cachers like Alternative PHP Cache (APC), but I like xcache so far.
Today I wondered how my newly purchased Virtual Server performs under load. I am currently using lighttpd as a webserver and MySQL as the database for WordPress. I already knew that MySQL features the Query Cache, which stores the result of issued queries in memory (Oracle’s equivalent of this would be the Result Cache in Oracle 11g). I wondered how much this feature could improve performance on a normal WordPress blog.
I quickly wrote a small Java program to query my website (source code available here: TestWebPerfo.java) and retrieve the performance metrics from the HTML source code. I then ran it 500 times to get my metrics without the Query Cache turned on. Average time for building the website: 0.115 seconds.
Read the rest of this entry
Having security in mind, I had some concerns granting all privileges to the WordPress MySQL user (see the instructions from WordPress):
GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername" [..]
After all, with these privileges the WordPress user would be able to access other databases on this server and do whatever he likes. WordPress has become very popular and is a known target for exploits and the like (as a quick search on milw0rm.com will confirm). I didn’t like that idea.
So here is what I did:
GRANT SELECT, INSERT, UPDATE, CREATE, DELETE ON wordpress.* TO 'wordpress' IDENTIFIED BY 'mypass';
This works fine so far and I don’t think my WordPress installation needs more privileges. Note that the ALTER and DROP statements are missing from my list, which could interfere with future updates. But we’ll see…
