bananan_wの日記： 英語勉強日記#11(翻訳がんばろう日記)
日記 by
bananan_w
17章。
17. Help! My boss wants me to load test our web app!
17. 助けて!上司にウェブアプリケーションの負荷試験を行うように指示されました!
This is a fairly open-ended proposition. There are a number of questions to be asked first, and additionally a number of resources that will be needed. You will need some hardware to run the benchmarks/load-tests from. A number of tools will prove useful. There are a number of products to consider. And finally, why is Java a good choice to implement a load-testing/Benchmarking product.
これは実に制限の存在しない議題です。初めに確認する多数の質問があり、どれだけのリソースが必要とされているか。また、ベンチマークや負荷テストを実施するにはいくつかのハードウェアが必要になるでしょう。いくつかのプロダクトに別れている、いくつもの便利なツールの存在に気がつくでしょう。そして最終的には、負荷テストやベンチマークプロダクトの実装の選択に何故Javaが優れた選択であるのかを理解するでしょう。
17.1 Questions to ask
17.1 質問と回答
What is our anticipated average number of users (normal load) ?
予想されるユーザの平均数はいくつでしょうか(平常負荷)？
What is our anticipated peak number of users ?
予想される最大ユーザ数はいくつでしょうか？
When is a good time to load-test our application (i.e. off-hours or week-ends), bearing in mind that this may very well crash one or more of our servers ?
アプリケーションに負荷を掛けるのに適切な時間(例えば、休みの時間か週末)はいつですか。これはサーバのクラッシュを頻繁に引き起こす事を心に留めておいてください。
Does our application have state ? If so, how does our application manage it (cookies, session-rewriting, or some other method) ?
アプリケーションは状態を保持しますか？保持するのならアプリケーションはどのようにして状態を管理していますか(クッキー、セッションリライト、又は他の方法)？
What is the testing intended to achieve?
テストを実施する代わりにアーカイブを参照できませんか？
17.2 Resources
17.2 リソース
The following resources will prove very helpful. Bear in mind that if you cannot locate these resources, you will become these resources. As you already have your work cut out for you, it is worth knowing who the following people are, so that you can ask them for help if you need it.
以下のリソースは大変役に立っていると判断できるでしょう。それらのリソースが存在しない場合には、これらのリソースになる事を忘れないでください(約注:意味不明。。。)。既に仕事が開始されている場合には、以下の人のうち誰がどの仕事を行っているか把握する必要があります。必要に応じて彼らに問い合わせを行うことは手助けとなるでしょう。
17.2.1 Network
17.2.1 ネットワーク
Who knows our network topology ? If you run into any firewall or proxy issues, this will become very important. As well, a private testing network (which will therefore have very low network latency) would be a very nice thing. Knowing who can set one up for you (if you feel that this is necessary) will be very useful. If the application doesn't scale as expected, who can add additional hardware ?
ネットワークとポロジを誰が把握していますか？ネットワークかプロキシのいずれかを経由して試験を実施する場合、これは大変重要なことです。テスト用の特別なネットワーク(それゆえにネットワークレイテンシが大変低いでしょう)では良好な成果を得るでしょう。誰が上記を設定できるか(これが重要だと考えているなら)知っているならとても便利でしょう。アプリケーションの性能が望んだ水準に達しない場合には、誰がハードウェアを追加できますか？
17.2.2 Application
17.2.2 アプリケーション
Who knows how our application functions ? The normal sequence is
アプリケーションの機能を誰が把握していますか？通常は以下の通りです。
* test (low-volume - can we benchmark our application?)
* benchmark (the average number of users)
* load-test (the maximum number of users)
* test destructively (what is our hard limit?)
* テスト(小規模 - アプリケーションのベンチマークを実施できるか？)
* ベンチマーク(平均ユーザ数)
* 負荷試験(最大ユーザ数)
* 破壊的テスト(ハードウェアの限界の調査)
The test process may progress from black-box testing to white-box testing (the difference is that the first requires no knowledge of the application [it is treated as a "black box"] while the second requires some knowledge of the application). It is not uncommon to discover problems with the application during this process, so be prepared to defend your work.
テスト過程はブラックボックステストからホワイトボックステストへ前進する(異なる点はアプリケーションの初めのリクエストに対する知識はありません["ブラックボックス"の様に処理された]が、二つ目のリクエストはいくつかのアプリケーションに対する知識があることです)様なものです。この過程ではアプリケーションの問題を発見することは良くあり、仕事の一つとして事前に組み込まれているべきです。
17.3 What platform should I use to run the benchmarks/load-tests ?
17.3 ベンチマークや負荷試験をどのプラットフォームで実施すべきですか？
This should be a widely-used piece of hardware, with a standard (i.e. vanilla) software installation. Remember, if you publish your results, the first thing your clients will do is hire a graduate student to verify them. You might as well make it as easy for this person as you possibly can.
これはハードウェアに強く依存し、標準的な(吊しの)ソフトウェアをインストールするべきです。テスト結果を公表する場合、クライアントが最初にすることは大学院生を雇って検証することです。これをより簡単に実施させることが望ましいです。
For Windows, Windows XP Professional should be a minimum (the others do not multi-thread past 50-60 connections, and you probably anticipate more users than that).
Windowsでは、Windows XP Professionalが最小要求です(それ以外はマルチスレッドで50-60接続ユーザを越える接続を処理しきれないでしょう)。
Good free platforms include the linuxes, the BSDs, and Solaris Intel. If you have a little more money, there are commercial linuxes. If you can justify it, a commercial Unix (Solaris, etc) is probably the best choice.
優秀な無料のプラットフォームにはLinux、BSD一族、Intel Solarisがあります。もし小金持ちであるなら、商用Linuxも存在します。それらに納得できない場合には、商用Unix(Solaris、その他)がおそらく最善の選択となります。
For non-Windows platforms, investigate "ulimit -n unlimited" with a view to including it in your user account startup scripts (.bashrc or .cshrc scripts for the testing account).
Windows以外のプラットフォームにおいて、"ulimit -n unlimited"をユーザアカウントのスタートアップスクリプトに含めるかどうか吟味してください(テスト実施アカウントの.bashrcか.cshrcスクリプトにおいて)。
As you progress to larger-scale benchmarks/load-tests, this platform will become the limiting factor. So it's worth using the best hardware and software that you have available. Remember to include the hardware/software configuration in your published benchmarks.
巨大なベンチマークや負荷試験を進める場合には、これらのプラットフォームでは性能のボトルネックとなります。有用な結果を得るためには最良のハードウェアとソフトウェアを使用する価値があります。ハードウェアとソフトウェアの設定も含めてベンチマーク結果を公表することを忘れないでください。
Don't forget JMeter batch mode. This can be useful if you have a powerful server that supports Java but perhaps does not have a fast graphics implementation, or where you need to login remotely. Batch (non-GUI) mode can reduce the network traffic compared with using a remote display or client-server mode. The batch log file can then be loaded into JMeter on a workstation for analysis, or you can use CSV output and import the data into a spreadsheet.
JMeterのバッチモードを忘れないでください。Javaをサポートする強力であるが高速なグラフィック性能をもっていない場合や、リモートログインする必要がある場合にとても便利です。バッチ(non-GUI)モードはリモートディスプレイから結果を確認したり、クライアントサーバモードで動作させるネットワークトラフィックを削減できます。バッチログファイルはワークステーションで動作するJMeterの実行結果を解析でき、また、CSV出力をさせ表計算ソフトから読み込むことができます。
17.4 Tools
17.4 ツール
The following tools will all prove useful. It is definitely worthwhile to become familiar with them. This should include trying them out, and reading the appropriate documentation (man-pages, info-files, application --help messages, and any supplied documentation).
いかのツールはどれも便利なものです。これらは間違いなく使いこなす価値があります。それらを十分に試すべきで、適切な文書(manページ、infoファイル、application --helpメッセージ、その他提供される文書)を読むべきです。
17.4.1 ping
17.4.1 ping
This can be used to establish whether or not you can reach your target site. Options can be specified so that 'ping' provides the same type of route reporting as 'traceroute'.
これはターゲットサイトに到達可能かを調査します。オプションを指定できるので'pingは'traceroute'と同様のルートレポートを提供します。
17.4.2 nslookup/dig
17.4.2 nslookup/dig
While the user will normally use a human-readable internet address, you may wish to avoid the overhead of DNS lookups when performing benchmarking/load-testing. These can be used to determine the unique address (dotted quad) of your target site.
通常、ユーザは人間が読むことのできるインターネットアドレスを使用しますが、ベンチマークや負荷試験の性能からDNS検索のオーバヘッドを取り除きたいと思うかもしれません。これはユニークアドレス(ドット4つの)をターゲットサイトに指定して実現できます。
17.4.3 traceroute
17.4.3 traceroute
If you cannot "ping" your target site, this may be used to determine the problem (possibly a firewall or a proxy). It can also be used to estimate the overall network latency (running locally should give the lowest possible network latency - remember that your users will be running over a possibly busy internet). Generally, the fewer hops the better.
ターゲットサイトに"ping"が実行できない場合、これを使用すると問題（ファイアウォールかプロキシ要因のもの)を洗い出せるかもしれません。これは全てのネットワークレイテンシを計測することに使用されます(ローカルでの実行は最も低いレイテンシを得ます - ユーザは混雑しているインターネット経由でアクセスすることを忘れないでください)。通常、少ないホップ数であることが望ましいです。
17.5 What other products are there ?
17.5 他にはどのような製品がありますか？
There are a number of commercial products, which generally have fairly hefty pricetags. If you can justify it, these are probably the way to go. If, however, these products do not do exactly what you want, or you are on a limited budget, the following are worth a look. In fact, you should probably start by trying the Apache ab tool, as it may very well do the job if your requirements are not particularly complicated.
いくつもの商用製品があり、かなり高額な値札が通常付けられています。それについて納得できるなら購入するといいでしょう。ですが、それらの製品が望んだ機能を実装していない場合や、予算の制限が存在する場合には、以下は見る価値があります。実際には、要求は複雑で入り組んだものではないことが多いため、Apache abツールの様なものを試すことで要求は満たされるでしょう。
17.5.1 Apache 'ab' tool
17.5.1 Apache 'ab'ツール
You should definitely start with this one. It handles HTTP 'get' requests very well, and can be made to handle HTTP 'post' requests with a little effort. Written in 'C', it performs very well, and offers good (if basic) performance reporting.
確実にこれから取り掛かるべきです。これはHTTPの'get'リクエストを確実に処理し、HTTP 'post'リクエストを多少の努力で確実に処理できます。'C'で書かれ、性能は非常に高く、優秀な(基本的で構わないなら)性能レポートを提供します。
17.5.2 HttpUnit
17.5.2 HttpUnit
This is worth a look. It is a library (and therefore of more interest to developers) that can be used to perform HTTP tests/benchmarks. It is intended to be used instead of a web browser (therefore no GUI) in conjunction with JUnit .
これは見る価値があります。これはライブラリ(従って開発者により関心をもたれます)でHTTPテストやベンチマークを実施できます。JUnitと連係してウェブブラウザの代わりになることを意図しています(従ってGUIを持ちません)。
17.5.3 Microsoft WAS
17.5.3 Microsoft WAS
This is definitely worth a look. It has an excellent user interface but it may not do exactly what you want. If this is the case, be aware that the functionality of this product is not likely to change.
これは間違いなく見る価値があります。華麗なユーザインタフェースを持ちますが、望む機能はおそらく持っていないでしょう。この場合には、この製品の機能は変更されないことを認識してください。
17.5.4 JMeter
17.5.4 JMeter
If you have non-standard requirements, then this solution offers an open-source community to provide them (of course, if you are reading this , you are probably already committed to this one). This product is free to evolve along with your requirements.
非標準的な要求がある場合には、オープンソースコミュニティによって提供されるJMeterが解決方法を提示します(もちろん、このドキュメントを読んでいるなら、既にJMeterを選択しているはずです)。このプロダクトはあなたの要求とともに自由に発展します。
17.6 Why Java ?
17.6 何故Javaなの？
Why not Perl or C ?
何故PerlやCではないのですか？
Well, Perl might be a very good choice except that the Benchmark package seems to give fairly fuzzy results. Also, simulating multiple users with Perl is a tricky proposition (multiple connections can be simulated by forking many processes from a shell script, but these will not be threads, they will be processes). However, the Perl community is very large. If you find that someone has already written something that seems useful, this could be a very good solution.
Benchmarkパッケージがかなり不明瞭な結果を返すこと以外はPerlを選択することはとても良い選択です。複数ユーザをPerlでシミュレートするには厄介な手段(シェルスクリプトから複数のプロセスをフォークして複数の接続をシミュレートすることは、スレッドではなくプロセスです)が必要です。しかしながら、Perlコミュニティは非常に巨大です。もし誰かが既に便利なものを作成しているなら、それは良い手段と言えます。
C, of course, is a very good choice (check out the Apache ab tool). But be prepared to write all of the custom networking, threading, and state management code that you will need to benchmark your application.
Cはもちろんとても良い選択です(Apache abツールに見られる通り)。しかしベンチマークアプリケーションに関するネットワーク、スレッド、状態管理の全てのコードを記述して準備しなければなりません。
Java gives you (for free) the custom networking, threading, and state management code that you will need to benchmark your application. Java is aware of HTTP, FTP, and HTTPS - as well as RMI, IIOP, and JDBC (not to mention cookies, URL-encoding, and URL-rewriting). In addition Java gives you automatic garbage-collection, and byte-code level security.
ベンチマークアプリケーションで必要になる(無料の)ネットワーク、スレッド、状態管理コードがJavaには存在します。JavaはHTTP、FTP、HTTPSに関する処理方式を組み込まれています - また、RMI、IIOP、JDBC(クッキー、URLエンコーディング、URLリライティングに関しては除きます)も同じく組み込まれています。更にJavaは自動ガベージコレクションとバイトコードレベルのセキュリティを提供します。
And once Microsoft moves to a CLR (common language run-time) a Windows Java solution will not be any slower than any other type of solution on the Windows platform.
MicrosoftがWindowsのJavaソリューションをCLR(common language run-time)へ移行させると、その他のWindowsプラットフォーム上のソリューションより遅くなることはなくなるでしょう。
17. Help! My boss wants me to load test our web app!
17. 助けて!上司にウェブアプリケーションの負荷試験を行うように指示されました!
This is a fairly open-ended proposition. There are a number of questions to be asked first, and additionally a number of resources that will be needed. You will need some hardware to run the benchmarks/load-tests from. A number of tools will prove useful. There are a number of products to consider. And finally, why is Java a good choice to implement a load-testing/Benchmarking product.
これは実に制限の存在しない議題です。初めに確認する多数の質問があり、どれだけのリソースが必要とされているか。また、ベンチマークや負荷テストを実施するにはいくつかのハードウェアが必要になるでしょう。いくつかのプロダクトに別れている、いくつもの便利なツールの存在に気がつくでしょう。そして最終的には、負荷テストやベンチマークプロダクトの実装の選択に何故Javaが優れた選択であるのかを理解するでしょう。
17.1 Questions to ask
17.1 質問と回答
What is our anticipated average number of users (normal load) ?
予想されるユーザの平均数はいくつでしょうか(平常負荷)？
What is our anticipated peak number of users ?
予想される最大ユーザ数はいくつでしょうか？
When is a good time to load-test our application (i.e. off-hours or week-ends), bearing in mind that this may very well crash one or more of our servers ?
アプリケーションに負荷を掛けるのに適切な時間(例えば、休みの時間か週末)はいつですか。これはサーバのクラッシュを頻繁に引き起こす事を心に留めておいてください。
Does our application have state ? If so, how does our application manage it (cookies, session-rewriting, or some other method) ?
アプリケーションは状態を保持しますか？保持するのならアプリケーションはどのようにして状態を管理していますか(クッキー、セッションリライト、又は他の方法)？
What is the testing intended to achieve?
テストを実施する代わりにアーカイブを参照できませんか？
17.2 Resources
17.2 リソース
The following resources will prove very helpful. Bear in mind that if you cannot locate these resources, you will become these resources. As you already have your work cut out for you, it is worth knowing who the following people are, so that you can ask them for help if you need it.
以下のリソースは大変役に立っていると判断できるでしょう。それらのリソースが存在しない場合には、これらのリソースになる事を忘れないでください(約注:意味不明。。。)。既に仕事が開始されている場合には、以下の人のうち誰がどの仕事を行っているか把握する必要があります。必要に応じて彼らに問い合わせを行うことは手助けとなるでしょう。
17.2.1 Network
17.2.1 ネットワーク
Who knows our network topology ? If you run into any firewall or proxy issues, this will become very important. As well, a private testing network (which will therefore have very low network latency) would be a very nice thing. Knowing who can set one up for you (if you feel that this is necessary) will be very useful. If the application doesn't scale as expected, who can add additional hardware ?
ネットワークとポロジを誰が把握していますか？ネットワークかプロキシのいずれかを経由して試験を実施する場合、これは大変重要なことです。テスト用の特別なネットワーク(それゆえにネットワークレイテンシが大変低いでしょう)では良好な成果を得るでしょう。誰が上記を設定できるか(これが重要だと考えているなら)知っているならとても便利でしょう。アプリケーションの性能が望んだ水準に達しない場合には、誰がハードウェアを追加できますか？
17.2.2 Application
17.2.2 アプリケーション
Who knows how our application functions ? The normal sequence is
アプリケーションの機能を誰が把握していますか？通常は以下の通りです。
* test (low-volume - can we benchmark our application?)
* benchmark (the average number of users)
* load-test (the maximum number of users)
* test destructively (what is our hard limit?)
* テスト(小規模 - アプリケーションのベンチマークを実施できるか？)
* ベンチマーク(平均ユーザ数)
* 負荷試験(最大ユーザ数)
* 破壊的テスト(ハードウェアの限界の調査)
The test process may progress from black-box testing to white-box testing (the difference is that the first requires no knowledge of the application [it is treated as a "black box"] while the second requires some knowledge of the application). It is not uncommon to discover problems with the application during this process, so be prepared to defend your work.
テスト過程はブラックボックステストからホワイトボックステストへ前進する(異なる点はアプリケーションの初めのリクエストに対する知識はありません["ブラックボックス"の様に処理された]が、二つ目のリクエストはいくつかのアプリケーションに対する知識があることです)様なものです。この過程ではアプリケーションの問題を発見することは良くあり、仕事の一つとして事前に組み込まれているべきです。
17.3 What platform should I use to run the benchmarks/load-tests ?
17.3 ベンチマークや負荷試験をどのプラットフォームで実施すべきですか？
This should be a widely-used piece of hardware, with a standard (i.e. vanilla) software installation. Remember, if you publish your results, the first thing your clients will do is hire a graduate student to verify them. You might as well make it as easy for this person as you possibly can.
これはハードウェアに強く依存し、標準的な(吊しの)ソフトウェアをインストールするべきです。テスト結果を公表する場合、クライアントが最初にすることは大学院生を雇って検証することです。これをより簡単に実施させることが望ましいです。
For Windows, Windows XP Professional should be a minimum (the others do not multi-thread past 50-60 connections, and you probably anticipate more users than that).
Windowsでは、Windows XP Professionalが最小要求です(それ以外はマルチスレッドで50-60接続ユーザを越える接続を処理しきれないでしょう)。
Good free platforms include the linuxes, the BSDs, and Solaris Intel. If you have a little more money, there are commercial linuxes. If you can justify it, a commercial Unix (Solaris, etc) is probably the best choice.
優秀な無料のプラットフォームにはLinux、BSD一族、Intel Solarisがあります。もし小金持ちであるなら、商用Linuxも存在します。それらに納得できない場合には、商用Unix(Solaris、その他)がおそらく最善の選択となります。
For non-Windows platforms, investigate "ulimit -n unlimited" with a view to including it in your user account startup scripts (.bashrc or .cshrc scripts for the testing account).
Windows以外のプラットフォームにおいて、"ulimit -n unlimited"をユーザアカウントのスタートアップスクリプトに含めるかどうか吟味してください(テスト実施アカウントの.bashrcか.cshrcスクリプトにおいて)。
As you progress to larger-scale benchmarks/load-tests, this platform will become the limiting factor. So it's worth using the best hardware and software that you have available. Remember to include the hardware/software configuration in your published benchmarks.
巨大なベンチマークや負荷試験を進める場合には、これらのプラットフォームでは性能のボトルネックとなります。有用な結果を得るためには最良のハードウェアとソフトウェアを使用する価値があります。ハードウェアとソフトウェアの設定も含めてベンチマーク結果を公表することを忘れないでください。
Don't forget JMeter batch mode. This can be useful if you have a powerful server that supports Java but perhaps does not have a fast graphics implementation, or where you need to login remotely. Batch (non-GUI) mode can reduce the network traffic compared with using a remote display or client-server mode. The batch log file can then be loaded into JMeter on a workstation for analysis, or you can use CSV output and import the data into a spreadsheet.
JMeterのバッチモードを忘れないでください。Javaをサポートする強力であるが高速なグラフィック性能をもっていない場合や、リモートログインする必要がある場合にとても便利です。バッチ(non-GUI)モードはリモートディスプレイから結果を確認したり、クライアントサーバモードで動作させるネットワークトラフィックを削減できます。バッチログファイルはワークステーションで動作するJMeterの実行結果を解析でき、また、CSV出力をさせ表計算ソフトから読み込むことができます。
17.4 Tools
17.4 ツール
The following tools will all prove useful. It is definitely worthwhile to become familiar with them. This should include trying them out, and reading the appropriate documentation (man-pages, info-files, application --help messages, and any supplied documentation).
いかのツールはどれも便利なものです。これらは間違いなく使いこなす価値があります。それらを十分に試すべきで、適切な文書(manページ、infoファイル、application --helpメッセージ、その他提供される文書)を読むべきです。
17.4.1 ping
17.4.1 ping
This can be used to establish whether or not you can reach your target site. Options can be specified so that 'ping' provides the same type of route reporting as 'traceroute'.
これはターゲットサイトに到達可能かを調査します。オプションを指定できるので'pingは'traceroute'と同様のルートレポートを提供します。
17.4.2 nslookup/dig
17.4.2 nslookup/dig
While the user will normally use a human-readable internet address, you may wish to avoid the overhead of DNS lookups when performing benchmarking/load-testing. These can be used to determine the unique address (dotted quad) of your target site.
通常、ユーザは人間が読むことのできるインターネットアドレスを使用しますが、ベンチマークや負荷試験の性能からDNS検索のオーバヘッドを取り除きたいと思うかもしれません。これはユニークアドレス(ドット4つの)をターゲットサイトに指定して実現できます。
17.4.3 traceroute
17.4.3 traceroute
If you cannot "ping" your target site, this may be used to determine the problem (possibly a firewall or a proxy). It can also be used to estimate the overall network latency (running locally should give the lowest possible network latency - remember that your users will be running over a possibly busy internet). Generally, the fewer hops the better.
ターゲットサイトに"ping"が実行できない場合、これを使用すると問題（ファイアウォールかプロキシ要因のもの)を洗い出せるかもしれません。これは全てのネットワークレイテンシを計測することに使用されます(ローカルでの実行は最も低いレイテンシを得ます - ユーザは混雑しているインターネット経由でアクセスすることを忘れないでください)。通常、少ないホップ数であることが望ましいです。
17.5 What other products are there ?
17.5 他にはどのような製品がありますか？
There are a number of commercial products, which generally have fairly hefty pricetags. If you can justify it, these are probably the way to go. If, however, these products do not do exactly what you want, or you are on a limited budget, the following are worth a look. In fact, you should probably start by trying the Apache ab tool, as it may very well do the job if your requirements are not particularly complicated.
いくつもの商用製品があり、かなり高額な値札が通常付けられています。それについて納得できるなら購入するといいでしょう。ですが、それらの製品が望んだ機能を実装していない場合や、予算の制限が存在する場合には、以下は見る価値があります。実際には、要求は複雑で入り組んだものではないことが多いため、Apache abツールの様なものを試すことで要求は満たされるでしょう。
17.5.1 Apache 'ab' tool
17.5.1 Apache 'ab'ツール
You should definitely start with this one. It handles HTTP 'get' requests very well, and can be made to handle HTTP 'post' requests with a little effort. Written in 'C', it performs very well, and offers good (if basic) performance reporting.
確実にこれから取り掛かるべきです。これはHTTPの'get'リクエストを確実に処理し、HTTP 'post'リクエストを多少の努力で確実に処理できます。'C'で書かれ、性能は非常に高く、優秀な(基本的で構わないなら)性能レポートを提供します。
17.5.2 HttpUnit
17.5.2 HttpUnit
This is worth a look. It is a library (and therefore of more interest to developers) that can be used to perform HTTP tests/benchmarks. It is intended to be used instead of a web browser (therefore no GUI) in conjunction with JUnit .
これは見る価値があります。これはライブラリ(従って開発者により関心をもたれます)でHTTPテストやベンチマークを実施できます。JUnitと連係してウェブブラウザの代わりになることを意図しています(従ってGUIを持ちません)。
17.5.3 Microsoft WAS
17.5.3 Microsoft WAS
This is definitely worth a look. It has an excellent user interface but it may not do exactly what you want. If this is the case, be aware that the functionality of this product is not likely to change.
これは間違いなく見る価値があります。華麗なユーザインタフェースを持ちますが、望む機能はおそらく持っていないでしょう。この場合には、この製品の機能は変更されないことを認識してください。
17.5.4 JMeter
17.5.4 JMeter
If you have non-standard requirements, then this solution offers an open-source community to provide them (of course, if you are reading this , you are probably already committed to this one). This product is free to evolve along with your requirements.
非標準的な要求がある場合には、オープンソースコミュニティによって提供されるJMeterが解決方法を提示します(もちろん、このドキュメントを読んでいるなら、既にJMeterを選択しているはずです)。このプロダクトはあなたの要求とともに自由に発展します。
17.6 Why Java ?
17.6 何故Javaなの？
Why not Perl or C ?
何故PerlやCではないのですか？
Well, Perl might be a very good choice except that the Benchmark package seems to give fairly fuzzy results. Also, simulating multiple users with Perl is a tricky proposition (multiple connections can be simulated by forking many processes from a shell script, but these will not be threads, they will be processes). However, the Perl community is very large. If you find that someone has already written something that seems useful, this could be a very good solution.
Benchmarkパッケージがかなり不明瞭な結果を返すこと以外はPerlを選択することはとても良い選択です。複数ユーザをPerlでシミュレートするには厄介な手段(シェルスクリプトから複数のプロセスをフォークして複数の接続をシミュレートすることは、スレッドではなくプロセスです)が必要です。しかしながら、Perlコミュニティは非常に巨大です。もし誰かが既に便利なものを作成しているなら、それは良い手段と言えます。
C, of course, is a very good choice (check out the Apache ab tool). But be prepared to write all of the custom networking, threading, and state management code that you will need to benchmark your application.
Cはもちろんとても良い選択です(Apache abツールに見られる通り)。しかしベンチマークアプリケーションに関するネットワーク、スレッド、状態管理の全てのコードを記述して準備しなければなりません。
Java gives you (for free) the custom networking, threading, and state management code that you will need to benchmark your application. Java is aware of HTTP, FTP, and HTTPS - as well as RMI, IIOP, and JDBC (not to mention cookies, URL-encoding, and URL-rewriting). In addition Java gives you automatic garbage-collection, and byte-code level security.
ベンチマークアプリケーションで必要になる(無料の)ネットワーク、スレッド、状態管理コードがJavaには存在します。JavaはHTTP、FTP、HTTPSに関する処理方式を組み込まれています - また、RMI、IIOP、JDBC(クッキー、URLエンコーディング、URLリライティングに関しては除きます)も同じく組み込まれています。更にJavaは自動ガベージコレクションとバイトコードレベルのセキュリティを提供します。
And once Microsoft moves to a CLR (common language run-time) a Windows Java solution will not be any slower than any other type of solution on the Windows platform.
MicrosoftがWindowsのJavaソリューションをCLR(common language run-time)へ移行させると、その他のWindowsプラットフォーム上のソリューションより遅くなることはなくなるでしょう。
英語勉強日記#11(翻訳がんばろう日記) More ログイン