The GUI versus the Command Line: Which is better? (Part 2)
(As promised this is Part 2 of the GUI CLI blog. Part 1 is here.)
Intro
In Part one of this blog, we saw that we could carry out an OS task and produce the same results whether we were using a CLI or a GUI. This was at least the case when it came to listing the contents of a directory -- which is obviously a very simple operation. There are literally hundreds of other OS tasks that we can complete using a GUI or a CLI. The GUI generally is more intuitive to use and normally has a shorter learning curve. This is a key strength for most GUI. CLI’s generally do not have these same qualities, leading some people to consider this one of their key weaknesses. So now let’s have a look at a key strength for the CLI interface: task automation.
Task Automation
Let’s examine a typical task a Systems Engineer here at MSCOM might have to carry out. As you probably know, SE’s are often called upon to carry out tasks that involve a lot of work, can be extremely repetitive, and need to get done in a very short period of time. Take for example the task of quickly having to run spot checks against performance counters on multiple servers. Say we need to check the number of network connections-established and CPU-utilization values for each server in an eight node cluster. Better yet, let’s say we have five eight-node clusters and we need to have this information gathered within 5 minutes time.
Using the Perfmon GUI
A great GUI tool for observing performance data is the Performance Monitor (Perfmon) utility. With this tool, we have a couple ways to perform our task. One is to term-serve into all forty servers, launch the Perfmon utility on each one, setup our counters and observes our data. Now just logging into each box will probably take about 20 seconds each, at least. That’s a total of 13 minutes and 20 second just to log in. Time's up.
Another way we can do this with Perfmon is to launch it on a single box, setup the counters we want to see and then connect to each server remotely through it. This will allow us to observer both counters from all forty boxes within the utility itself. So let’s see, logging into one box, launching Perfmon and selecting our two counters will probably take about a minute. We’ll then need to connect to the next box through Perfmon and luckily, once that connection is made, the counter that was last selected from the previous box will be our default for the new one – this should save us some time. We’ll then have to select and add the other counter we need. Doing this requires several steps. These include:
· Clicking the Performance Object drop-down and selecting the object
· Selecting the counter from the Counter List
· Selecting the Instance, if applicable
· And finally, clicking the Add button.
This whole process of “clicking around” will probably take about 20 seconds or so for each of the remaining thirty nine boxes. That’s a total of 14 minutes. Time's up.
From these two examples it seems clear that using the Perfmon GUI for our task will take us at least 13 minutes to complete and, not to mention, will require a fair amount of tedious clicking around.
Using the typeperf Command Line Utility
Now let’s take a look at how this task can be accomplished from the command line. Windows comes with a very simple yet powerful command-line tool called typeperf. Taken right out of the help file, the typerperf command “writes performance counter data to the command window, or to a supported log file format.”
To get our counter data from one server we simply launch the typeperf command and include with it three parameters. These comprise of the two counter names we want to observer values from and the name of the remote server we want to query (without the server name paramater, typeperf queries the local machine). For example, to see our metrics from a server named Test01 we would use the following command:
typeperf “TCPv4\Connections Established” “Processor(_Total)\% Processor Time” –s Test01
Note that the counter names we use with typeperf are identical to those used in the Perfmon GUI tool. Each “counter name” actually includes three components: The Object (the stuff before the back-slash); the Counter (the stuff after the back-slash) and the Instance (the stuff in the parentheses --if applicable for the given counter).
Now typing, launching and returning from this command will take less than a minute – let’s say 15 seconds. If we multiply this time by the number of servers we have (40), we’d obviously be well over our time limit. However, this was just the setup. We can now use this basic command as the basis for creating a quick ad-hoc script from the cmd shell. We do this by including the for construct to our command. We’ll also add an additional parameter ( -sc 1) to typeperf. This limits our performance query to a single sample. By using the for construct , we can create a programmatic loop that will check 8 boxes at a time, right from the cmd shell. Our server names are TEST01-08, TEST11-18, TEST21-28 and TEST31-38 so to check the first 8 servers at once, we would use the command:
for (1 2 3 4 5 6 7 8) in $j do typeperf “TCPv4\Connections Established” “Processor(_Total)\% Processor Time” –s TEST0%i –sc 1
This prints out both counter values from all eight boxes, one after the other, allowing us to very quickly spot-check each one, all at once. To check the next 8 boxes we simply use the same command with a slight modification. This modification entails changing the server name from TEST0%i to TEST1%.
Now typing the first command took about a minute. This included being careful to make sure there were no typos (with a little cut-and-paste craftiness typos can be completely eliminated). Running it took about 10 seconds. Construction of the 2nd through 4th commands took only 2 seconds each with the use of the command-line history feature of cmd.exe. If we wanted, we could have nested the for loop with an outer one, or used for’s “ /F” parameter, such that all 40 boxes were checked at once, but let’s not get too completed here. Even without checking all 40 at once, it took less than 2 minutes to collect and observe our performance metrics from every box using a CLI!
A CLI Strength is a GUI weaknesses
With the command line we were able to accomplishing our performance analysis task much faster than we were with the GUI. This is because we were able to automate our task through the use of a simple programmatic constructs. Doing this also made our task more efficient and much less tedious to carry out. Now granted, we needed to be familiar with how typerperf and the for construct worked in order to be proficient with them. Had we not been, we may have missed our deadline of 5 minutes. However, the point here is that the command line is completely conducive to the automation of tasks. This is its strength. The GUI, on the other hand, is not. With the native interfaces and utilities provided by the OS, the GUI makes for an extremely poor platform for automation. Therefore, our score for strengths and weaknesses is one each for both UIs.
Conclusion
In this blog we examined graphical vs. command line user interfaces. We saw that these styles of the UI had both strengths as well as weaknesses. Indeed, we discovered that where one was strong the other was weak, and vice-versa. The appropriate interface for a given task really depends on the nature of the task. In Part 1, we saw that whether the task is complex or simple but does not need to be repeated over and over, the GUI is a good choice. However, if the task is one that is repetitive the command line interface is the best way to go. This is because programs with CLIs can very easily be incorporated into process automation. Unlike the GUI, with its intuitive interface and short learning curve, CLI’s require more time and effort from the user but they are a powerful addition to your task automation tool kit.