SPECweb2009 Support Frequently Asked Questions |
Last updated 2009-09-25
(To check for possible updates to this document, please see http://www.spec.org/web2009/docs/SPECweb2009_SupportFAQ.html)
Below are some common questions related to setting up and running the SPECweb2009 benchmark. If you have a question which is not addressed here or in the main FAQ, please send it to web2009support@spec.org.
Reread the User's Guide and make sure that you've followed all the steps and have run through the checklists in section 3.
Review this FAQ to see if there is anything similar to the condition you are seeing.
Try running with a higher DEBUG_LEVEL value for more information to isolate the problem.
Save your console logs to files and review them for errors.
If you have done all of the above and are still unable to resolve your problem, write up the details of the problem and send them along with your logs, .config files, and console logs to web2009support@spec.org.
The minimum required time is: ~144 minutes (2.4 hours), with each iteration at 48 minutes. If WARMUP_SECONDS or THREAD_RAMUP_SECONDS have been increased, the test will run somewhat longer.
Invoke the client JVMs with more heap space; for example, assuming the clients have sufficient RAM, the initial and maximum heap sizes can be forced to 512MB (these values are only suggestions, and will vary depending upon system):
java -Xms512m -Xmx512m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
specwebclient
More information about heap size and garbage collection can be found
here:
http://java.sun.com/javase/technologies/hotspot/gc/index.jsp
You must first initialize the benchmark by running 'java specweb
'
with all the variables in the .config files set properly. The init.php
script for each workload will write these variables to init_vars.php,
so be sure user the Web server runs as has write permissions for the
SPECweb2009 directories.
If you have BESIM_PERSISTENT=1, try changing it to 0. During testing, Apache was observed to have issues with attempting to use persistent sockets to BeSim. It is suspected that this is due to the Apache architecture which forks multiple child processes to respond to requests; this makes it difficult to reuse a connection across script executions.
More information about the issue can be found here (search on Apache):
Ensure that the user the Web server process runs as has sufficient permissions to write to the appropriate SPECweb2009 directories. For PHP (all workloads), init.php attempts to write init_vars.php, which contains server-specific variables required to run the benchmark.
For Unix, BeSim attempts to write a globals file to the /tmp directory; for Win32, the root of the C: drive. There are two possible solutions:
BESIM_banking.h
, BESIM_ecommerce.h
,
and BESIM_supportsite.h
to specify different BESIM_BANKING_GLOBALS_PATH,
BESIM_ECOMMERCE_GLOBALS_PATH, and BESIM_SUPPORT_GLOBALS_PATH variables
respectively. You must then recompile the API.PHP ships with two ini files, php.ini-dist and php.ini-recommended. While php.ini-recommended is optimized for performance and security, for initial troubleshooting, php.ini-dist may be a better choice. This will configure PHP to display errors in the browser. You may also want to set "error_reporting = E_ALL", which will display all errors and warnings.
The test_besim_bank.pl
, test_besim_ecom.pl
,
and test_besim_support.pl
Perl scripts (included in the
BeSim directory) good ways to test whether you're getting valid BeSim
responses. Invoke these scripts with the URL to your compiled BeSim API,
i.e.
perl test_besim_bank.pl http://192.2.1.132/isapi-bin/BESIM_zisapi.api
.
The BeSim may need to be to restarted cleanly along with the rest of the testbed software. Try:
stopping the webserver on the SUT
stopping the BeSim webserver
remove /tmp/besim_*.globals
remove old besim access logs
check that none of your clients are running "java specwebclient" processes (kill these processes if present)
start the webserver on the SUT and on BeSim box
re-run your test
Check the following items:
Ensure your clients are not overloaded.
Ensure THINK_TIME to a reasonable level.
Increase THREAD_RAMPUP_SECONDS in Test.config.
SPECweb_Support: [ERROR] SocketTimeoutException
encountered during run!
Occasionally the log has error sequences that begin with: Connection: [ERROR] Bad Status: 503
Your server is overloaded or under-tuned for the number of Simultaneous Sessions the test is requesting. The SocketTimeoutException error occurs when the server was unable to send a response back before the PROTOCOL_TIMEOUT_SECONDS (60 sec) has expired.The 503 status is returned by some webservers to indicate that the service is temporarily unavailable. See if reducing the load on the server eliminates these messages, if so you may wish to investigate if there is addition tuning that could be done to the SUT.
If the errors occur before the line that reads "WorkloadScheduler: Clearing statistics...", then they occurred during warmup and thus are not counted as errors.
Make sure that you are accessing the Web server with the same host name as you specified for the WEB_SERVER variable in Test.config. For example, if WEB_SERVER=192.168.0.1 in your Test.config, you should use a URI such as http://192.168.0.1/ecommerce/index.php (and not a hostname that resolves to that IP address). This is due to the way the Location redirects are done in the scripts.
There is a helpful tutorial available here: http://www.peterguy.com/php/install_IIS6.html
You must also configure IIS to serve all files regardless of file name
extension by adding a wildcard character (*) MIME type. NOTE: This should
not be performed on production Web servers. More information can be found
here:
The message: Error: path length too long for requested file size has to do with very small files (like ccc which is 30 bytes). To be a specweb file it has to have the byte count, relative file name and at least 1 char. of data. So to handle support's smallest image file, the path can be <7chars>/<6chars>/<name>. While you can change the path to something else (sup/sup_images or sup1data/img01 or other as long as it fits into this footprint and the changes are reflected in the SPECweb_<workload>.config. The Wafgen README does include the following warning under the section on Support: Warning: this file set contains several very small files (30 bytes) so the path name must not be longer than 14 characters. So, "support/images" is OK but "supporting/image" is NOT.
List all web server instances (hostnames or IP addresses) in SERVER_LIST, and all ports in SERVER_PORT_LIST. For example, if you have two web server instances (192.2.1.1:80 and 192.2.2.1:81) on one machine, your entries should read:
SERVER_LIST = "192.2.1.1 192.2.2.1"
SERVER_PORT_LIST = "80 81"
SPECweb_Ecommerce[1]: [ERROR] state = 8
response.indexOf fail to find unit price: NN.NN, scaled_load =1
One possible reason for this failure is a localization issue. Try changing the localization settings on the clients to US-format.
This is a rather complex task with several dependencies on the OS you are running on. There is a detailed explanation what needs to be done in the SPECweb2009 User's Guide (Appendix G). A working runtime configuration is described in the following published result file: http://www.spec.org/web2005/results/res2006q2/web2005-20060508-00025.html The important configuration details are listed under the "BESIM Notes" heading. The recommended Apache Version is 2.0 or newer. With earlier versions incompatibilities with certain FastCGI modules appeared in some tests. Successful tests have used mod_fastcgi_2.4.2. There is no experience with older FastCGI versions.
WPD errors will occur whenever the number of requests made during the run period are too few. Because state-to-state (or request-to-request, if you prefer) transitions are based on probabilities rather than being fixed, you need to perform a sufficient number of requests in order to meet the expected request distributions. Try increasing the amount of sessions you are using and/or the runtime duration if you shortened it from the default value.
They will typically look like this:
This
means the specweb process was unable to communicate with the
specwebclient process at IP address 192.168.1.211 via RMI. When it
attempted to do so, the connection was refused. This usually
happens when either the specwebclient process is not started on
that system, or it is started but listening on a different port than
the one specified (or if unspecified, port 1099).
Check the following:
Can you ping the system from the prime client (specweb) system? If not, fix the connection.
Is a specwebclient process started on that system? If not, start it.
Is that system listening on the same port that the specweb process is using when it attempts to communicate with the client? If not, sync the ports.
Is there a firewall running on any of the systems? If so, turn it off.
Your server time is probably way ahead or behind the time on the prime client. Try to synchronize times on the systems in your environment.
The Java (gcj) included with many Linux distributions does not run the Java installer correctly. Also, many times the versions of Java and/or PHP that are included with Linux Distributions are not properly set up by default to support the full SPECweb2009 environment. You may want to install a different Jave Runtime Environment (JRE) and/or stock PHP (http://www.php.net/)
Make sure that you have enabled SSL on your web server. Banking requires HTTPS while Ecommerce requires both HTTP and HTTPS (ports 80 and 443).
"400 Bad Request" errors can occur for many reasons. However, the most common ones are usually resolved via the following:
Ensure that you have permissions set properly for the files and directories used by the benchmark.
Ensure that directories and paths (i.e. PADDING_DIR=, CHECK_IMAGE_DIR=, and IMG_PATH=) are set properly in the .config files
Ensure that directories and paths do not have extraneous or missing /
This issue is related to the way Windows OS authorizes a user. For Windows based systems the WEB_SERVER name must be the correct machine name for the system under test otherwise autherization will fail. This behavior will be the same regardless of script type. As this is an issue with the Operating system and not the ASP.NET kit this issue will remain and currently the user will need to use the actual web server name in the config files.
This is a setup issue that is poorly documented in IIS7. The issue is that by default, session state is maintained in the memory space of the current worker process so each successive request that changes session data simply changes the in-memory data for that worker process. If you have 2 worker processes subsequent requests can be made to either of the worker process for that web site or application with the net result of losing your previous session state data which is in the other worker process memory. If you need to implement more than 1 worker process you will need to change the session state mode settings using the sessions state feature for the ecommerce application.
Copyright© 2009 Standard Performance Evaluation Corporation. All rights reserved.