Monitoring Ubuntu Linux from LoadRunner (RSTAT)

Over the years I’ve used RSTAT to monitor the performance of Linux servers during performance tests many times. Historically I’ve asked Linux admins to enable RSTAT for me but over the last year or two I’ve incorporated various Linux machines into my test and demo environment so I’ve had to do this myself.

I’m primarily a Microsoft specialist so I always seem to rely on Google searches and some trial and error to resolve problems that I encounter with Linux and this weekend was no exception. I spotted a FaceBook post from Scott Moore describing problems that he was having with LoadRunner and RSTAT so I decided to see if I could help him.

2016-11-15-08_16_07-scott-moore

I installed RSTAT on my Ubuntu test machine at home and immediately saw the dreaded error message “Error while creating the RPC client. Ensure that the machine can be connected and that it runs the rstat daemon (use rpcinfo utility for this verification).”

Whatever I tried, I could’t get RSTAT to start. After some ‘Googling’, I found a number of posts in various places which helped me to resolve this problem.

A post on StackExchange (related to NFS issues) told me that rpcbind may have a dependency on a package called nfs-common. I installed this “just in case”. The same post told me that to start STATD (which I think is related to RSTAT) automatically at boot, I needed to add “NEED_STATD=yes” to the file “/etc/default/nfs-common”.

A  post on GadgetWiz.com told me that I should edit my /etc/hosts.allow file to ensure that the local host could make rstatd requests.

After restarting my Ubuntu PC, I checked that RSTATD was running using the commands “rsysinfo localhost” and “rup localhost”. I was pleased to see that after making these changes, it was possible to monitor my Ubuntu machine using LoadRunner.

 

lr_ubuntu2

I repeated my test on a new Ubuntu 16.04 LTS machine which I monitored using LoadRunner 12.53. A list of the commands that I used is below:

Install rstatd and related components:

sudo apt-get install rstatd rstat-client nfs-common

Add a line to /etc/hosts.allow to allow certain hosts to make rstatd requests:

rpc.rstatd: localhost

Added a line to /etc/default/nfs-common to start STATD automatically:

NEED_STATD=yes

These commands confirm that RSTATD is running:

rpcinfo -p localhost 
rsysinfo localhost
rup localhost

Batch file to delete files older than x days from folders in Windows

I’ve been working for a client over recent months and part of my resposibility has been to look after a number of servers used for performance testing. Occasionally drives fill up on the server farm causing outages and obvious interruptions to testing.

It would be a near full-time job to manage all these servers, so to reduce the chance of temporary files from filling up drives and causing problems, I looked into creating a scheduled task to delete old temporary files. Since my server estate is varied, I didnt want to use PowerShell so I opted for an old “DOS” command, FORFILES.

This seems to have done the trick for me:
forfiles /s /m *.* /d -7 /c "cmd /c del @path"

(This command deletes all files that are more than 7 days old from the folder in which it runs.)

Update – To remove folders as well:
forfiles /S /D -7 /C "cmd /c IF @isdir == TRUE RMDIR @path /S /Q"

(This command deletes all folders that are more than 7 days old from the folder in which it runs. – Run it after deleting the files with the command above.)

 

Introduction to performance testing at the NWTG

I really enjoy the NWTG events in Manchester which arintro_nwtge great for the testing community in this area.  I’ve noticed that performance testing is “under represented” at these events (which frequently
have a functional-testing bias).  With this in mind, I tried to give an introduction to performance testing.

For those unable to attend, the slides are available on SlideShare.

….and a video of the presentation is available on YouTube.
(My son thinks that the number of “ums” and “erms” is hilarious. I’m hoping to reduce the number of these “linguistic fillers” for my next presentation)

The final slide includes links to the Trust IV LoadRunner download page as well as blogs that I have found helpful during my time as a tester.

If anybody wants to learn more, don’t hesitate to contact @RichardBishop or @TrustIV via Twitter.