Jun 09, 2009

[AS] Apache Tomcat で gzip 圧縮を有効にする方法

Apache Tomcat で gzip 圧縮を有効にする方法をメモ。

Apache Tomcat Configuration Reference - The HTTP Connector
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
compression
The Connector may use HTTP/1.1 GZIP compression in an attempt to save server bandwidth. The acceptable values for the parameter is "off" (disable compression), "on" (allow compression, which causes text data to be compressed), "force" (forces compression in all cases), or a numerical integer value (which is equivalent to "on", but specifies the minimum amount of data before the output is compressed). If the content-length is not known and compression is set to "on" or more aggressive, the output will also be compressed. If not specified, this attribute is set to "off".
$CATALINA_HOME/conf/server.xml を以下の様に設定する。
<Server port="8005" shutdown="SHUTDOWN">
    <Connector port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" 
               useBodyEncodingForURI="true" 
               compression="on"/>
</Server>

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Dec 26, 2008

[AS] Tomcat Native で不可思議なエラー

Apache HTTP Server + APR + Tomcat Native + Apache Tomcat 環境下で、特定条件の HTTP コネクションが途中で切れる現象が発生した。 結論から言うと Tomcat Native のバグの様で、Tomcat Native をバージョンアップしたら直った。 同様の症状が発生したという情報は見つかったが、解決したという情報が見当たらなかったのでメモ。

症状が発生した環境

  • Apache HTTP Server 2.2.6
  • Apache Portable Runtime 1.2.7-10
  • Apache Tomcat 5.5.25
  • Apache Tomcat Native 1.1.6

出力されたログ

/var/log/httpd/error_log

[error] (70014)End of file found: ajp_ilink_receive() can't receive header
[error] ajp_read_header: ajp_ilink_receive failed
[error] (120006)APR does not understand this error code: proxy: dialog to 127.0.0.1:8009 (localhost) failed

$CATALINA_HOME/logs/catalina.out

ClientAbortException:  java.io.IOException
        at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:366)
        at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:432)
        at org.apache.tomcat.util.buf.ByteChunk.append(ByteChunk.java:291)
        at org.apache.catalina.connector.OutputBuffer.writeByte(OutputBuffer.java:414)
        at org.apache.catalina.connector.CoyoteOutputStream.write(CoyoteOutputStream.java:77)
        at java.io.FilterOutputStream.write(FilterOutputStream.java:60)
        at java.io.FilterOutputStream.write(FilterOutputStream.java:108)

    (SNIP)

        at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
        at org.apache.coyote.ajp.AjpAprProcessor.process(AjpAprProcessor.java:444)
        at org.apache.coyote.ajp.AjpAprProtocol$AjpConnectionHandler.process(AjpAprProtocol.java:472)
        at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
        at java.lang.Thread.run(Thread.java:595)
Caused by: java.io.IOException
        at org.apache.coyote.ajp.AjpAprProcessor.flush(AjpAprProcessor.java:1199)
        at org.apache.coyote.ajp.AjpAprProcessor$SocketOutputBuffer.doWrite(AjpAprProcessor.java:1284)
        at org.apache.coyote.Response.doWrite(Response.java:560)
        at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:361)
        ... 26 more

解決策

Tomcat Native を 1.1.6 → 1.1.8 にバージョンアップしたら改善した。

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Nov 07, 2008

[AS] Apache Tomcat + DBCP で Connection のリークを確認する方法をメモ

