Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend Functionality for Dynamically Fetching HW Specific Environment Variables #32

Closed
piyush286 opened this issue Feb 6, 2019 · 4 comments · Fixed by #111
Closed
Labels
enhancement New feature or request

Comments

@piyush286
Copy link
Contributor

Problem Description

For running any benchmark, we need to fetch the HW specific variables that change depending on the machine selected. We also populate these HW specific variables on PerfNext GUI, as shown below in the screenshot, so that users are able to change the affinity and other commands if needed.

image

Currently, environment variables are hard-coded for just one machine right now. So, you would need to manually change environment variables such as CLIENT, DB_MACHINE, LIBERTY_HOST and AFFINITY while running some benchmarks, especially the ones that require more than one machine, such as Liberty DayTrader.

One example of hard-coded configs:
https://github.com/AdoptOpenJDK/openjdk-test-tools/blob/b528a63ea146080f4bb1430740a734c2af87df7e/PerfNext/config/benchmarks/data_simple/Liberty.xml#L18-L31

Proposed Solution

Task 1:

We should remove all machine specific environment variables from the various XML configs files under PerfNext/config/benchmarks/data_simple since they are already present in the /config/master_machine_list.xml, which has all the machine specific configs, a file that the user provides while deploying PerfNext.

Snippet from master_machine_list.xml

                    <capability id="41" name="LibertyDayTrader" bits="all">
                        <property id="1" name="client">perfxposh10G</property>
                        <property id="2" name="dbMachine">perfxposh10G</property>
                        <property id="3" name="dbHome">/home/db2inst1/</property>
                        <property id="4" name="dbName">day30r</property>
                        <property id="5" name="dbUserName">db2inst1</property>
                        <property id="6" name="appServer">DayTrader3</property>
                        <property id="7" name="dbPort">50000</property>
                        <property id="8" name="libertyPort">9080</property>
                        <property id="9" name="scriptName">tradelite.sh</property>
                        <property id="10" name="clientWorkDir">/java/perffarm/liberty</property>
                        <property id="11" name="libertyHost">kermit10G</property>
                    </capability>

Task 2:

While PerfNext was being developed internally, I had already added majority of the functionality for fetching HW specific environment variables such as CPU Affinity variables by coding various functions (shown below) for it in PerfNext/public/lib/js/util.js. We need extend this functionality to fetch other HW specific environment variables that might be missing.

image

Snippet Code from PerfNext/public/lib/js/util.js:
https://github.com/AdoptOpenJDK/openjdk-test-tools/blob/b528a63ea146080f4bb1430740a734c2af87df7e/PerfNext/public/lib/js/util.js#L423-L635

Assigned Contributors

Awsaf (@pinicman) from my team would work on adding this functionality.

@smlambert
Copy link
Contributor

@karianna karianna added this to To do in aqa-test-tools via automation Feb 6, 2019
@karianna karianna added the enhancement New feature or request label Feb 6, 2019
@piyush286
Copy link
Contributor Author

piyush286 commented Apr 23, 2019

Related to this issue Store HW Specific Benchmark Variables for Perf Testing. I thought it might be more appropriate to open a separate issue for that since that would require some additional work.

@smlambert
Copy link
Contributor

Note: we have very recently added the ability to query machine information into the base of testkitgen (a.k.a. Openjdk-tests framework), see https://github.com/eclipse/openj9/tree/master/test/TestConfig/src/org/openj9/envInfo

This may be more useful and suitable to augment for gathering additional machine/hw info, and generating a machine info file needed by perf tests.

@piyush286
Copy link
Contributor Author

Thanks @smlambert for sharing that info. We can discuss this in our PerfNext meeting tmr.

awsafsakif added a commit to awsafsakif/openjdk-test-tools that referenced this issue May 13, 2019
- Closes adoptium#32
- Removed hard coded hardware environment variables
- Extended functionality to look for capability in order to populate HW specific variables

Signed-off-by: Awsaf Arefin Sakif <awsaf.sakif@ibm.com>
awsafsakif added a commit to awsafsakif/openjdk-test-tools that referenced this issue May 14, 2019
- Closes adoptium#32
- Removed hard coded hardware environment variables
- Extended functionality to look for capability in order to populate HW specific variables
- Soft coded NUM_THREADS variable to replace hard coded MULTITHREAD variable

Signed-off-by: Awsaf Arefin Sakif <awsaf.sakif@ibm.com>
awsafsakif added a commit to awsafsakif/openjdk-test-tools that referenced this issue May 15, 2019
- Closes adoptium#32
- Removed hard coded hardware environment variables
- Extended functionality to look for capability in order to populate HW specific variables
- Soft coded NUM_THREADS variable to replace hard coded MULTITHREAD variable

Signed-off-by: Awsaf Arefin Sakif <awsaf.sakif@ibm.com>
awsafsakif added a commit to awsafsakif/openjdk-test-tools that referenced this issue May 15, 2019
- Closes adoptium#32
- Removed hard coded hardware environment variables
- Extended functionality to look for capability in order to populate HW specific variables
- Soft coded NUM_THREADS variable to replace hard coded MULTITHREAD variable

Signed-off-by: Awsaf Arefin Sakif <awsaf.sakif@ibm.com>
awsafsakif added a commit to awsafsakif/openjdk-test-tools that referenced this issue May 22, 2019
- Closes adoptium#32
- Removed hard coded hardware environment variables
- Extended functionality to look for capability in order to populate HW specific variables
- CPU Affinity calculations fixed, also name changed to 4-way instead of cores
- Soft coded NUM_THREADS variable to replace hard coded MULTITHREAD variable

Signed-off-by: Awsaf Arefin Sakif <awsaf.sakif@ibm.com>
aqa-test-tools automation moved this from To do to Done Jun 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

3 participants