Apache JMeter Corporate Online Training | Interview Questions and Answers
-
Upload
ashokvirtual -
Category
Education
-
view
85 -
download
6
Transcript of Apache JMeter Corporate Online Training | Interview Questions and Answers
Call Us: +91- 8885560202 (India)
+1-707-666-8949 (USA)
Mail Us: [email protected]
1. Explain Apache JMeter?
The Apache JMeter desktop application is open to the source software, a 100% pure Java
application designed to load test functional behavior and measure performance. It was originally
designed for testing Web Applications but has since expanded to other test functions.
JMeter is not a browser. As far as web-services and remote services are concerned, JMeter looks
like a browser (or rather, multiple browsers); however JMeter does not perform all the actions
supported by browsers. In particular, JMeter does not execute the JavaScript found in HTML
pages. Nor does it render the HTML pages as a browser does (it's possible to view the response
as HTML etc, but the timings are not included in any samples, and only one sample in one thread
is ever viewed at a time).
2. What can I do with the Apache JMeter?
Apache JMeter may be used to test performance both on static and dynamic resources (files,
Servlets, Perl scripts, Java Objects, Data Bases and Queries, FTP Servers and more). It can be
used to simulate a heavy load on a server, network or object to test its strength or to analyze
overall performance under different load types. You can use it to make a graphical analysis of
performance or to test your server/script/object behavior under heavy concurrent load.
3. What does Apache JMeter do??
Apache JMeter features include below:
Can load and performance test many different server types?
Web - HTTP, HTTPS
SOAP
Database via JDBC
LDAP
JMS
Mail - SMTP(S), POP3(S) and IMAP(S)
Native commands or shell scripts
Complete portability and 100% Java purity.
Full multithreading framework allows concurrent sampling by many threads and
simultaneous sampling of different functions by separate thread groups.
Careful GUI design allows faster operation and more precise timings.
Caching and offline analysis/replaying of test results.
Highly Extensible:
Pluggable Samplers allow unlimited testing capabilities.
Several load statistics may be chosen with pluggable timers.
Data analysis and visualization plugins allow great extensibility as well as
personalization.
Functions can be used to provide dynamic input to a test or provide data manipulation.
Scriptable Samplers (Bean Shell is fully supported; and there is a sampler which supports
BSF-compatible languages)
4. Explain the remote testing in ‘proper way'?
You have:
1. Your application server. You shouldn't run anything on this machine that you wouldn't
have running on it in your proposed or actual production environment (if you are running
anything else, including JMeter, you will be adding load to the server and thus tainting
your results).
2. One or more machines running jmeter-server (the JMeterEngine). You want these
machines to be reasonably close (network wise) to the application server. By "reasonably
close" I mean on the same Ethernet segment or at least with no low speed links between
them. The JMeter User Manual provides reasonable information about doing this.
3. A single machine running the JMeter GUI that you use to control the machines running
the JMeterEngine. While you are developing your scripts and for only moderate levels of
user testing (assuming you are "close" to the application server) you do not need to
involve any JMeterEngine machines.
The reason you have these are to:
1. Eliminate the impact of slow network connections when you are not "close" to the
application server.
2. Execute more than test threads than your local machine is capable of handling. Note that
if the GUI is running multiple remote servers, it can easily become a bottle-neck,
especially if a lot of listeners are being used. Remove all unnecessary listeners before
running stress tests. Running JMeter in non-GUI (batch) mode is preferable, as this uses
far fewer resources. The output log files can be merged after the test run and used to
create overall test statistics. (CVS files can just be appended to each other; XML output
files need a bit of editing to maintain well-formedness.) If there are several nodes running
the JMeter test plan, it is a good idea to try and ensure that their clocks are synchronized,
as this makes it easier to analyze the data later.
5. How can I do the stress testing of EJBs?
You can use the User Manual/Reference/Java Sampler classes to write your own class that runs
your EJB’s, and then JMeter will take over the threading and reporting. This, however, is not
ideal. Someone needs to write a good EJB Sampler implementation for JMeter (hint, hint).