Unification
Your first reaction probably is “Am I at the right web site?” and the answer is yes this is a blog about advanced systems development. So why that title you ask yourself? My answer is this article is about unifying several important requirements regarding quality into a system that not only satisfy the Customer and Business but also the Information Technology groups such as Operations, Application Support and Development. This is the first article of a series that will focus on dimensions of quality that when incorporated into a system will have your customers calling your boss in praise, your system administrator can sleep at night and have your CIO complementing you on your work your boss and customers mentioned in a high level meeting. The dimension of quality discussed this article is about performance. It is usually thought about but may not have been given enough attention in design, only partially implemented and not tested completely. Performance - To me this means never saying you are sorry to your customer that it took over a second to logon or display data and make your CIO happy that IT does not need to keep buying new hardware. In MyUniPortal I did this by using multi-tier caching, and paying close attention to data types and size of data. This was easier to accomplish when using a Rich Internet Application so I could cache at that level and check to see if there was newer data at the middle tier cache. Checking the type of data and it’s structure was equally important thus using complex objects was to be avoided and arrays a must. Also, using tags that were small in number of characters helped for the SOAP messages. By doing that I was able to keep message sizes below 1500 bytes or one network packet. For performance verification I added timers to measure round trip times at the client or RIA, middle tier or servlet layer and at the Integration tier or Enterprise Java Bean layer. I later added a metric service for monitoring performance at each tier for each service. Not satisfied with just that I implemented logging such that if performance requirements were not met at each tier then the violation was logged so as to use for later analysis if the human monitor was not watching the metrics. So why all this effort? Being able to be proactive in isolating and correcting performance issues in production in minutes is critical before the service desk or system calls. If done correctly you may never have to purchase an expensive monitoring system that itself may use precious server resources. Also, if you have sub-millisecond response times then scalability is met within a multi-socket, multi-core single blade or server for most requirements and allow resources for hosting more applications through virtualization. As mentioned in a previous blog I was down to 6-7msec round trip times as measured at the client but by using more efficient protocols, updateing the jvm and a small upgrade of the CPU I am down to 4-5msec typically for requests and expect at the server itself around 1-2msec with perhaps to 100-200usec response times if the CPU is upgraded from a desktop grade CPU to a server grade extreme performance CPU.