Apache Tomcat + DBCP の環境で Connection のリークを確認する方法をメモしておく。 この設定のおかげで、リリース直前のコードに潜んでいた Connection のリークを発見できた。 Connection を自前でハンドリングするのであれば、もう少し気を使ってコーディングして欲しいものだ。 とは言え、コーディングするのも人間。 ミスすることを前提として、開発環境では必ずこの設定をしておきたい。 そのうち自分でやらかして怒られるかもしれないし(^^;

Apache Tomcat 6.0 - JNDI Datasource HOW-TO : Preventing dB connection pool leaks
http://tomcat.apache.org/tomcat-6.0-doc/jndi-datasource-examples-howto.html#Preventing%20dB%20connection%20pool%20leaks

context.xml の設定

Apache Tomcat にディプロイする Web アプリケーションの context.xml に以下の設定を追加する。

<Context ...>
  <Resource ...
        factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"
        removeAbandoned="true"
        removeAbandonedTimeout="300"
        logAbandoned="true" />
</Context>

各設定の意味は以下の通り(Commons DBCP - Configurationより抜粋)。
Parameter Default Description
removeAbandoned false Flag to remove abandoned connections if they exceed the removeAbandonedTimout. If set to true a connection is considered abandoned and eligible for removal if it has been idle longer than the removeAbandonedTimeout. Setting this to true can recover db connections from poorly written applications which fail to close a connection.
removeAbandonedTimeout 300 Timeout in seconds before an abandoned connection can be removed.
logAbandoned false Flag to log stack traces for application code which abandoned a Statement or Connection. Logging of abandoned Statements and Connections adds overhead for every Connection open or new Statement because a stack trace has to be generated.

設定の確認

設定が有効な状態で Apache Tomcat を起動すると、起動時に下記の様なメッセージがコンソールに出力される。

AbandonedObjectPool is used (org.apache.tomcat.dbcp.dbcp.AbandonedObjectPool@5f8bae)
   LogAbandoned: true
   RemoveAbandoned: true
   RemoveAbandonedTimeout: 300

コネクションのリーク検知

コネクションのリークが検知されると、以下の様なログが出力される。

DBCP object created 2008-11-06 12:01:25 by the following code was never closed:
java.lang.Exception
  at org.apache.tomcat.dbcp.dbcp.AbandonedTrace.setStackTrace(AbandonedTrace.java:157)
  at org.apache.tomcat.dbcp.dbcp.AbandonedObjectPool.borrowObject(AbandonedObjectPool.java:76)
  at org.apache.tomcat.dbcp.dbcp.PoolingDataSource.getConnection(PoolingDataSource.java:95)
  at org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:540)
  at jp.in_vitro.myapp.MyServlet.doGet(MyServlet.java:10)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
  at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
  at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
  at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
  at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
  at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
  at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:833)
  at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:639)
  at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1285)
  at java.lang.Thread.run(Thread.java:595)

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Aug 28, 2008

[AS] Apache Tomcat Directory Traversal Vulnerability を再現してみる。

Apache Tomcat の Directory Traversal 脆弱性が報告されている。 報告だけではイマイチ分かりにくいので再現実験を行ってみた。

SecurityForcus - Apache Tomcat Directory Traversal Vulnerability
http://www.securityfocus.com/archive/1/archive/1/495318/100/0/threaded
CVE-2008-2938
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2938

脆弱性の内容

SecurityForcus によると、

As Apache Security Team, this problem occurs because of JAVA side. If your context.xml or server.xml allows 'allowLinking'and 'URIencoding' as 'UTF-8', an attacker can obtain your important system files.(e.g. /etc/passwd)

Exploit
If your webroot directory has three depth(e.g /usr/local/wwwroot), An attacker can access arbitrary files as below. (Proof-of-concept)
http://www.target.com/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/foo/bar
とのこと。allowLinking が true で且つ URIEncoding が UTF-8 に設定されている Apache Tomcat(〜6.0.16) で再現するそうだ。

allowLinking と URIEncoding

allowLinking と URIEncoding は、Apache Tomcat のドキュメントによると

Apache Tomcat Configuration Reference - The HTTP Connector
http://tomcat.apache.org/tomcat-6.0-doc/config/http.html
URIEncoding
This specifies the character encoding used to decode the URI bytes, after %xx decoding the URL. If not specified, ISO-8859-1 will be used.
Apache Tomcat Configuration Reference - The Context Container
http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
allowLinking
If the value of this flag is true, symlinks will be allowed inside the web application, pointing to resources outside the web application base path. If not specified, the default value of the flag is false.
NOTE: This flag MUST NOT be set to true on the Windows platform (or any other OS which does not have a case sensitive filesystem), as it will disable case sensitivity checks, allowing JSP source code disclosure, among other security problems.
というものだそうだ。

