load generator connects but wont run script

[Sam]

Hi all.

As a reminder, I am a fairly new LoadRunner user and learning.

We are using Loadrunner V11.3 and ALM V11.?.

I have a small Loadrunner environment setup, 1 controller and 5 load
generators. I can run fine with this environment.

I am working with ODBC scripts, very simple. Only up to about 65
scripts heading towards around 500.

I added 5 more load generator pc's and I can get them to connect and
the controller does transfer the scripts to them but the VU's never
start on the new pc's. I get a lot of error messages with no text in
the description and code fields.

All load generators are using the same userids and passwords, Userid
is full admin on the pc's..
All pc's and controller are in the same domain and Active directory
setup. Same DNS. (all in same room too).
All pc's are running XP.

I can run the scripts successfully on any of the original 5 Load
Generator pc's.

All data files are on all pc's in the same directory structure. All
local, no shares.

I have all pc's at same maint level from what I can tell, HP update
finds no fixes needed on any pc. Patch level 3 on all pc. (Actually
using LoadRunner with Service Test add on if that matters).

I have not modified any paths or anything like that. Again, very
simple setup , at least I thought it was.

Our license is for 600 database VU's and 1000 web2. but only using
ODBC right now. I have 4 vu's per script and about 65 scripts, well
below our license.

The load generators disconnect after trying to start the vu's.

I am sure there is something I am doing wrong but I can not find any
error message or file that tells me what is wrong, so I would really
appreciate some pointers!

[James Pulley]

That you are new, have 65 scripts now and are headed for 500 tells me with a high degree of certainty that you have a major process and concepts malfunction where you are attempting to reproduce all functional edge cases in performance scripts

Sam <srudo...@gmail.com> wrote:

>--
>You received this message because you are subscribed to the Google "LoadRunner" group.
>To post to this group, send email to LR-Loa...@googlegroups.com
>To unsubscribe from this group, send email to
>LR-LoadRunne...@googlegroups.com
>For more options, visit this group at
>http://groups.google.com/group/LR-LoadRunner?hl=en

[Sam]

Thanks James for your insight.... it really helps with my problem. I
think I notice a trend with your responses.
We have around1000 DB2 stored procedures and growing everyday but we
will only be using about 150 to 200 at a time for LOAD testing..These
usually make up about 75-80% of the transaction rate, cpu, IO, and
memory usage. We have a very rapidly growing SQL server, internal web,
and web service load, just depends on what part of multiple
applications we need to test. There will be more than 500 in a few
years...we create most of the scripts so that they are long term
reusable with minor changes. We are new to LoadRunner, but not
loadtesting. Most are low volume and won't be in the "load" test, but
we use load testing scripts for testing major new features and
functions at times too. Will already have the scripts, and it gives
us a head start on finding problems with non load changes. .Since DB2
stored procedures are written in a number of different languages, we
also need a wide range of samples in various tests for different
reasons, not just load testing. You can find a lot of issues with
OS, middleware, and DB upgrades or changes using a low volume and a
range of the same scripts as you use for load testing, we have been
VERY successful in finding (non LOAD related) problems using this
method without having to get lots of programmers and testers involved,
they still have to test but we can find and resolve most problems
before wasting their time.
We are in the process of adding QTP, Sprinter, and Service Test
scripts to other testing methods too. We did not have tools like those
before. These might not end up being so reusable due to the fast rate
of change in the applications front ends, but yes we know that there
are ways to help with that. We are just starting to learn, and I am
sure we will make a LOT of mistakes.

After sleeping on the issue, I have an idea what it might be, the new
pc's may not have the correct ODBC driver..it was recently updated and
these pc's were being used for something else. . I will check that
today. Thanks again James!


On Sep 22, 10:49 pm, James Pulley <loadrunner-li...@jamespulley.com>
wrote:

[James Pulley]

That makes sense then, these are functional validation scripts and you
understand them as such. Then I owe you an apology. I cannot tell
you how many times a month I have desperate questions from someone who
has been moved over from functional to performance and they are trying
to reproduce their entire functional validation set as performance
scripts. Your question and awareness for the reasons why you are
working with the model you have is certainly the exception in today's
market.

If you find that a standard protocol such as web or winsock will work
fine from your generators then you are likely on the right path with
the environmental dependecy for ODBC. In addition to the ODBC driver
you may need to install your standard client software for DB2, SQL
Server, etc... as some ODBC drivers actually leverage the client
software underneath the covers, such as

