Working with large response maps

Question

question

respy asked Aug 13, '10 amichaels edited Dec 2, '15

Working with large response maps

I am attempting to create a very large response map table. The problem I am having is the time it takes for iTest to map the table initially and every time I attempt to work with the associated response. It also has a tendency to lock up iTest as well. I have increased the memory in my iTest.ini file to 2048, which helped to a certain extent.

Here is what I am trying to accomplish:

I have two large tables (table_a and table_b)

I would like to iterate through each row in table_a and assign to a variable (row_n)

Then I would like to iterate through each row in table_b to see if I find a match for row_n.

I was hoping to do this using row queries from a response table map but I may have to find another way. Any help would be appreciated.

iTest response map

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 1 · 2015-12-01T14:58:32Z

Gerkman answered Dec 1, '15 amichaels edited Dec 1, '15

Hi all,

I am also having trouble with large response maps. I am having around 5000 rows and 20 columns. The responsive of iTest is bad at this size of the response map. When I want to select query from response map it takes few minutes just to show the queries. And it also takes long time when fetching the response. I thought that response maps were made for large responses.

I have tried to reduce the size of the responses but in few of my tests I need large response maps.

Does anybody have any ideas how to solve this issue?

I am using iTest 4.3.0

Regards,

Ales

3

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

amichaels ♦ commented · Dec 01, 2015 at 04:20 PM

One approach you could use is to redirect the output (the 5000 lines) to a file, then use the file session type to access it. It allows you to iterate through a file line by line. This will save on memory usage, and should speed things up quite a bit.

0 ·

Gerkman commented · Dec 02, 2015 at 08:34 AM

This sound like a good idea. Where could I find some tips on how to use File session?

Thanks

0 ·

amichaels ♦ Gerkman commented · Dec 02, 2015 at 02:58 PM

The file session command reference in iTest help is fairly good. The session type itself is somewhat simple and only has a few commands. You open the file, and then you can navigate the file line by line, even skipping lines. One trick for growing files (like log files) is to keep track of your last position and when you need to open the file later, skip to the last known position. The help references a video on the File session, but I couldn't find the video on the support site. Hope that helps.

Oh, another thing to be aware of, the remote file access doesn't work as expected. I'd recommend saving the response of a step as a file (locally), then opening that file for reading. To do this:

select the step that has the desired response.
open the "step properties" pane
under "Other Post Processing", select "store response"
specify where you want the file to live

0 ·

Answer 2 · 2010-08-13T15:35:31Z

AdamB answered Aug 13, '10 AdamB posted Aug 13, '10

Are you having problems creating the response map with a big response? Or using that response map in a test case that has big responses?

2

10 |950

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

respy commented · Aug 13, 2010 at 06:34 PM

The large response time makes the map very difficult to use. It is about a 5 minute wait every time I click on a step that uses that map. I have started using Linux commands to parse the file.

0 ·

AdamB respy commented · Aug 13, 2010 at 06:47 PM

Yeah, when iTest is mapping it, it is creating a new data structure will all that information in it and it can be very slow. If you want to attach your response map and a sample of the response, we can see whether or not we can improve mapping in some way to make it faster.

Some customers that have been trying to work with large responses have taken two paths.

1. Filter/limit the data - this would be via response filters for all lines that aren't interesting or using the grep command on the device

2. Perform the DIFF on the dut and then use iTest to parse out the differences and make meaning out of them.

0 ·

question