> That's far from reality for us and > very likely > others as well. So we try to add the usage factor in the mix > to be fair to > everyone. Current thinking is that we could establish some > base rate or > 'entry fee' to cover some amount of fixed costs regardless of > the number of > apps and then present a periodic maintenance/usage fee based on cpu > utilization or hits, etc..
That's going to be very difficult to accomplish. Linux process accounting isn't nearly as detailed as most host accounting facilities, and if you use the multiple application servers per instance model, process accounting isn't going to tell you much about application thread utilization within a process, which is how this stuff is going to get done. One customer of ours does it this way: Establish a small number of shared WAS servers and create a set of tiered service levels (low, medium, high), with appropriate relative SHARE values and CPU caps. Within the tiers, use the shared application server model and divide the usage figures by the number of applications and adjust for cost, which would give the users their fixed usage costs, but also allow you to balance the costs for each service level (and you can point them at each other for making performance yucky -- or so we can dream...8-)). If the users are unhappy sharing, then they can "upgrade" to a higher performance tier at appropriate cost uptick. If they want dedicated resources, then you can charge appropriately. You can review the charges periodically (half-yearly is good) and adjust accordingly. With this model, you can use the VM accounting stream to gather the data, and split it up after the fact -- you know what internal users are part of the service level group -- and not have to go after the sub-process accounting stuff.
