245681 items (663 unread) in 24 feeds
CNN
(6 unread)
MSNBC
(16 unread)
PHP
(57 unread)
Deals
(573 unread)
Tech
(3 unread)
Web Development
(1 unread)
CNN Money
(6 unread)
Frugal Blogs
(1 unread)
A little while ago, I wrote an article discussing why interfaces rock and the way that interfaces work. However, a couple of comments made me realize that I didn’t discuss one of the key elements about interfaces: why you would use them.
One key rule about interfaces is that all methods must be defined as public. You cannot define protected or private methods, and you cannot define any members of any type. You may define constants, as these cannot be overridden by any class implementing the interface.
So why is an interface useful?
An interface is useful because it allows you to know what methods will be there. No matter what, when you get an object that implements a particular interface, it has to have implemented all the methods of that interface. What’s more, you also know that the interface is public, so each of those methods is public. Essentially, this means that an interface is for defining your public API.
Take the following example:
interface ActionI
{
public function initialize();
public function execute();
public function getResult();
public function setRequest();
}
Each and every one of those public methods will be available to every single object in our application. We know that any object implementing ActionI will have those methods defined, and they form the public API of our object. Regardless of what private or protected methods that we implement (the guts that make our object function properly), this is our public API.
An added benefit of doing this is that an interface definition allows you to document more effectively. Theoretically we can document just the four public API methods, and skip the protected or private methods (except for internal documentation), because anyone who is accessing our objects only needs to know about the four public ones. Only the developers who are modifying the internal workings of the objects care about the helper methods.
Interfaces make programming much easier, by allowing us to plan, and by giving us consistency in our public API, without requiring us to define much about the methods to do so.
It’s worth noting that this article contradicts something in my previous article, “Why Interfaces Rock”. That is that I defined a constructor method. When defining your public API, you do not want to define any methods that might be unnecessary in descendant objects. In practice, when you define your interface, make sure to only include the methods that will be necessary for all objects to implement; nothing more, nothing less.
Oct 6 update: Added logging of disk [d] and network [n] info.
Oct 4 update: added availability option. Now uses xentop internally.
Oct 2 update: added graphing to xenstat.pl. Now xenstat.pl detects Guest VM start/shutdown and resets itself. Number of vcpus also shown. Misc bug fixes.
You can download xenstat.pl here.
Syntax
perl xenstat.pl [$mode] [$intervalsecs=5] [$nsamples=0] [$urlToPostStats]
Quick Guide
perl xenstat.pl -- generate cpu stats every 5 secs perl xenstat.pl 10 -- generate cpu stats every 10 secs perl xenstat.pl 5 2 -- generate cpu stats every 5 secs, 2 samples perl xenstat.pl d 3 -- generate disk stats every 3 secs perl xenstat.pl n 3 -- generate network stats every 3 secs perl xenstat.pl a 5 -- generate cpu avail (e.g. cpu idle) stats every 5 secs perl xenstat.pl 3 1 [server] -- gather 3 secs cpu stats and send to URL perl xenstat.pl d 4 1 [server] -- gather 4 secs disk stats and send to URL perl xenstat.pl n 5 1 [server] -- gather 5 secs network stats and send to URL
Usage
To use run "perl xenstat.pl" in domain 0. The following output will be generated, with a new statistic generated every 5 seconds:
[root@server ~]# perl xenstat.pl
cpus=2
40_falcon 2.67% 2.51 cpu hrs in 1.96 days ( 2 vcpu, 2048 M)
52_python 0.24% 747.57 cpu secs in 1.79 days ( 2 vcpu, 1500 M)
54_garuda_0 0.44% 2252.32 cpu secs in 2.96 days ( 2 vcpu, 750 M)
Dom-0 2.24% 9.24 cpu hrs in 8.59 days ( 2 vcpu, 564 M)
40_falc 52_pyth 54_garu Dom-0 Idle
2009-10-02 19:31:20 0.1 0.1 82.5 17.3 0.0 *****
2009-10-02 19:31:25 0.1 0.1 64.0 9.3 26.5 ****
2009-10-02 19:31:30 0.1 0.0 50.0 49.9 0.0 *****
In the above output, the first few lines summarise the CPUs and running domains. Then we have the statistics generated every 5 seconds. At the end of each line is a simple graph. 5 stars means 90% or over CPU utilisation, 4 stars is 70% or over, etc.
You can also define the interval to poll (in seconds), and the number of samples just like vmstat:
[root@server ~]# perl xenstat.pl 3 2
cpus=2
40_falcon 2.67% 2.51 cpu hrs in 1.96 days ( 2 vcpu, 2048 M)
52_python 0.24% 748.07 cpu secs in 1.79 days ( 2 vcpu, 1500 M)
54_garuda_0 0.44% 2258.38 cpu secs in 2.96 days ( 2 vcpu, 750 M)
Dom-0 2.24% 9.24 cpu hrs in 8.59 days ( 2 vcpu, 564 M)
40_falc 52_pyth 54_garu Dom-0 Idle
2009-10-01 12:14:59 0.0 0.0 1.7 5.7 92.5
2009-10-01 12:15:02 0.0 0.0 0.3 10.4 89.3 *
[root@server ~]#
Logging Using REST web service
To log the CPU utilisation using the Perl script, I didn't want to install a database client in Dom-0. So I added another parameter, a URL to a web server to call with the CPU info as GET parameters. I assume wget is installed in your Dom-0.
[root@server ~]# perl xenstat.pl 10 1 [192.168.0.1] cpus=2 54_garuda_0 0.49% 165.81 cpu sec over 3.62 days (2 vcpu, 750 M) 59_gyrfalcon 0.62% 69.03 cpu sec over 0.80 days (2 vcpu, 2000 M) Dom-0 1.57% 2.15 cpu hrs over 3.62 days (2 vcpu, 564 M) --10:46:42-- [192.168.0.1] Connecting to 192.168.0.1:80... connected. HTTP request sent, awaiting response... 200 OK Length: 498 [text/html] Saving to: `STDOUT' 100%[============================================>] 498 --.-K/s in 0s 10:46:42 (67.8 MB/s) - `-' saved [498/498] 2009-09-29 10:46:42 0.1 2.1 2.2 95.6
This will accumulate statistics for 10 seconds then send it to the above url in this format:
[192.168.0.1]
This allows you to log the data using a REST-ful web service.
Network mode [n]
Shows total network reads and writes in KBytes or MBytes for that time period.
perl xenstat.pl n
Network I/O (K) 52_pyth 54_garu 59_gyrf Dom-0
2009-10-05 19:55:08 7 979 1 3
2009-10-05 19:55:13 6 1.2M 1 1
2009-10-05 19:55:18 5 600 2 3
Disk IO mode [d]
Shows total reads and write requests for each domain for that time period.
perl xenstat.pl d Disk I/O (Reqs) 52_pyth 54_garu 59_gyrf Dom-0 2009-10-05 19:51:02 4 0 1317 0 2009-10-05 19:51:07 27 0 1140 0
Availability Option [a]
Shows CPU Availability % (which is the same as CPU Idle %) instead of CPU Utilisation %.
The problem with showing CPU Utilisation occurs when you have multiple Guest VMs with different number of vcp
Truncated by Planet PHP, read more at the original (another 3758 bytes)