脆弱性の再現

Apache Tomcat 6.0.16 を使用して脆弱性の再現実験を行った。 手順は以下の通り。

  1. Apache Tomcat 6.0.16 をインストール
  2. $CATALINA_HOME/conf/server.xml を編集
  3. $CATALINA_HOME/conf/context.xml を編集
  4. Apache Tomcat 6.0.16 を起動
  5. Web ブラウザより Apache Tomcat 6.0.16 にアクセスし、脆弱性を再現
server.xml はこんな感じ
<?xml version='1.0' encoding='utf-8'?>
<Server port="8005" shutdown="SHUTDOWN">
  <Service name="Catalina">
    <Connector port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" 
               URIEncoding="UTF-8" />
  </Service>
</Server>
context.xml はこんな感じ
$CATALINA_HOME/conf/context.xml
<?xml version='1.0' encoding='utf-8'?>
<Context allowLinking="true">
</Context>
Web ブラウザで http://localhost:8080/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd にアクセスしたところ、脆弱性が再現できた。 [脆弱性が再現できた]

もう少し調べてみる

allowLinking, URIEncodign がそれぞれ設定されていない場合はどうなるか試してみた。
[allowLinkngを設定しない場合] [URIEncodingを設定しない場合]
どちらも脆弱性は再現できなかった。

URIEncoding を UTF-16 にした場合はどうなるか試してみた。
[URIEncodingをUTF-16にした場合]
脆弱性は再現できなかった。

%c0%ae って何?

脆弱性が再現できたところで一つ気になるのは、%c0%ae が何者なのか、ということ。

System.out.println("" + URLDecoder.decode("%c0%ae", "UTF-8"));
.
まぁ想像通りの結果。 要するに、http://localhost:8080/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd は Apache Tomcat 内部で http://localhost:8080/../../../../etc/passwd と解釈されるわけだ。 で、何らかの原因で(「Java 側の問題」と書いてあるが、何だろう?)パスがチェックをすり抜けてファイルアクセスに使用されてしまう、ということだろう。

結論

とにかく Apache Tomcat を脆弱性が修正されている 6.0.18 以上にバージョンアップする必要がある。 急げ。急げ。

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Jul 16, 2007

[AS] JBoss AS 4.2.0 の Windows サービス化にチャレンジ

JBoss AS 4.2.0 を Windows サービスとして登録する方法をメモ。 Getting Started with JBoss 4.0Running as a Service の情報が古く、少々戸惑ったが Java Service Wrapper を使用することで無事 JBoss AS 4.2.0 を Windows サービスとして登録できた。

Java Service Wrapper
http://wrapper.tanukisoftware.org/doc/english/integrate-simple-win.html
RunJBossAsAServiceOnWindows
http://jboss.org/wiki/Wiki.jsp?page=RunJBossAsAServiceOnWindows
Running Jboss as a Windows Service
http://www.theserverside.com/discussions/thread.tss?thread_id=21279

Java Service Wrapper を JBoss AS 4.2.0 にコピー

まず、Java Service Wrapper を %JBOSS_HOME% にコピーする。

