We’ve started using the alpha version of AppLogic 2.0 for our Grid University training sessions so if you want to get a sneak peek of the upcomming system you can attend any of the twice weekly classes.

While on that note, in preparing for Tuesday’s GridU session I was working with one of our support engineers to balance the resources between the database and an array of web servers in the sample app so we could saturate the database’s write throughput. The new monitoring system in AppLogic 2.0 is tailor made for this. It let’s you create custom dashboards for each app by building graphs from any of hundreds of counters the system keeps on all appliances in your application. So once our app was up and running I set up a monitoring dashboard with database reads and writes on one graph, inbound and outbound traffic on another, free memory on a third, and finally cpu utilization for the database and all web servers in a fourth graph. Then we fired up the new traffic generator appliance he’d just built and started tuning our application.

Using the dashboard we could see at a glance that our first attempt at resource allocation wasn’t working. Our array of web servers was saturated but the database wasn’t even close to saturation. We added addtional resources to the front end, watched for a minute and then decided to add still more resources to the array. Success!

The total elapsed time to tune our application once it was up and running, including building the dashboard, was less than thirty minutes. I won’t even venture a guess how long this would have taken in the past.