Time has come to test the file-manager portlet once again. I'm using the same "MDSSLoadTesting.jmx" file as before, just with slightly bigger files this time.
I have downloaded the files, and just need to run the test within JMeter. I need to add three accounts however to the OGCE portal: ogceUSER1, ogceUSER2, ogceUSER3.
Wednesday, February 20, 2008
Find out if something is running on port 8080
For my remote NMI builds, there is a problem I am facing that the portal I am building won't start on port 8080 because it is "being used by" something else.
Here's a test you can perform automatically to verify if the port is indeed being blocked, and by what (use the "lsof" command). By the way this doesn't actually help me any for my NMI builds since the NMI machines don't have the "lsof" command.
echo -------- IS THE TOMCAT PORTAL ALREADY RUNNING, OR IS PORT 8080 BEING USED? ---------
# COMMAND TO FIND OUT WHAT IS RUNNING ON PORT 8080
lsof -i :8080
if test $? -ne 0; then
echo " => PORT 8080 IS FREE, NO PROBLEMO"
else
echo " => PORT 8080 IS BLOCKED, TRY SHUTTING DOWN TOMCAT SERVER"
portal_deploy/apache-tomcat-5.5.12/bin/shutdown.sh
fi
echo ------------------------------------------------------------------------------------
Here's a test you can perform automatically to verify if the port is indeed being blocked, and by what (use the "lsof" command). By the way this doesn't actually help me any for my NMI builds since the NMI machines don't have the "lsof" command.
echo -------- IS THE TOMCAT PORTAL ALREADY RUNNING, OR IS PORT 8080 BEING USED? ---------
# COMMAND TO FIND OUT WHAT IS RUNNING ON PORT 8080
lsof -i :8080
if test $? -ne 0; then
echo " => PORT 8080 IS FREE, NO PROBLEMO"
else
echo " => PORT 8080 IS BLOCKED, TRY SHUTTING DOWN TOMCAT SERVER"
portal_deploy/apache-tomcat-5.5.12/bin/shutdown.sh
fi
echo ------------------------------------------------------------------------------------
Friday, January 18, 2008
OGCE Local build/run tests almost done
The build and JMeter run tests for the OGCE portal are almost done. I've got a script finished that builds the portal from scratch, runs the JMeter tests, and sends all the result files to SVN.
Things to do:
Things to do:
- Try somehow to show the HTTP response errors for the JMeter modules that failed
- Maybe give a URL link to the errors within the XML document?
- Highlight the tests that failed within the XML document (via XSL stylesheets!)
Adding XSL stylesheet info line on second line of XML document
Solution for #1:
Clip the ?xml...? first line from the XML document, and copy the rest of the XML file into a temporary file. Then insert XSL tag-sheet info as well as the XML document header (which you clipped) into the original file (overwrite the file). Finally, append the temp file's contents to the original file and voila! You've inserted the XML stylesheet info on the 2nd line of your file!
num_of_lines=`cat OGCEJMeterResults.xml | wc -l`
tail -n $[$num_of_lines - 1] OGCEJMeterResults.xml > OGCEJMeterResults-temp.xml
echo (THE XML AND XSL HEAD TAGS HERE) > OGCEJMeterResults.xml
cat OGCEJMeterResults-temp.xml >> OGCEJMeterResults.xml
rm OGCEJMeterResults-temp.xml
Clip the ?xml...? first line from the XML document, and copy the rest of the XML file into a temporary file. Then insert XSL tag-sheet info as well as the XML document header (which you clipped) into the original file (overwrite the file). Finally, append the temp file's contents to the original file and voila! You've inserted the XML stylesheet info on the 2nd line of your file!
num_of_lines=`cat OGCEJMeterResults.xml | wc -l`
tail -n $[$num_of_lines - 1] OGCEJMeterResults.xml > OGCEJMeterResults-temp.xml
echo (THE XML AND XSL HEAD TAGS HERE) > OGCEJMeterResults.xml
cat OGCEJMeterResults-temp.xml >> OGCEJMeterResults.xml
rm OGCEJMeterResults-temp.xml
Wednesday, January 16, 2008
Local OGCE build/run test
I'm setting up a local (non-NMI) build and run test of the OGCE framework.
Steps completed:
1) Script made that:
- svn checks out portal
- does a clean build on portal (maven, tomcat bundled)
- starts up portal on tomcat server
- runs JMeter test file against portal and stores results of test in XML file
2) XSLT Style sheet made that converts JMeter resultant XML output file into readable HTML
Things to do:
1) Auto insert XSL tag into the JMeter resultant XML output file (tag specifying the XSL stylesheet must but at the top of XML file to have it display properly):
2) Send the XML test results file and stylesheet to soureforge account
3) Store build text output in a file, and send to soureforge account
Steps completed:
1) Script made that:
- svn checks out portal
- does a clean build on portal (maven, tomcat bundled)
- starts up portal on tomcat server
- runs JMeter test file against portal and stores results of test in XML file
2) XSLT Style sheet made that converts JMeter resultant XML output file into readable HTML
Things to do:
1) Auto insert XSL tag into the JMeter resultant XML output file (tag specifying the XSL stylesheet must but at the top of XML file to have it display properly):
2) Send the XML test results file and stylesheet to soureforge account
3) Store build text output in a file, and send to soureforge account
Thursday, December 13, 2007
JMeter Load Testing - how to use the test file
The following represents rough directions on how to do load testing with the mdss jmeter test file.
1) Open the file in JMeter (File->Open)
2) You will need to give the test file your MyProxy login information for the tests to work.
- In the left hand navigation, click on the HTTP request titled "Proxymanager (request proxy)"
- Enter your username in the username field, and password in the password field
3) If you want to increase the load, just add more users (and respective files to upload)
- In the left hand navigation, click on the "User parameters" link
- Click the "Add User" button at the bottom of the screen
- Add a corresponding "FileName", "usernameValue", and "mdssFileIndex" for each new user
- mdssFileIndex should be one higher than the corresponding value for the previous user
4) Decide on how many users you want to run this test with
- Click on the "Thread Group" link at the top of the left-hand navigation
- In the "Number of Threads" input box, enter how many users you want to run the test with (note: it is limited by the number of users you have specified in step number 3 above).
5) Run the test
- Click the "Run" dropdown menu at the top toolbar, then select "Start"
- The green square at the top right of the screen means the tests are still running
- To see the test results live, click on "View Results Tree" in the left hand navigation at the bottom
6) Analyze results
- Click on the "View results tree", "Graph Results" etc.. links in the left-hand navigation at the bottom to see statistics on the results of the test-run.
1) Open the file in JMeter (File->Open)
2) You will need to give the test file your MyProxy login information for the tests to work.
- In the left hand navigation, click on the HTTP request titled "Proxymanager (request proxy)"
- Enter your username in the username field, and password in the password field
3) If you want to increase the load, just add more users (and respective files to upload)
- In the left hand navigation, click on the "User parameters" link
- Click the "Add User" button at the bottom of the screen
- Add a corresponding "FileName", "usernameValue", and "mdssFileIndex" for each new user
- mdssFileIndex should be one higher than the corresponding value for the previous user
4) Decide on how many users you want to run this test with
- Click on the "Thread Group" link at the top of the left-hand navigation
- In the "Number of Threads" input box, enter how many users you want to run the test with (note: it is limited by the number of users you have specified in step number 3 above).
5) Run the test
- Click the "Run" dropdown menu at the top toolbar, then select "Start"
- The green square at the top right of the screen means the tests are still running
- To see the test results live, click on "View Results Tree" in the left hand navigation at the bottom
6) Analyze results
- Click on the "View results tree", "Graph Results" etc.. links in the left-hand navigation at the bottom to see statistics on the results of the test-run.
MDSS/BigRed Load Testing
I am working on a JMeter testing file to test the uploading and downloading capabilities of the file-manager portlet via connecting to MDSS (HPSS) and BigRed.
Important notes of the testing scheme:
- Each "user thread" within JMeter represents a unique portal user who will upload, transfer, and download a unique file
- To do more intense load testing, just add new users and new files for those users. Right now the test is set up to have a maximum of 3 users
- Sending the file from MDSS to BigRed requires knowing the "index" of the file. These all need to be hard-coded. For example, for my MDSS account, the first file is hard-coded to be at index 12 in the file-manager list, the second file is index 13, and the next at 14.. and so on. This is the case because whenever you upload a file to MDSS, it gets placed at the bottom of the list. My mdss account had 12 files originally (index starts from zero), so after the first upload, the newest file was given an index of 12 (remember index starts from zero).
Important notes of the testing scheme:
- Each "user thread" within JMeter represents a unique portal user who will upload, transfer, and download a unique file
- To do more intense load testing, just add new users and new files for those users. Right now the test is set up to have a maximum of 3 users
- Sending the file from MDSS to BigRed requires knowing the "index" of the file. These all need to be hard-coded. For example, for my MDSS account, the first file is hard-coded to be at index 12 in the file-manager list, the second file is index 13, and the next at 14.. and so on. This is the case because whenever you upload a file to MDSS, it gets placed at the bottom of the list. My mdss account had 12 files originally (index starts from zero), so after the first upload, the newest file was given an index of 12 (remember index starts from zero).
Subscribe to:
Posts (Atom)