In a previous blog, I reviewed Virtual Table Server and its history with LoadRunner. I wrote about many of my friends in the testing community who have contributed to it, talked about it, and used it in practice. Today, I want to introduce you to ANOTHER one of my longtime friends, Ed Leno of Solution Maniacs. Ed is one of the most talented performance engineers and consultants that I have had the privilege of working with over the years. He has decided to create a new utility application called SQUID (Simple Queues of Independent Data) that takes the concept of VTS to another level. It’s as easy to use (if not easier) than VTS 2.0, without the technical hoops some of the other proposed solutions require. It’s built as a modern WPF/WCF application.

What about performance? Let’s compare it to VTS. VTS was verified to hold up to 1 million entries per row. The total amount of data VTS can support is only limited by the OS’s maximum limit on process memory. However, VTS only allows users to scroll to the 32,767th row. VTS version 2 had about 5-10 times better performance than version 1.

SQUID is also single threaded as well.  The WCF ConcurrencyMode is set to single. However, it was  tested with 20,000,000 rows, and all of them are scrollable.

This is possible since all the data is kept in memory.  There is currently no disk caching when the set gets large.  This results in the 20,000,000 rows causing SQUID.EXE to consume approximately 2GB of RAM. This means it is really just a matter of how much RAM you want to use.

SQUID prompts you before closing it out that you will lose everything if you don’t export the data (VTS does not do  this).  The parameters (columns) are organized a bit differently than the VTS.  Instead of having the VTS running with all columns displayed together, SQUID allows you to group parameters together.  They will be displayed as tabs.  Each tab can be thought of as a parameter .dat file.  This way, if you have a USERS.DAT file with a userid and password, both of these values will be displayed on the same tab.  If you also have a URLS.DAT file with a url parameter, this will be displayed in the same SQUID, but a different tab.  Multiple SQUID’s can be running at the same time listening to different endpoints (ports).

Here is how some sample code looks in Vugen. First, here is how you would load the dll so you can start working with SQUID:

And sending some data:

Disconnecting from SQUID:

Here is what the SQUID interface looks like with some data. Notice what is populated in the Command text box.

Here is some code to load up some rows to the “Users” column:

And here is how that looks in the SQUID interface.

SQUID requires .NET 4.0 libraries, and you have to execute it as a local administrator on the machine you are using it on. There is no installation, just an executable that points to a DLL. SQUID.dll is a DLL that would be loaded via the lr_load_dll function call in Vugen. Call the service with the functions provided in the documentation,and you are off to the races. The configuration file is used to set the end point address and .NET version.  The port number is set when the SQUID server is started and the Vugen script wants to connect to it. It could very easily be a cloud-based solution if you wanted to implement it that way. Any application that can call web service endpoints can use SQUID. Best of all, it is FREE!

>>>>>Here is the link to SQUID <<<<<

Please make sure to tell Ed you heard about SQUID from me at Northway. That way I can get free BBQ for life from him on my referrals.

Ed is planning some additional features in the future. He also has a blog and will post change logs as new versions are released. If you have some suggestions or comments about SQUID, feel free to put them in the comment section below. For all of you geekazoids who just want to chime in about how SQUID is the name of a web proxy tool —- noted. Now, let’s talk  about how to use Simple Queues of Independent Data to solve some problems.