Pixelpost
Authentic Photoblog Flavour
Benchmarking The New Config June 18, 2009
Posted by jaywilliamsThanks to a comment on the previous post, I decided to run a simple benchmark test on the new file based config vs a MySQLi database based config. The benchmark consisted of two tests for each config type, first a read test, which would read all 37 configuration options into an array, 10,000 times. The second test, a write test, would save an option 10,000 times. All tests were run on my Quad-Core Mac Pro via PHP CLI, so server load wasn’t an issue.
The results weren’t too surprising, the file based config was able to load 10,000 times in just 2.0413 seconds, that’s fast! The database version took 10.6869 seconds. And as you’d expect, the write benchmarks were the opposite. The database version wrote the new option 10,000 times in only 1.7795 seconds, where as the file based method took 4.3609 seconds. Why is that? It’s simple, a database can update a single row very efficiently, where as the file based config has to rewrite the entire file each time you change an option.
Another thing I noticed while testing, the file based config used substantially less CPU than the database version, but the file version required substantially more disk activity.
In summery, I think a file based config makes more sense, as load speed is more important for a web application like a photoblog. That being said, any information that will change on a regular basis, such post information, comments, and stats would be much better served by a database.
If you’d like to see the rough, but simple benchmark source code, check this out: http://pastie.textmate.org/516039
As always, if you have any questions or suggestions, be sure to leave a comment!
You can follow any responses to this entry through the RSS 2.0 feed. Trackback from your own site.
6 Responses to “Benchmarking The New Config”
-
Jaroslav June 18, 2009 @ 6:52 am
I would like to suggest little improvement to the test case
Basically what concerns me most is the implementation of function Test2_1(). Why did you create new database connection (heaviest part) in every iteration of the loop?I believe that every webapp should use database connection pooling – http://en.wikipedia.org/wiki/Connection_pool – or at least reuse one connection per session.
I am not sure if it is possible to implement connection pooling in PHP but I believe that one reusable connection should also do the job.
-
jaywilliams June 18, 2009 @ 9:58 am
@Jaroslav
With tests Test1_1() and Test2_1(), I was trying to simulate the initial visit to the website, so on each iteration, it was simply discarding all of the previous information, and starting from scratch.
A persistent connection pool might be an idea, but again, I’m not sure how feasible this would be with PHP as shared hosting setups are generally not very user-configurable, and vary greatly from server to server. If setup incorrectly, it could easily reach the mySQL connection limit.
-
Jaroslav June 18, 2009 @ 1:42 pm
Could you please please please perform the test with modified Test2_1() so it would use just one initial connect? I am just curious about the results
I may be wrong but I think that connection to database will be opened on almost every page generation either way because info about uploaded photos will be stored in database right?
-
jaywilliams June 18, 2009 @ 3:41 pm
I’ve run the test again, using a modified Test2_1(), which uses a single connection and only queries the options 10,000 times. The result: 6.3626 seconds. That’s 4 seconds faster, but still not as fast as the file based method.
As you assumed, each page will need a database connection to load the photo details and comments, I’m just trying to find ways to lower the database usage, and speed up the overall site.
-
Jerry C. January 19, 2010 @ 12:11 pm
I glad reading your blog post. Thank for share good information.
-
Casey Grosman January 25, 2010 @ 2:23 pm
Out grown your own shared hosting plan? Upgrade to a http://www.wiredtree.com/243-0-3-28.html fully managed VPS.