> copy %WRAPPER_HOME%\bin\Wrapper.exe %JBOSS_HOME%\bin\
> copy %WRAPPER_HOME%\src\bin\App.bat.in %JBOSS_HOME%\bin\
> move %JBOSS_HOME%\bin\App.bat.in %JBOSS_HOME%\bin\JBoss.bat
> copy %WRAPPER_HOME%\src\bin\InstallApp-NT.bat.in %JBOSS_HOME%\bin\
> move %JBOSS_HOME%\bin\InstallApp-NT.bat.in %JBOSS_HOME%\bin\InstallJBoss-NT.bat
> copy %WRAPPER_HOME%\src\bin\UninstallApp-NT.bat.in %JBOSS_HOME%\bin\
> move %JBOSS_HOME%\bin\UninstallApp-NT.bat.in %JBOSS_HOME%\bin\UninstallJBoss-NT.bat
> copy %WRAPPER_HOME%\lib\Wrapper.DLL %JBOSS_HOME%\lib\
> copy %WRAPPER_HOME%\lib\wrapper.jar %JBOSS_HOME%\lib\
> md %JBOSS_HOME%\conf
> copy %WRAPPER_HOME%\src\conf\wrapper.conf.in %JBOSS_HOME%\conf\
> move %JBOSS_HOME%\src\conf\wrapper.conf.in %JBOSS_HOME%\conf\wrapper.conf

Java Service Wrapper の設定

%JBOSS_HOME%\conf\wrapper.conf を編集する。

#********************************************************************
# Wrapper Properties
#********************************************************************
# Java Application
wrapper.java.command=c:/jdk1.5.0_12/bin/java

# Java Main class.  This class must implement the WrapperListener interface
#  or guarantee that the WrapperManager class is initialized.  Helper
#  classes are provided to do this for you.  See the Integration section
#  of the documentation for details.
wrapper.java.mainclass=org.tanukisoftware.wrapper.WrapperSimpleApp

# Java Classpath (include wrapper.jar)  Add class path elements as
#  needed starting from 1
wrapper.java.classpath.1=c:/jboss-4.2.0.GA/lib/wrapper.jar
wrapper.java.classpath.2=c:/jdk1.5.0_12/lib/tools.jar
wrapper.java.classpath.3=./run.jar

# Java Library Path (location of Wrapper.DLL or libwrapper.so)
wrapper.java.library.path.1=c:/jboss-4.2.0.GA/lib

# Java Additional Parameters
wrapper.java.additional.1=-server

# Initial Java Heap Size (in MB)
#wrapper.java.initmemory=3

# Maximum Java Heap Size (in MB)
#wrapper.java.maxmemory=64

# Application parameters.  Add parameters as needed starting from 1
wrapper.app.parameter.1=org.jboss.Main
wrapper.app.parameter.2=-b 0.0.0.0

#********************************************************************
# Wrapper Logging Properties
#********************************************************************
# Format of output for the console.  (See docs for formats)
wrapper.console.format=PM

# Log Level for console output.  (See docs for log levels)
wrapper.console.loglevel=INFO

# Log file to use for wrapper output logging.
wrapper.logfile=c:/jboss-4.2.0.GA/server/default/log/wrapper.log

# Format of output for the log file.  (See docs for formats)
wrapper.logfile.format=LPTM

# Log Level for log file output.  (See docs for log levels)
wrapper.logfile.loglevel=INFO

# Maximum size that the log file will be allowed to grow to before
#  the log is rolled. Size is specified in bytes.  The default value
#  of 0, disables log rolling.  May abbreviate with the 'k' (kb) or
#  'm' (mb) suffix.  For example: 10m = 10 megabytes.
wrapper.logfile.maxsize=0

# Maximum number of rolled log files which will be allowed before old
#  files are deleted.  The default value of 0 implies no limit.
wrapper.logfile.maxfiles=0

# Log Level for sys/event log output.  (See docs for log levels)
wrapper.syslog.loglevel=NONE

#********************************************************************
# Wrapper Windows Properties
#********************************************************************
# Title to use when running as a console
wrapper.console.title=JBoss Server

#********************************************************************
# Wrapper Windows NT/2000/XP Service Properties
#********************************************************************
# WARNING - Do not modify any of these properties when an application
#  using this configuration file has been installed as a service.
#  Please uninstall the service before modifying this section.  The
#  service can then be reinstalled.

# Name of the service
wrapper.ntservice.name=JBoss

# Display name of the service
wrapper.ntservice.displayname=JBoss Server

# Description of the service
wrapper.ntservice.description=JBoss Server

