We have a lot of tests. Everytime there is a problem on pubget.com, we try to turn this into a test. This has added up over the last 3 years to 2 hours of functional and unit tests (we have others but not for the pubget.com build process).
Recently we lost one of our testing servers due hardware failure. This in itself was not problem as all the tests and database configuration is easily reproduced. However, waiting 2 hours between starting a test and checking if it worked was too long to wait.
We also noticed the server was not taxed at all. The CPU was not busy, HDD hardly getting much use and the memory was plentiful. The problem was just everying was single threaded and not using the 4 cores available.
As a result, we looked into a multi process solution to this. Thanks to the good work at http://ruby-toolbox.com/, we started with
Parallel Tests and found it 100% compatible with our fork of CruiseControl.rb.
We had to manually create the pubget_test1, pubget_test2, etc databases because our rails user does not have database create permissions but the rest of the instructions in their README worked perfectly.
If you want to save time in your tests and have more than one core or processor - I would encourage parallel testing. The next step is probably multi-box testing but this was such an easy win to double performance it was irresistible to include when we rebuilt the server.
* We also now have a hot spare for the build server thanks to unison for making a hot spare very easy to maintain.
Subscribe to:
Post Comments (Atom)
0 comments:
Post a Comment