Project Peach
WebApp Performance Monitoring - Live
##STATICWHYTEXT##
WebApp Performance Monitoring - Live
08/06/2017
We Continually Add New Features...
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.
Our AIM
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.
Application Instance Monitoring
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?
Project Peach Dashboard
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.
Application Messaging Load, Huh?
Back down to earth lets add a little clarity on application messaging. So we get CPU, memory and connections but what about application messaging load? Let's step back. Our native code, industrial strength, c++ webapps run in the cloud. They are powerful beasts written in a fast, compiled language that drive the countries banking and military systems. We can crunch data like lightning. BUT, we didn't want a client installation. So we run our UX (User eXperience) in a modern browser with our own HTML5/CSS3/JavaScript UI components. In order to talk to our cloud hosted webapps we created a message based communication system. The glue between the client and the server is a message in either direction. The client wants you to do this task OR The server says another user added content to the page you're currently looking at and here it is and so on. It's not a million miles away from the cooperative multitasking message based Microsoft Windows approach but these system messages pass across the Internet instead of between components on your local machine. So we have IN messages and OUT messages. An IN may generate one or more OUTs. Some system event might generate multiple OUTs. Importantly here, remember that OUTs are PUSH messages coming from the cloud to the client browser via our amazing smart connections. These IN and OUT message counts give us an indication of the level of current load too. You may have noticed that there's quite a few zeros in our 3 second app message snapshots. Remember one of the great advantages to our framework is "If nothing is happening then we simply wait...", contrast this to AJAX polling to mimic live. We are truly live, greener, eco with blistering performance through reduced load. Have a read up on our eco credentials in our blogs.
Balancing the Power
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...
##BLOGWRITTENBY##
John Ince
Comments