Uh Oh! It appears you're not connected to the internet!
Sorry! We currently have more users than we can cope with. You can either wait until a space becomes available or come back later. We will be upgrading our servers to cope with this soon!
You got the boot! Click to connect back up...
Please contact an administrator, You are not authorised to login via this IP address
Already have an account?
Click here to login
Don't have an account?
Click here to sign up
Go check your email!
Oops! We don't know your email address, We can't send you a new password! Contact an Admin
Set Profile Picture
Select An Image
Confirm End Of Friendship
Chat To Us
Prefer to chat anonymously?
Read all about it, See what the good people at Project Peach have to say
How do we monitor the resources consumed?
WebApp Performance Monitoring - Live
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.
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?
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...
Doing it differently since 2012. We're simply 10 years ahead. Our software is designed, coded, maintained, supported & hosted in the United Kingdom.