Testing an Alternate Field SQL Storage Module
After my post yesterday testing the field storage layer, a commentator pointed out an alternate SQL storage module that does not create a revision table for each field. Naturally, I had to try this out to see how what kind of performance was possible with this approach.
The average throughput numbers I observed using this module are shown in the table below.
|Default MySQL||2892 nodes / minute|
|Default PostgreSQL||2313 nodes / minute|
|Tuned MySQL||4730 nodes / minute|
|Tuned PostgreSQL||2464 nodes / minute|
The image below shows the results graphically for different environments I tested. The Y axis is throughput (node per minute) with the X axis specifying the CSV file (corresponding to a MLB year) being imported.
That’s a pretty big improvement over the numbers I got in my original test. We still are not approaching the 8000 nodes per minute that is possible with a tuned MySQL instance and MongoDB for field storage but at about 5000 nodes per minute, we are getting somewhat close. It does beg the question of whether the performance benefits of MongoDB for field storage are worth it when we can get somewhat close using this module and a site’s original database system?
I would be interested in suggestions for read benchmarks from the community for different field storage backends so I can attempt to gain more insight into this question for myself.
blog comments powered by Disqus