# Service dependencies.  Add dependencies as needed starting from 1
wrapper.ntservice.dependency.1=

# Mode in which the service is installed.  AUTO_START or DEMAND_START
wrapper.ntservice.starttype=AUTO_START

# Allow the service to interact with the desktop.
wrapper.ntservice.interactive=false
Java Service Wrapper の JMX サービスを JBoss AS に登録

%JBOSS_HOME%\server\default\deploy\java-service-wrapper-service.xml を作成する。

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE server>
<server>
    <mbean code="org.tanukisoftware.wrapper.jmx.WrapperManager"
           name="JavaServiceWrapper:service=WrapperManager"/>
    
    <mbean code="org.tanukisoftware.wrapper.jmx.WrapperManagerTesting"
           name="JavaServiceWrapper:service=WrapperManagerTesting"/>
</server>

JBoss AS 4.2.0 を Windows サービスとして登録

> cd %JBOSS_HOME%\bin
> InstallJBoss-NT.bat
  

JBoss AS 4.2.0 の起動と停止

起動は下記のコマンドで行う。

> net start JBoss
停止は下記のコマンドで行う。
> net stop JBoss

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Jul 05, 2007

[AS] JBoss AS 4.2.x に外部(loopback外)からアクセスする方法

JBoss AS 4.2.x はデフォルト状態では loopback address 以外からのアクセスを受け付けない様、仕様が変更されたらしい。 loopback address 以外から接続する場合は起動時に "-b" オプションを指定する必要がある。 Release Notes には書いてあるけれど、こういう影響の大きい変更はもう少し派手に情宣して欲しいな・・・。

JBoss AS 4.2.0.GA Release Notes
http://sourceforge.net/project/shownotes.php?group_id=22866&release_id=507793
JBossAS now binds its services to localhost (127.0.0.1) *by default*, instead of binding to all available interfaces (0.0.0.0). This was primarily done for security reasons because of concerns of users going to production without having secured their servers properly. To enable remote access by binding JBoss services to a particular interface, simply run jboss with the -b option, but be aware you still need to secure you server properly.

> run.bat --help

usage: run.bat [options]

options:
    -h, --help                    Show this help message
    -V, --version                 Show version information
    --                            Stop processing options
    -D<name>[=<value>]            Set a system property
    -d, --bootdir=<dir>           Set the boot patch directory; Must be absolute or url
    -p, --patchdir=<dir>          Set the patch directory; Must be absolute or url
    -n, --netboot=<url>           Boot from net with the given url as base
    -c, --configuration=<name>    Set the server configuration name
    -B, --bootlib=<filename>      Add an extra library to the front bootclasspath
    -L, --library=<filename>      Add an extra library to the loaders classpath
    -C, --classpath=<url>         Add an extra url to the loaders classpath
    -P, --properties=<url>        Load system properties from the given url
    -b, --host=<host or ip>       Bind address for all JBoss services
    -g, --partition=<name>        HA Partition name (default=DefaultDomain)
    -u, --udp=<ip>                UDP multicast address
    -l, --log=<log4j|jdk>         Specify the logger plugin type

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Apr 29, 2006

[AS] JBoss AS のコードを読む (3)

Server 実行編

今回は Server の実行周り。

org.jboss.Main
起動用クラス。main メソッドを持つ。起動時引数の解析はここで行われている。
org.jboss.system.server.Server
Server 機能を表すインタフェース。主に Server のライフサイクルを制御するメソッドが定義されている。
org.jboss.system.server.ServerImpl
Server インタフェースのデフォルト実装。

[Server Server 実行に関係するクラス]
Server 実行に関係するクラス

[Server Server 実行時のシーケンス]
Server 実行時のシーケンス

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Apr 27, 2006

[AS] JBoss AS のコードを読む (2)

Server 初期化編

今回は Server の初期化処理周り。