ODBC Program (mdrv)
|
\ /
ODBC Driver manager
|
\ /
ODBC Driver
|
\ /
Client Libraries for
connection to ODBC
data source

If you find that you get an API to execute correctly but you get a
connection error then take a look at the ODBC driver to see if it
needs the full client installation underneath as well as taking a look
at the connection definition to see if you need to have a specific
ODBC instance name defined to work with your recorded connection.

James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix

[Sam]

Thanks for that James! I probably should have just left that 500
number out of the picture anyway...does not matter to the problem

I am at work now and the ODBC drivers are the right ones. Rats, would
have been too easy.

I will try to build a simple web script and try that... good
suggestion. Another learning opportunity. Been focused on ODBC so
far.
I will do some more ODBC testing directly, I am the DB2 ODBC guy too
so I know what to look for. Or I should. The right drivers are there
but now I have to test them. Not DB2 Connect btw. Shadow ODBC driver
from DataDirect... good stuff.
In our case, the ODBC driver is not linked directly to the client
software in any fashion, unless you are running the thick client. And
my testing does not.
Thanks again!

On Sep 23, 8:56 am, James Pulley <loadrunner-li...@jamespulley.com>
wrote:

> James Pulley,http://www.loadrunnerbythehour.com/PricingMatrix

> > > >http://groups.google.com/group/LR-LoadRunner?hl=en- Hide quoted text -
>
> - Show quoted text -

[Sam]

Figured it out...but not the root cause.
I have common code for logon and logoff in all my scripts, so I have
includes for that code so I can manage changes to it with less issue.
That worked on VUGEN and my 5 original Load Gen Pc's.
The include is on share on the SAN and I mapped the Q: drive to it on
all pc's. This worked on VUGEN, Controller, and the first 5 Load Gen
PC's.
I verified the drive was mapped correctly on the failing loadgen pc's
and even started up VUGEN and ran a script on that PC (which did work
correctly).

I finally found an error file on the load gen pc that said it could
not find the includes. So... I changed the scripts to use NLS path
names instead of trying to use a drive mapping. This works on ALL
pc's now. I don't know why the drive mapping works on some and not
others.
I have now seen some mention that I should use NLS paths on google
searches.

Part of my confusion comes from not knowing that LoadRunner recompiles
the scripts on the LoadGen pc's when running a load test. Did not
expect or notice that before.
Can it just transfer the compiled script? I have not seen an option
for that yet.
Is that due to our using ALM to store the scripts? I have more
research to do now.

Thanks!

> > > > >http://groups.google.com/group/LR-LoadRunner?hl=en-Hide quoted text -
>
> > - Show quoted text -- Hide quoted text -

[James Pulley]

LoadRunner transfers text files to the load generator for local
compilation because of a couple of odd artifacts of its heritage.
Load Generators used to be a lot more platform promiscuous than they
are now, with many organizations using both UNIX (pre-widely
distributed LINUX era) and Windows boxes for load generation. By
transferring the C source and then affecting a local compilation you
can then leverage the platform specific libraries based upon the
target load generator. The transfer as source is still around for
the same reason which allows for the source built on 32 bit window
systems to be replayed on Win-32, Win-64, LINUX and UNIX boxes without
any source changes. Even in the LINUX universe people recognize the
value of this, use the source Luke.

The second is that LoadRunner virtual users don't really compile all
of the way to a compiled executable. If you take a look at what the
embedded LCC compiler produces what you get in the end is a .CI file,
which is almost but not quite all of the way to a pick up and run
executable file. If you have time I recommend reading the
architecture documents for the LCC compiler (Google can find these
things) and it will provide a lot of insight into the LoadRunner
compiler.

> > > > > >http://groups.google.com/group/LR-LoadRunner?hl=en-Hidequoted text -

[Sam]

That makes sense... I was just thinking of my limited Windows world.
Thanks for the info on the compiler, I will try to find time to read
it. I suspect that will help alot.
RoadRunner works vastly different than QA/Load but LR had more
flexibility.
Maybe they will send me to school next year...only a maybe so far!
Heading to google now... thanks again.

On Sep 23, 3:50 pm, James Pulley <loadrunner-li...@jamespulley.com>

> ...
>
> read more »- Hide quoted text -