Moving into CiviCRM v1.6

Last week was a pretty intense week for the team. The quest application process had the application deadline and as expected the load on the servers was really high for an extended period of time. As always we learnt quite a few lessons and a few things to do differently the next time around. Some of the lessons learnt include:

• Balance is not a very good load balancer. It croaked under heavy load and did not distribute the traffic evenly. An not aware of any other open source "web server balancing" solution. If someone knows other solutions, please let us know.
• Along with CPU, your network can/will be a bottleneck. In future, we'll serve all the "static" content (images, js, css) from a seperate web server and make sure we set a fairly nice expires header for maximum browser cache affect
• Splitting the drupal db and civicrm db was well worth it. The database servers were humming along quite nicely during the whole process. The maximum load on the servers was during the periodic mysqldump backup procedure
• Next time, we'll use the Zend Platform and hopefully get better profiling results of the code for the application flow.

So the project now moves onto the next phase, and we've rolled out the head version of CiviCRM onto the production boxes. We've made all our changes on trunk and it made sense to do so rather than a branch. Some noteworthy features that will be tested include batch update of contacts, acl permissioning and search views. We also implemented an xml exporter (i suspect we'll use some version of this in our generalized search engine implementation) and generated pdf copies of the application using a commercial license of PDFLib. Next week we start work on the mcconnell foundation project which is similar to the questbridge project. hopefully this will help us generalize the code and make it easier to deploy for other "application processing" systems. lobo