org.jboss.Main
起動用クラス。main メソッドを持つ。起動時引数の解析はここで行われている。
org.jboss.system.server.Server
Server 機能を表すインタフェース。主に Server のライフサイクルを制御するメソッドが定義されている。
org.jboss.system.server.ServerImpl
Server インタフェースのデフォルト実装。
org.jboss.system.server.ServerConfig
Server の設定項目を表すインタフェース。
org.jboss.system.server.ServerConfigImpl
ServerConfig インタフェースのデフォルト実装。

[Server 初期化に関係するクラス]
Server 初期化に関係するクラス

[Server 初期化時のシーケンス]
Server 初期化時のシーケンス

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Apr 26, 2006

[AS] JBoss AS のコードを読む (1)

以前から JBoss のコードを読んでみたいと思っていた。 ただ Application Server という規模の大きなコードを読む面倒さから、なかなか着手する気にならなかった。 今回、とりあえずどこまで続くか分からないが、着手だけはしてみることに。 読みやすい順番で少しずつ、のんびりと読んで行きたいと思う。

起動編

まずは main メソッド実行から Server#start が呼ばれるところ辺りまで。

org.jboss.Main
起動用クラス。main メソッドを持つ。起動時引数の解析はここで行われている。
org.jboss.system.server.ServerLoader
Server インスタンスを生成するファクトリクラス。
org.jboss.system.server.Server
Server 機能を表すインタフェース。主に Server のライフサイクルを制御するメソッドが定義されている。
org.jboss.system.server.ServerImpl
Server インタフェースのデフォルト実装。
org.jboss.system.server.NoAnnotationURLClassLoader
URLClassLoader の拡張。何故拡張が必要かは知らない。

[起動時処理に関係するクラス]
起動時処理に関係するクラス

[起動時のシーケンス]
起動時のシーケンス

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Apr 12, 2006

[AS] Apache Web Server 2、lighttpd、JBossWeb のパフォーマンス比較

JBossWeb のパフォーマンス感が知りたくて、大雑把なパフォーマンス比較をしてみた。 それぞれインストールしただけの Apache Web Server 2、JBossWeb に JMeter で負荷をかけてみた。 また、ついでに lighttpd も試してみた。

テスト環境

  • Debian Sarge on VMWare Player
  • Kernel 2.6.8-2-386

テスト方法

  1. 各サーバのドキュメントルートに以下の "index.html" を作成する。
    <html>
    <head>
      <title>dummy page</title>
    </head>
    <body>
      This is a dummy page.
    </body>
    </html>
    
  2. JMeter で 1000 回程度 "/index.html" を GET する。(このときの結果は無視)
  3. JMeter でスレッド数 10、20、30、40、50 の状態で "/index.html" を 1000 回 GET し、パフォーマンスを計測する。

テスト結果

Apache Web Server 2

# /usr/sbin/apache2 -v
Server version: Apache/2.0.54
Server built:   Sep  5 2005 11:11:08
スレッド数 Samples Average Median 90% Line Min Max Error % Throughput KB/sec
10 10000 9 0 16 0 1734 0.00% 824.7/sec 78.93
20 20000 18 15 31 0 3562 0.00% 859.7/sec 82.27
30 30000 28 16 32 0 3609 0.00% 913.0/sec 87.38
40 40000 35 15 47 0 11078 0.00% 815.0/sec 78.00
50 50000 48 16 78 0 12218 0.00% 810.3/sec 77.55

lighttpd

# /usr/sbin/lighttpd -v
lighttpd-1.4.11 (ssl) - a light and fast webserver
Build-Date: Mar 27 2006 09:56:59
スレッド数 Samples Average Median 90% Line Min Max Error % Throughput KB/sec
10 10000 5 0 16 0 485 0.00% 1406.7/sec 134.62
20 20000 15 16 31 0 235 0.00% 1175.4/sec 112.49
30 30000 23 16 47 0 313 0.00% 1209.1/sec 115.71
40 40000 32 31 62 0 204 0.01% 1151.6/sec 110.32
50 50000 41 47 63 0 297 0.01% 1140.8/sec 109.27

