Hi All,
I am looking to increase our jmeter test throughput for the following scenario a simple http request with beanshell script generating hmac authentication. How can i speed up the authentication computation ? One thought that comes to mind is Pre-compute HMACS (300K ) and store them in the app. Then when i go to run the 7K of threads, simply pull the authentication from a list. Can any one help with suggestions around this ? --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
When it comes to maximum throughput I believe if you store the pre-generated
hashes in a file somewhere in setUp Thread Group <https://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group> and then read the file using CSV Data Set Config <https://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config> it will be the most performing option. Alternatives are in: 1. Since JMeter 3.1 you should be using JSR223 Test Elements and Groovy <https://jmeter.apache.org/usermanual/best-practices.html#bsh_scripting> language for scripting as currently it's the most performing scripting option, see Apache Groovy - Why and How You Should Use It <https://www.blazemeter.com/blog/groovy-new-black> article for more details 2. There is __digest() function <https://jmeter.apache.org/usermanual/functions.html#__digest> which supports wide range of hashes including several hmac* -- Sent from: http://www.jmeter-archive.org/JMeter-User-f512775.html --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Thank you glinius for your valuable contribution :)
On 2021/02/11 15:19:52, "[hidden email]" <[hidden email]> wrote: > When it comes to maximum throughput I believe if you store the pre-generated > hashes in a file somewhere in setUp Thread Group > <https://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group> > and then read the file using CSV Data Set Config > <https://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config> > it will be the most performing option. > > Alternatives are in: > > 1. Since JMeter 3.1 you should be using JSR223 Test Elements and Groovy > <https://jmeter.apache.org/usermanual/best-practices.html#bsh_scripting> > language for scripting as currently it's the most performing scripting > option, see Apache Groovy - Why and How You Should Use It > <https://www.blazemeter.com/blog/groovy-new-black> article for more > details > 2. There is __digest() function > <https://jmeter.apache.org/usermanual/functions.html#__digest> which > supports wide range of hashes including several hmac* > > > > -- > Sent from: http://www.jmeter-archive.org/JMeter-User-f512775.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
In reply to this post by glinius@live.com
Thank you glinius I forgot one question.
When consuming these hashes within the sampler. Will jmeter / Groovy be able provide some sort of mutual exclusion when reading UNIQUE hash table entries ? On 2021/02/11 15:19:52, "[hidden email]" <[hidden email]> wrote: > When it comes to maximum throughput I believe if you store the pre-generated > hashes in a file somewhere in setUp Thread Group > <https://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group> > and then read the file using CSV Data Set Config > <https://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config> > it will be the most performing option. > > Alternatives are in: > > 1. Since JMeter 3.1 you should be using JSR223 Test Elements and Groovy > <https://jmeter.apache.org/usermanual/best-practices.html#bsh_scripting> > language for scripting as currently it's the most performing scripting > option, see Apache Groovy - Why and How You Should Use It > <https://www.blazemeter.com/blog/groovy-new-black> article for more > details > 2. There is __digest() function > <https://jmeter.apache.org/usermanual/functions.html#__digest> which > supports wide range of hashes including several hmac* > > > > -- > Sent from: http://www.jmeter-archive.org/JMeter-User-f512775.html > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Am 11.02.21 um 17:33 schrieb Clint Fortinbrass: > Thank you glinius I forgot one question. > > When consuming these hashes within the sampler. > > Will jmeter / Groovy be able provide some sort of mutual exclusion when reading UNIQUE hash table entries ? That depends on the type of source. If you take the CSV Data Set Config, you can configure it to be shared among all threads. Combined with stop at the end of the CSV file, will give you uniqueness, when the hashes were unique in the CSV file. You could also pre-calculate (if you want to do that) these hashes into lists (or queues), that you store in JMeter variables. Those are local to the threads and could therefore be used "thread safe". When you share data structures with 7000 threads, you have to make sure, that you don't congest your threads by accessing the shared data structure. Felix > > On 2021/02/11 15:19:52, "[hidden email]" <[hidden email]> wrote: >> When it comes to maximum throughput I believe if you store the pre-generated >> hashes in a file somewhere in setUp Thread Group >> <https://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group> >> and then read the file using CSV Data Set Config >> <https://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config> >> it will be the most performing option. >> >> Alternatives are in: >> >> 1. Since JMeter 3.1 you should be using JSR223 Test Elements and Groovy >> <https://jmeter.apache.org/usermanual/best-practices.html#bsh_scripting> >> language for scripting as currently it's the most performing scripting >> option, see Apache Groovy - Why and How You Should Use It >> <https://www.blazemeter.com/blog/groovy-new-black> article for more >> details >> 2. There is __digest() function >> <https://jmeter.apache.org/usermanual/functions.html#__digest> which >> supports wide range of hashes including several hmac* >> >> >> >> -- >> Sent from: http://www.jmeter-archive.org/JMeter-User-f512775.html >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [hidden email] >> For additional commands, e-mail: [hidden email] >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
You could also pre-calculate (if you want to do that) these hashes into
lists (or queues), that you store in JMeter variables. Those are local to the threads and could therefore be used "thread safe". Thank you Felix for this valuable input also. Considering your above scenario. How would you organize this solution into the httpsampler and beanshell preporcessor? specifically the beanshell pre processor would have 2 parts. 1 computation of 1k of hashes. ( one off at start of all threads) 2. Pop next item in the queue and use it in the http sampler. Thank you. On 2021/02/11 17:51:23, Felix Schumacher <[hidden email]> wrote: > > Am 11.02.21 um 17:33 schrieb Clint Fortinbrass: > > Thank you glinius I forgot one question. > > > > When consuming these hashes within the sampler. > > > > Will jmeter / Groovy be able provide some sort of mutual exclusion when reading UNIQUE hash table entries ? > > That depends on the type of source. If you take the CSV Data Set Config, > you can configure it to be shared among all threads. Combined with stop > at the end of the CSV file, will give you uniqueness, when the hashes > were unique in the CSV file. > > You could also pre-calculate (if you want to do that) these hashes into > lists (or queues), that you store in JMeter variables. Those are local > to the threads and could therefore be used "thread safe". > > When you share data structures with 7000 threads, you have to make sure, > that you don't congest your threads by accessing the shared data structure. > > Felix > > > > > On 2021/02/11 15:19:52, "[hidden email]" <[hidden email]> wrote: > >> When it comes to maximum throughput I believe if you store the pre-generated > >> hashes in a file somewhere in setUp Thread Group > >> <https://jmeter.apache.org/usermanual/component_reference.html#setUp_Thread_Group> > >> and then read the file using CSV Data Set Config > >> <https://jmeter.apache.org/usermanual/component_reference.html#CSV_Data_Set_Config> > >> it will be the most performing option. > >> > >> Alternatives are in: > >> > >> 1. Since JMeter 3.1 you should be using JSR223 Test Elements and Groovy > >> <https://jmeter.apache.org/usermanual/best-practices.html#bsh_scripting> > >> language for scripting as currently it's the most performing scripting > >> option, see Apache Groovy - Why and How You Should Use It > >> <https://www.blazemeter.com/blog/groovy-new-black> article for more > >> details > >> 2. There is __digest() function > >> <https://jmeter.apache.org/usermanual/functions.html#__digest> which > >> supports wide range of hashes including several hmac* > >> > >> > >> > >> -- > >> Sent from: http://www.jmeter-archive.org/JMeter-User-f512775.html > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [hidden email] > >> For additional commands, e-mail: [hidden email] > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [hidden email] > > For additional commands, e-mail: [hidden email] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [hidden email] > For additional commands, e-mail: [hidden email] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [hidden email] For additional commands, e-mail: [hidden email] |
Free forum by Nabble | Edit this page |