We're always adding new features to our live webapps and the underlying live webapp framework. Our latest feature includes easier, centralised 'Application Performance Monitoring'. We already had this information available to individual webapps but we wanted a dashboard style viewpoint too. This new feature works in complete harmony with our existing alerts and mechanic messaging. It's a feature of our cloud AIM (Application Instance Management) and propagates throught to our own Project Peach webapp as an instance management overview.
In order to control our cloud hosted, native code webapps we built an AIM (Application Instance Manager) which is responsible for lots of cool stuff. It helps us with everything from software updates and rollback, creating new instances of webapps in a click, managing backups and a host of other useful stuff like starting/restarting/stopping webapps. Before we started this particular feature our webapp instance data was somewhat scattered across the individual webapps, you had to visit each to get a birds eye veiwpoint of the whole system. Our alerts helped but sometimes it's nice to just sit back and watch a while from a higher plain. So that's the background to the feature.
We've revamped our AIM Instance page to form a running performance application dashboard. Each running webapp defined in our design time AIM structure is show along with details of the running process. Each metric gives us some indication regarding performance and load balance of ALL webapps running in our cloud. We monitor the webapp memory consumption, the webapp CPU, the number of live connections to the webapp (realtime users/browsers) and the application messaging load. Each of these values represents how well the webapp is coping under the current load. We've watermarks, alerts and error messaging if any of these values exceeds our preset expectations which trigger warnings and/or errors in our dashboard. So our bird's eye view is built into our AIM, however we don't spend all day here we're generally found over at Project Peach webapp. So what can we do?
We've a centralised alarm and error report dashboard in Project Peach. If one of our live webapps starts to go south we know about it instantly. We get what we call mechanic messages for all types of alarms and software coding errors. They give us a sort of early warning system regarding software defects. It's pretty comprehensive. From exceptions to SQL syntax errors pretty much all down to the line of offending code. We wanted to filter down our AIM improvements to our PP dashboard. The birds eye instance viewpoint giving us performance related information in realtime. Just another weapon in our arsenal for creating the ultimate, forever improving, software for our clients.
We've another story on our agile backlog. Balancing the power. Sharing the resources equally or/and increasing the resources to a specific webapp. We're a small amount of the way there already. We can currently limit the live connections to a webapp after which they form an orderly queue for connection. We could throttle the response to messages dynamically by restricting threads in our thread pool. We can do this already. However wouldn't it be great to offer a process priority? We've a way to go with this feature but watch this space...