James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
--
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
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
Please note that your virtual users will consume more resources than any C virtual user will and you will have the constant challenge of LR and the Java environment (Which version of LoadRunner to which version of java to getting it to work on your VUGEN box and then translating the same to any load generator.) You _may_ need to license additional virtual user types depending upon your current license. It may be worth noting why C was chosen years ago, because it was the truly portable cross platform language for the virtual users with substantially low overhead to keep out of the way of the weight of the business process.
I think this may be a generational issue. (Outside of Basic), C was my ‘primary’ computer language, so when I come to the Java universe I have to both think in C and functional terms and transpose to Java and object terms, so I am much faster in native ansi C than Java. It sounds like you may be the reverse, thinking ‘natively’ in Java and having to transpose. No matter which path you head, it’s a myth that you don’t need development skills to be successful with _any_ performance test tool, be it open source or commercial.
James Pulley, http://www.loadrunnerbythehour.com/PricingMatrix
Well, before you head down this path and invest all of the time it would be wise to make sure you have the license to support your needs. Next, you will have the added encumbrances of the pleasure that is working with Java in general with performance test tools which historically has not been the prettiest of situations. And then there is the resource tradeoff with Java (at its core) significantly higher in resource costs than an equivalent C based virtual user, with the C based user running much closer ‘to the metal’ versus the Java virtual user which has the overhead of the Java Virtual Machine and the constant ‘thunking’ (swiping a Microsoft term here) of calls back and forth from the Java native calls to the OS native calls.
Having said that there are some environments I work in where I have to deal with Java, such as writing directly to a binding queue|topic in AMQP environment. All of the developers are using Java to integrate around the core, so its just easier to swipe the Java code and modify for use rather than be an orphan in the wild trying to reengineer existing work product in C with no one able to assist. Whenever I have to head down this path I will always run into a Java environment idiosyncrasy which costs me time, such as the version of Java which the developer uses and tests their code with versus the version of Java which is currently being used for the version of LoadRunner, … Of course, you usually find these issues when you run into a “hmmmm, that’s odd…” situation.
So many times the Java app in question can be covered by other protocols which have a more robust environment definition that whenever possible I go to other protocols. Heck, I’ll even do RM/I in Winsock instead of Java where I can.
‘Pulley
Here’s something which may overlooked which could be of use to you in your search for the ability to integrate third party code, lr_load_dll().