Apache Web Server 2

# ./run.sh --version
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /opt/jbossweb

  JAVA: /opt/jdk15/bin/java

  JAVA_OPTS: -server -Xms128m -Xmx128m -Dprogram.name=run.sh

  CLASSPATH: /opt/jbossweb/bin/run.jar:/opt/jdk15/lib/tools.jar

=========================================================================

JBoss 4.0.4RC1 (build: CVSTag=JBoss_4_0_4_RC1 date=200602071519)

Distributable under LGPL license.
See terms of license at gnu.org.
スレッド数 Samples Average Median 90% Line Min Max Error % Throughput KB/sec
10 10000 10 0 16 0 625 0.00% 856.8/sec 81.99
20 20000 21 0 16 0 12984 0.00% 817.9/sec 78.27
30 30000 32 15 31 0 13750 0.00% 763.7/sec 73.09
40 40000 48 15 62 0 6703 0.00% 739.0/sec 70.73
50 50000 59 16 94 0 12922 0.00% 750.1/sec 71.79

Apache Tomcat 5.5

Apache Tomcat 5.5.16 の計測結果を以下に示す。

スレッド数 Samples Average Median 90% Line Min Max Error % Throughput KB/sec
10 10000 8 0 16 0 562 0.00% 959.5/sec 91.83
20 20000 19 0 16 0 10844 0.00% 888.9/sec 85.07
30 30000 28 0 16 0 20766 0.00% 901.0/sec 86.23
40 40000 36 0 16 0 8953 0.00% 886.4/sec 84.83
50 50000 51 0 16 0 12844 0.00% 866.7/sec 82.95

まとめ

未チューニング状態では、JBossWeb のパフォーマンスは Apache Web Server 2 より多少遅いレベルの様だ。 当然ながら Apache Tomcat とも大差ない結果となっている。 それにしても、lighttpd は light と銘打つだけあって流石に速い。 それにしても、Apache Web Server 2 が JBossWeb や Apache Tomcat と同等だったのが意外だった。 もう少し速いイメージがあったのだけれど。

[Throughput]
[KB/sec]

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |

Apr 11, 2006

[AS] JBossWeb にチャレンジ

JBossWeb とは

JBossWeb は、JBoss AS をシンプルにして Web サーバ機能のみを残したもの。 要するに「ほぼ」Apache Tomcat ということだろう。 当然 Servlet や JSP の動作環境も提供される。

JBossWeb
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.info&project=jbossweb
JBossWeb Download
http://labs.jboss.com/portal/index.html?ctrl:id=page.default.downloads&project=jbossweb

JBossWeb のインストール

Debian Sarge 上に JBossWeb をインストールしたときのメモ。

  1. こちらから JBossWeb のバイナリをダウンロードする。ここでは jbossweb-4.0.4RC1-linux-i686.tar.gz を前提とする。
  2. アーカイブを解凍して、適当な位置に配置する。
    # tar zxvf ./jbossweb-4.0.4RC1-linux-i686.tar.gz
    # mv ./jbossweb-4.0.4RC1-linux-i686 /opt
    # ln -s /opt/jbossweb-4.0.4RC1-linux-i686 /opt/jbossweb
    
  3. シェルスクリプトのパーミッションを変更する。
    # chmod 755 /opt/jbossweb/bin/*.sh
    
  4. Java の動作環境を設定する。
    # export JAVA_HOME=/opt/jdk15
    # export PATH=$JAVA_HOME/bin:$PATH
    # java -version
    java version "1.5.0_05"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
    Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
    
  5. 必要に応じてサーバの設定を変更する。 例えば、HTTP のポートを変更する場合は /opt/jbossweb/server/default/deploy/jbossweb.sar/server.xml を変更する。
  6. 起動する。
    # cd /opt/jbossweb/bin
    # ./run.sh
    

Posted in AS | このエントリーをはてなブックマークに追加 | この記事をクリップ! livedoor クリップ |