I want to know when checking Cache compiled script if available checkbox is wrong,
Following Best practices there are some situations that Cache compiled script shouldn't be used, but the example of not using ${varName} is wrong, I did a test and the value it's taking is the updated value of ${varName} and not the first value.
When using JSR 223 elements, it is advised to check Cache compiled
script if available property to ensure the script compilation is
cached if underlying language supports it. In this case, ensure the
script does not use any variable using ${varName} as caching would
take only first value of ${varName}.
Does someone knows of a real case it's wrong to use caching?
EDIT
I check using ${varName} in script and there are similar results with/without caching:
I define variable in Jmeter called aa with value 1, and created a script:
def aa = "2";
aa = "3";
log.info("${aa}");
Value 1 was return in both cases of checkbox, so it doesn't relate to caching
Also tried with Beanshell (not compiled language without def aa = "2";) and got same results.
What is meant by documentation is that whenever ${varName} has a different value a new entry is stored in cache which will end up filling it with useless data.
So in this case it is wrong and ${varName} should be replaced with
vars.get("varName")
In fact I don't see real reason for unchecking this option provided you use the right JMeter syntax
The option is unchecked by default due to the risk described above and also for "non consensus" reasons:
https://bz.apache.org/bugzilla/show_bug.cgi?id=56554
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201212.mbox/%3CCAH9fUpZ7dMvuxq9U5iQYoBtVX7G-TqOx4aJjjOnPcp%3D5Fc%3D8Qw%40mail.gmail.com%3E
http://mail-archives.apache.org/mod_mbox/jmeter-dev/201301.mbox/%3CCAH9fUpbnde3mnyKmHXwoQeL-SqZUA0Wt1%3D%3D-XMxQWq3ZAS6Pvw%40mail.gmail.com%3E
As to performance, it is exactly the same wether or not you check it for a language that does not support compilation as the first thing JMeter does is to check "supportsCompilable" before using the checkbox, see:
https://github.com/apache/jmeter/blob/trunk/src/core/org/apache/jmeter/util/JSR223TestElement.java#L171
You should not be using caching when you use a scripting engine which does not support caching if compiled scripts. Since only Groovy is capable of compiling scripts you should tick this box for Groovy and untick for the other engines (the code block which does not make sense will be triggered each time the script will be called)
Well-behaved Groovy engine should:
Compile script in the runtime to avoid interpretation each time
Cache compiled script to avoid recompilation
Recompile script and update the cache if any changes are being made to it.
Inlining JMeter functions and variables into scripts is a little bit dangerous for any language as it might resolve into something which cause compilation failure or even even worse result in code which you don't expect. In case of Groovy JMeter Variables syntax conflicts with Groovy GString template
So inlining variables will cause overhead for recompiling the script each time it's called.
So please continue following JMeter's Best Practices and remember one more little tip: avoid scripting where possible as none scripting option performance behaves as fast as Java does, check out Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! guide for details.
Related
I am running a local blastx server. One of the command line options is -num_threads. Looking at the executable, blastx, thinking it may be a shell script that sets OMP_NUM_THREADS, it turns out that it is in machine code. I am assuming (possibly incorrectly) that it is an OpenMP application and this got me thinking.
Question : is it possible to change the number of OpenMP threads as a command line option, as opposed to using the environmental variable OMP_NUM_THREADS?
Using OpenMP, you have basically 3 different ways of specifying the number of threads to use in a parallel region:
The most commonly used one is the environment variable OMP_NUM_THREADS which needs to be set in the code's environment prior to running it for being effective;
The function omp_set_num_threads(), to be called before reaching a parallel region; and
The optional num_threads() clause of the parallel directive.
The relative priorities of these are defined in great details by the standard but pretty much boil down to num_threads() taking precedence over omp_set_num_threads(), which itself takes precedence over OMP_NUM_THREADS.
So now, if you want to have your code defining the number of OpenMP threads to use as a command line option, what you need is:
To parse you command line, either by hand, or using a function like getopt, and to store the value you read in a variable; and
To use this value in either a call to omp_set_num_threads() or as a parameter to the num_threads() clause. Either of the two will take precedence to the possible value set for OMP_NUM_THREADS.
OMP_NUM_THREADS is parsed by the program at runtime, so it already does what you want.
Setting it at compile time has no effect (unless you specifically design your build system to use it).
Because you export this environment variable, it's there at runtime as well. That's why you think it is doing something when you compile.
]2I am trying to write script in Beanshell preprocessor to manipulate an input text file containing a list of locations. I want to pass Location 1 as input for the 1st user's destinations, Location 2 as second user's destination and so on... I also want to send a combination of locations for some users. Please help me with this.
Thanks in advance.
If you need to parametrize your test so different users would use different locations from the text file - you don't even need Beanshell. Take a look at __StringFromFile() function - it reads next line from the specified file each time it's being called.
If you still want to use Beanshell - just consider it Java as it's almost Java compliant. To be completely sure that your test will work - write it J2SE 1.4-way.
Be aware that if your script logic is complex and it does something "heavy" and/or if you plan to produce immense load - it's better to consider JSR223 PreProcessor and Groovy scripting language as:
Groovy is even more Java-compliant than Beanshell
Groovy engine performance is much higher
See Beanshell vs JSR223 vs Java JMeter Scripting: The Performance-Off You've Been Waiting For! guide for different scripting engines benchmarks, instructions on installation of groovy engine and scripting best practices.
I am preparing LaTex/Tex fragments with lua programs getting information from SQL request to a database (LuaSQL).
I wish I could see intermediate states of expansion for debugging purpose but also to control what has been brought from SQL requests and lua processings.
My dream would be for instance to see the code of my Latex page as if I had typed it myself manually with all the information given by the SQL requests and the lua processing.
I would then have a first processing with my lua programs and SQL request to build a valid and readable luaLatex code I could amend if necessary ; then I would compile again that file to obtain the wanted pdf document.
Today, I use a lua development environment, ZeroBrane Studio, to execute and test the lua chunk before I integrate it in my luaLatex code. For instance:
my lua chunk :
for k,v in pairs(data.param) do
print('\\def\\'..k..'{'..data.param[k]..'}')
end
lua print out:
\gdef\pB{0.7}
\gdef\pAinterB{0.5}
\gdef\pA{0.4}
\gdef\pAuB{0.6}
luaLaTex code :
nothing visible ! except that now I can use \pA for instance in the code
my dream would be to have, in the luaLatex code :
\gdef\pB{0.7}
\gdef\pAinterB{0.5}
\gdef\pA{0.4}
\gdef\pAuB{0.6}
May be a solution would stand in the use of the expl3 extension ? But since I am not familiar with it nor with the precise Tex expansion process, I prefer to ask you experts before I invest heavily in the understanding of this module.
Addition :
Pushing forward the reflection, a consequence would be that from a Latex code I get a Latex code instead of a pdf file for instance. This implies that we use only the first steps of the four TeX processors as described by Veijkhout in "TeX by Topic" : the input processor, the expansion processor (but with a controlled depth of expansion), not the execution processor nor the visual processor. Moreover, there would be need to show the intermediate state, that means a new processor able to show tokens back into readable strings and correct Tex/Latex code that can be processed later.
Unless somebody has already done or seen something like that, I feel that my wish may be unfeasible in the short and middle terms. What is your feeling, should I abandon any hope ?
I have a VB6 application that I'm trying to make log out differently. What I have is a flag in the registry (existing) which states if the application is set to Debug mode so that it would log out.
Within my code I then have lots of if statements checking if this is true. This means that there is a lot of processing time checking if a statement is true, which maybe not much really but as it does it so often it's an overhead I would like to reduce.
The code is full of statements like this
If isDebug = True Then
LogMessage("Log what is happening")
End If
So what I'm looking for is a better way to do this. I know I can set a debug mode within Project Properties -> Make, but this needs to be set prior to building the .exe and I want to be able to set this in production via the registry key.
Consider using a command line argument to set debug mode. I used to do this.
Dim sCommandLine() As String
sCommandLine = Split(Command$)
For I = 0 To UBound(sCommandLine)
' do something with each arg
Next I
You can also persist command line args inside the IDE, so you always have them when debugging. When running outside of the IDE, make a shortcut to the compiled application with the arguments in it.
I do something almost identical to what you have in mind in a lot of my code. Add this:
Sub LogDebug(ByVal strMsg As String)
If (isDebug) Then
LogMessage(strMsg)
End If
End Sub
Then just call LogDebug in your main program body, or call LogMessage directly if it's something you always want to log, regardless of the debug flag.
I'm assuming isDebug is a boolean here. If it's a function call, you should just create a global flag that you set at the beginning of the code, and check that instead of looking at the registry over and over. I don't think checking a boolean is that much of a processing load, is it?
You want to call a function if a runtime flag is set. The only thing I can see that could be faster is:
If isDebug Then
LogMessage("Log what is happening")
End If
But I doubt that either would be the cause of performance problems. Most logging frameworks promote code like that and even put the flag/log level as a parameter to the function. Just be sure that you don't have other places where you needlessly compute a log message outside of the conditional statement.
You might evaluate why you need logging and if the logs produced are effective for that purpose.
If you are looking for a problem that can be trapped using VB error handling, consider a good error handling library like HuntERR31. With it you can choose to log only errors instead of the debug message you are now doing. Even if you don't use the library, the docs have a very good description of error handling in VB.
Another answer still:
Read your registry flag into your app so that it's a session based thing (i.e. when you close and restart the app the flag will be checked again - there's no point in checking the registry with every single test).
Then (as per Tom's post) assign the value to a global variable and test that - far faster than a function.
To speed up logging you may want to consider dimensioning a string buffer in your app and, once it has reached a specific size, fire it into your log file. Obviously there are certain problems with this approach, namely the volatility of the memory, but if you want performance over disk access I would recommend such an approach.
This would, of course, be a lot easier if you could show us some code for your logging process etc.
I have some issues when using Lauterbach debug tools. I want to create Practice scripts and integration to existing scripts.
For example, I'm testing for board ARM. I have a script arm.cmm, but when I'm running it the value of a register is changed. I can use debugging and detect that manually but I want it to be done by full auto.
So I'm using Practice script language to check the value of the register but I don't know any way to integrate the new script .cmm to existing scripts.
How can I do that?
DO <filename.cmm> [<paramaters>]
ENDDO
The DO command starts a PRACTICE program. The DO command can be used on the command level to start a PRACTICE program or within a program to run another file like a subroutine. PRACTICE files started by a DO command should be terminated by the ENDDO instruction. Additional parameters may be defined
which are passed to the subroutine. The subroutine reads the parameter list by the ENTRY command.
I'm not sure I entirely understand... a register is changing out from under you when you are debugging? Do you just want to print out contents of the register or do you want to do logical comparisons on it?
Either way I recommend giving them a call or shooting them an email. The Lauterbach is a great debugger, but it can be complex. I know the guys in the Mass division and they are incredibly helpful and can answer a question like that immediately.