究極のウェブサーバーベンチマーク:Apache、NGINX、LiteSpeed、OpenLiteSpeed、Caddy & Lighttpd の比較
適切なウェブサーバーを選ぶことは、ウェブサイトのパフォーマンスを左右します。多くの選択肢がある中で Apache、NGINX、LiteSpeed、OpenLiteSpeed、Caddy、Lighttpd 、どれが最も速く、最も効率的で、あなたのニーズに最適かをどうやって知ることができますか?
確認するために、私たちは包括的なベンチマークを実施し、これらの6つの人気ウェブサーバーを、静的ファイル処理、高い同時接続、大きなファイルのダウンロード、持続的なトラフィックシミュレーションなどの異なる条件下でテストしました。私たちの目標は?速度、リソース使用量、信頼性の点で最も優れたパフォーマンスを示すサーバーを特定することです。
この記事では、次のことについて説明します。
- ベンチマーキングのセットアップ(ハードウェア、構成、テスト方法論)。
- 複数のテストシナリオにわたる詳細な性能比較。
- CPUおよびRAMの効率分析。
- 異なる負荷条件下でのレイテンシトレンド。
- 異なる使用ケースに最適なウェブサーバーに関する最終的な推奨事項。
さて、どのウェブサーバーがトップに立ったのでしょうか?結果を見てみましょう!
上のチャートは、すべてのテストでのトップパフォーマンスのウェブサーバーを強調しています。NGINXとOpenLiteSpeedは一貫して最良の結果を提供し、LiteSpeed、Lighttpd、Caddyがそれに続きました。Apacheは最低のパフォーマンスを示し、特に高同時接続および持続的負荷テストにおいて顕著でした。
レイテンシ比較
スループットは重要ですが、低レイテンシはユーザーにとっての迅速な応答時間を保証します。Lighttpdは最も低いレイテンシを持っており、そのためWebコンテンツを最も迅速に配信することができます。NGINXとOpenLiteSpeedも十分に性能を発揮しましたが、Apacheは最高のレイテンシを持ち、高い同時処理に苦しんでいることを強調しています。
次は何ですか?
結果の全体的な概要が把握できたので、各テストを詳細に掘り下げ、これらのウェブサーバーが特定の条件と負荷の下でどのように動作したかを分析しましょう。
テスト1: 静的ファイル処理
テストの目的
静的ファイルの処理は、どのウェブサーバーにとっても基本的な作業です。このテストは、各サーバーが同時リクエストの下でどれだけ効率的にシンプルなHTMLページを提供するかを測定します。静的コンテンツに最適化されたウェブサーバーは、遅延やリソース使用を最小限に抑えながら、高いリクエスト毎秒(RPS)を提供するべきです。このテストは、ブログ、ドキュメントサイト、コンテンツ配信ネットワーク(CDN)など、ウェブサイトが主にキャッシュされた事前生成されたページを提供するシナリオにおいて非常に重要です。
レイテンシとは、クライアントのリクエストとサーバーの応答の間の時間の遅延を指します。ウェブホスティングにおいて、低いレイテンシはページの読み込みが速く、ユーザーのインタラクションがスムーズで、全体的なパフォーマンスが向上することを意味します。高いレイテンシは、ウェブサイトの読み込みが遅く、ユーザー体験が悪化し、収益の損失をもたらす可能性がある、特にEコマースや高トラフィックのアプリケーションではそうです。私たちのテストでは、レイテンシはリクエストスループットと共に測定され、各サーバーがどれだけ迅速に着信リクエストを処理し、応答できるかを評価しました。秒あたりのリクエスト数(RPS)が重要である一方で、低レイテンシのサーバーは、コンテンツが効率的に提供され、不必要な遅延なしに配信されることを保証します。特にトラフィックが多い状況下でも。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してApache Benchmark (ab)で実施されました:
ab -n 10000 -c 100 http://server-ip/-n 10000→ リクエストの総数(10,000)-c 100→ 同時ユーザー数(100)http://server-ip/→ 静的テストページのURL
このコマンドは、サーバーのリクエスト処理速度と効率を評価するために、100人のユーザーが簡単なHTMLファイルに繰り返しリクエストを送信するシミュレーションを行います。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒に関して最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
Lighttpdは8645 RPSという最高のリクエストレートを達成し、この静的コンテンツテストで最も速いサーバーとなりました。LiteSpeedとOpenLiteSpeedもそれに続き、優れた静的ファイルのパフォーマンスを示しましたが、NGINXとCaddyは同様の性能を発揮しました。Apacheはまだ能力がありますが、トップパフォーマーと比べて1秒あたりのリクエスト数は大幅に少なく処理しました。
ベストユースケースと推奨事項
- Lighttpdは、最小限のリソース使用で静的コンテンツを提供するのに最適で、組み込みシステム、軽量ウェブサービス、および静的コンテンツが多いサイトに適しています。
- LiteSpeed と OpenLiteSpeed は、高速な静的コンテンツ配信を提供し、動的機能との互換性を保つため、高性能なウェブサイトに最適な選択肢です。
- NGINXは、特に静的コンテンツと動的コンテンツのバランスを効率的にとる必要があるセットアップで、依然として強力な競争相手です。
- Apacheは最も速いわけではありませんが、
.htaccessや既存の設定との互換性が必要な環境では良い選択肢となるかもしれません。
テスト2: 大容量ファイル転送
テストの目的
大きなファイルを効率的に配信することは、ダウンロード、ストリーミングメディア、高解像度の画像やソフトウェアパッケージなどの大きな資産を配信するウェブサイトにとって重要です。このテストでは、同時リクエストの下で各ウェブサーバーが10MBファイルの転送をどのように処理するかを評価します。最適化されたサーバーは、CPUとメモリ使用量を最小限に抑えながら、高い転送速度を維持する必要があります。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してApache Benchmark (ab)で実施されました:
ab -n 500 -c 10 http://server-ip/testfile10M.bin- -n 500 → リクエストの総数 (500)
- -c 10 → 同時ユーザー数 (10)
http://server-ip/testfile10M.bin→ 10MBテストファイルのURL
このコマンドは10人の同時ユーザーが大きなファイルを繰り返しダウンロードすることをシミュレートし、大きなペイロードを処理する各ウェブサーバーのスループットと効率に関する洞察を提供します。
結果表
注意: 最後の列は結果を正規化しており、100%は転送速度において最もパフォーマンスの良いサーバーを表しています。
結果の解釈
NGINXは123.26 MB/secで最高のスループットを示し、大きなファイルを効率的に提供するための最良の選択肢となりました。OpenLiteSpeedもほぼ同等のパフォーマンスを示し、転送速度にはわずかな差がありました。Lighttpdも強力な結果を示し、大きなペイロードを効果的に処理できる能力を示しています。Apacheは最低の転送速度を持ち、これに高いレイテンシが加わることで、他のサーバーと比較して大きなファイルを提供するために最適化されていないことを示唆しています。
最適な使用例と推奨事項
- NGINXは大容量ファイルの配信に最適なオプションであり、ビデオストリーミング、ファイルホスティング、ソフトウェア配信サービスに理想的です。
- OpenLiteSpeed と LiteSpeed は、キャッシングと最適化機能を追加することで競争力のあるパフォーマンスを提供し、高トラフィックのメディアリッチなウェブサイトにとって強力な選択肢となります。
- Lighttpd は、効率が重要な軽量展開において有効な代替手段のままです。
- Caddyは良好なパフォーマンスを提供し、HTTPSの設定を簡素化します。これは、安全なファイル配信に役立ちます。
- Apacheはこのテストでは遅れをとっているため、追加の調整が行われない限り、大きなファイルを頻繁に提供するサイトには最適な選択ではないかもしれません。
テスト3: 高同時実行性能
テストの目的
ウェブサーバーは、特にピーク時の負荷の多い高トラフィック量を効率的に処理しなければなりません。このテストは、1,000人の同時ユーザーが単純なHTMLページにリクエストを送信したときに、各サーバーがどれだけうまく機能するかを測定します。最適化されたサーバーは、最小限のレイテンシーで高いリクエストレートを維持し、過剰なCPUおよびメモリの消費を避けるべきです。このテストは、eコマースプラットフォーム、ニュースウェブサイト、およびオンラインサービスなど、トラフィックのピークを経験するサイトにとって重要です。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してApache Benchmark (ab)で実施されました:
ab -n 20000 -c 1000 http://server-ip/-n 20000→ リクエストの総数 (20,000)-c 1000→ 同時ユーザー数 (1,000)http://server-ip/→ テストページのURL
このコマンドは、テストページに1,000の同時リクエストを送信することで、重いトラフィック負荷をシミュレートします。目標は、サーバーが秒間に処理できるリクエストの数を測定し、レイテンシや潜在的な障害を監視することです。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒において最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
Lighttpdは高い同時接続を最も効果的に処理し、1秒間に7936リクエストを達成し、最低のレイテンシを記録しました。LiteSpeedとOpenLiteSpeedも接近しており、強力な同時接続処理能力を示しました。NGINXとCaddyも良好なパフォーマンスを示しましたが、わずかに高いレイテンシを示しました。Apacheは再び最もリクエスト数が少なく、最高のレイテンシを持っており、極端な負荷の下では最も効率が悪い選択肢となっています。
ベストユースケースと推奨事項
- Lighttpdは、最小限のリソース使用で多数の同時ユーザーを処理するのに最適な選択であり、高トラフィックのAPIやウェブアプリケーションに適しています。
- LiteSpeed と OpenLiteSpeed は、高い同時接続環境において優れた性能を発揮し、賑わっているウェブサイト、フォーラム、WooCommerce ストアに最適です。
- NGINXは非常に優れたパフォーマンスを発揮します、特に負荷のかかる状況下で静的および動的コンテンツの両方を処理する際に。
- Caddyはそれなりの同時処理能力を提供しますが、NGINXやLiteSpeedにはわずかに劣ります。
- Apacheは高い同時接続数に苦しんでおり、徹底的に最適化されない限り、高トラフィックの環境にはあまり適していません。
テスト4:wrk ベンチマーク(100ユーザー)
テストの目的
wrkベンチマークツールは、Apache Benchmarkと比較して、より現実的なユーザートラフィックのシミュレーションを提供します。これは、複数のスレッドとオープン接続を使用して、高負荷条件をより効果的にシミュレートします。このテストは、各Webサーバーが100同時ユーザーが30秒間シンプルなHTMLページにリクエストを送信する際の処理能力を評価します。目標は、リクエストスループット、平均レイテンシ、およびサーバーが高トラフィック負荷を持続する能力を測定することです。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してwrkを使って実施されました:
wrk -t4 -c100 -d30s http://server-ip/-t4→ スレッドの数 (4)-c100→ 同時接続数(100)-d30s→ テストの期間(30秒)http://server-ip/→ テストページのURL
このテストは100人のユーザーが30秒間にわたって繰り返しリクエストを行うことをシミュレートし、一貫した負荷の下での持続的なパフォーマンスと応答時間に関する洞察を提供します。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒に関して最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
Lighttpdは、持続的なリクエスト処理において他のすべてのウェブサーバーを上回り、28,867リクエスト/秒という最低のレイテンシで処理しました。OpenLiteSpeedはこれに次ぎ、高いパフォーマンスを維持しました。LiteSpeed、NGINX、Caddyは比較的似ていましたが、Lighttpdよりも10〜15%悪いパフォーマンスを示しました。Apacheは再び遅れを取り、競合他社よりもリクエストスループットが低く、レイテンシが高かったです。
最適な使用例と推奨事項
- Lighttpdは持続的な高負荷シナリオに最適な選択肢であり、APIサーバー、静的ファイルホスティング、組み込みシステムに最適です。
- OpenLiteSpeed と LiteSpeed は、長期間のベンチマークで優れたパフォーマンスを発揮します。これにより、高トラフィックの WordPress および WooCommerce サイトに適しています。
- NGINXは依然として強力な選択肢です、特に静的コンテンツと動的コンテンツの処理の両方を必要とする混合ワークロードに対してです。
- キャディは堅実な選択肢ですが、LiteSpeedやNGINXと同じパフォーマンスの利点を提供していません。
- Apacheは持続的な負荷性能において遅れをとっており、継続的な高トラフィック環境に対処するのにはあまり適していません。
テスト 5: wrk ベンチマーク (500 ユーザー)
テストの目的
このテストは、各ウェブサーバーが持続的な期間にわたり、より多くの同時ユーザーをどのように処理するかを評価します。同時処理レベルを500ユーザーに引き上げることで、このベンチマークは、重い負荷の下での各サーバーの最大スループットと安定性を測定します。このテストは、特にeコマースストア、ニュースサイト、大規模APIなど、高いピークトラフィックを経験するウェブサイトやアプリケーションにとって有用です。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してwrkを使って実施されました:
wrk -t8 -c500 -d60s http://server-ip/-t8→ スレッドの数 (8)-c500→ 同時接続数(500)-d60s→ テストの期間(60秒)http://server-ip/→ テストページのURL
このコマンドは500人のユーザーが1分間継続的にリクエストを行うことをシミュレートし、過酷な条件下での各サーバーの長期的な安定性とスループットに関する洞察を提供します。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒において最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
Lighttpdが再びトップの座を獲得し、毎秒28,308リクエストを達成し、最も低いレイテンシーを記録しました。これは高い同時接続時に最も効率的なサーバーです。OpenLiteSpeedが続き、強力なパフォーマンスを示しました。LiteSpeedとNGINXも好成績を収めましたが、わずかに高いレイテンシーがありました。Apacheは大きく後れを取り、トップパフォーマーと比較して毎秒30%少ないリクエストに苦しみ、重い持続的なトラフィックを処理する際の限界をさらに確認しました。
最適な使用例と推奨事項
- Lighttpdは、最小限のリソース使用で非常に高い同時処理を処理するための最良の選択肢であり、大規模なAPI、高トラフィックの静的サイト、埋め込みシステムに最適です。
- OpenLiteSpeed と LiteSpeed は、高負荷の状況下でも非常に優れたパフォーマンスを発揮します。これにより、忙しい WordPress/WooCommerce サイトや高トラフィックのアプリケーションに最適な選択肢となります。
- NGINXは強力な候補です、一般的なウェブホスティングのためのパフォーマンスと柔軟性のバランスを取っています。
- キャディは合理的な選択ですが、極端な負荷の下ではLiteSpeedやNGINXのパフォーマンスには及びません。
- Apacheは高同時接続シナリオで引き続き苦しんでおり、大規模なトラフィックのあるプロダクション環境には、十分に最適化されていない限り、最適な選択肢とは言えません。
テスト6:wrkベンチマーク(大ファイル、50ユーザー)
テストの目的
大容量ファイル転送を効率的に処理することは、メディアファイル、ソフトウェアダウンロード、高解像度画像をホストしているウェブサーバーにとって重要です。このテストでは、各サーバーが50ユーザーという中程度の同時負荷の下で10MBのファイルをどれだけうまく配信できるかを評価します。目的は、持続的スループットと応答時間を測定し、サーバーが過度な遅延やボトルネックなしに大容量ファイル転送を処理できることを確認することです。
ベンチマーキングコマンドとその説明
テストは次のコマンドを使用してwrkを使って実施されました:
wrk -t4 -c50 -d30s --latency http://server-ip/testfile10M.bin-t4→ スレッドの数 (4)-c50→ 同時接続数(50)-d30s→ テストの期間(30秒)- --latency → 詳細なレイテンシレポートを有効にします
http://server-ip/testfile10M.bin→ 10MBテストファイルのURL
このテストは、50人の同時ユーザーが10MBのファイルを30秒間継続的にダウンロードすることをシミュレートしています。それは、サーバーが低遅延を保ちながら高い転送速度を維持できる能力を測定します。
結果表
注意: 最後の列は結果を正規化しており、100%は転送速度における最良のサーバーを表しています。
結果の解釈
Lighttpdは136.01 MB/secの転送速度で最高のパフォーマンスを発揮し、大きなファイルのダウンロードに最も効率的な選択肢となりました。OpenLiteSpeed、LiteSpeed、NGINXは同様に良好な性能を示し、わずか3-7%の差がありました。CaddyとApacheは後れを取り、特にApacheはこのテストで最も遅いサーバーであり、著しく高いレイテンシを伴いながら高い転送速度を維持するのに苦労しました。
ベストユースケースと推奨事項
- Lighttpdは、大きなダウンロードファイル、ビデオストリーミング、高速コンテンツ配信に最適なホスティングの選択肢です。
- NGINXとLiteSpeedは優れた代替手段です。追加のキャッシングと最適化機能を備えた高いパフォーマンスを提供します。
- OpenLiteSpeedは競争力のあるパフォーマンスを提供し、大規模なメディアファイルを提供する高トラフィックアプリケーションに最適です。
- Caddyはシンプルなデプロイメントのオプションですが、Lighttpd、LiteSpeed、またはNGINXの効率には及びません。
- Apacheは大きなファイル転送において不足しており、広範な最適化が適用されない限り、高容量のファイルホスティングには不適格です。
テスト7: シージベンチマーク(50ユーザー - バーストトラフィック)
テストの目的
ウェブサーバーは、フラッシュセール、ニュース速報、ソーシャルメディアによる急増など、突然のトラフィックの急増に対応しなければなりません。このテストは、50人のユーザーのバーストが短期間に急速にリクエストを送信することをシミュレートします。リクエストを連続して送信するwrkやabとは異なり、siegeはリクエスト間にランダムな遅延を導入して、実際のブラウジング行動をよりよく模倣します。
包囲(Siege)は単なる負荷テストツールではなく、遅延、同時処理、持続的な負荷条件を導入することで、実際のブラウジング行動をシミュレートします。一定のリクエストを送信する
ab とは異なり、Siege はランダムな遅延を伴う実際のユーザー交通を模倣します。また、複数のURLをサポートしており、静的ページ、大きなファイル、動的コンテンツなどの混合ワークロードのテストに最適です—これはこのベンチマークで行ったことと同じです!ベンチマーキングコマンドとその説明
テストは、次のコマンドを使用してsiegeで実施されました:
siege -c50 -t2M -d1 http://server-ip/-c50→ 50人の同時ユーザーをシミュレートします-t2M→ 2分間テストを実行します-d1→ 各ユーザーはリクエストの間に最大1秒までランダムに待機しますhttp://server-ip/→ 静的テストページのURL
このテストは、不定期に発生する高いユーザートラフィックの急増を処理する際の各ウェブサーバーのパフォーマンスを評価し、スループット、応答時間、そして失敗率を測定します。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒に関して最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
NGINXはバーストトラフィックを最も効果的に処理し、最低のレイテンシーで202.19 RPSを達成し、トラフィックの突然の急増を処理する際の効率が最も高いことが示されました。LiteSpeed、Lighttpd、Caddyはほぼ同じパフォーマンスを示し、スループットにおいて1-2%の差にとどまりました。Apacheはその後ろに近づき、前回のテストと比較して効率が改善されていました。OpenLiteSpeedはパフォーマンスにわずかな低下がありましたが、依然として競争力を維持していました。
最適な使用例と推奨事項
- NGINXは突然のトラフィックの急増を処理するための最適な選択肢です。これにより、高トラフィックのブログ、ニュースウェブサイト、ソーシャルメディアによるコンテンツに理想的です。
- LiteSpeedとOpenLiteSpeedはほぼ同等のパフォーマンスを提供し、追加のキャッシュおよび最適化機能が組み込まれています。
- Lighttpdは効率的な代替手段です、最小限のリソース消費で優れたバーストトラフィック性能を提供します。
- Caddyはシンプルなデプロイメントに適した選択肢ですが、そのパフォーマンスはトップクラスのものにはほんの少し劣ります。
- Apacheはこのテストで驚くほど良い結果を出しました。これにより、一時的なトラフィックの急増を経験しているサイトにとって合理的な選択肢となります。
テスト8:攻城ベンチマーク(200ユーザー - 継続的負荷)
テストの目的
このテストは、5分間にわたり200人の同時ユーザーで各ウェブサーバーが持続的な高トラフィックをどの程度処理できるかを評価するために設計されました。以前のテストとは異なり、短期間のバーストや中程度の同時性に焦点を当てたのではなく、このテストは、ピーク時のeコマースサイトやプライムタイムのストリーミングサービスに類似した延長された高流量トラフィックをシミュレートしています。
ベンチマーキングコマンドとその説明
テストは、次のコマンドを使用してsiegeで実施されました:
siege -c200 -b -t5M http://server-ip/-c200→ 200人の同時ユーザーをシミュレートします- -b はベンチマークモードで実行され、リクエスト間にランダムな遅延がないことを意味します。
-t5M→ 5分間実行しますhttp://server-ip/→ 静的テストページのURL
このテストはサーバーに途切れのない高負荷を強いることでストレスを与え、リクエスト処理、リソース配分、接続管理における弱点を明らかにします。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒において最も良好なパフォーマンスを示すサーバーを表しています。
結果の解釈
このテストでは、Apache、LiteSpeed(商用)、Caddy、およびLighttpdはすべてベンチマークを完了できませんでした。テストは無限にハングしたり、応答しなくなったりしました。これは、これらのサーバーが、デフォルト設定のままでは、長期間にわたる高い同時実行性を維持するのに苦労していることを示唆しています。それぞれのサーバーを個別に調査して調整するのではなく、デフォルト設定のみに焦点を当てることにしました。設定を変更して失敗をトラブルシューティングすることは、結果を薄め、比較間での不一致を導入することになるからです。
テストを完了したサーバーの中で、NGINXが最も優れたパフォーマンスを発揮しました。1秒間に100リクエストを正常に処理し、最も低いレイテンシで対応しました。OpenLiteSpeedもテストを完了しましたが、スループットはやや低い98.4 RPSで、レイテンシは高くなりました。
最適な使用例と推奨事項
- NGINXは、長期間の高同時接続トラフィックを処理するための最適な選択であり、大規模なウェブサイト、API、およびストリーミングサービスに最適です。
- OpenLiteSpeedは実行可能な代替手段です。NGINXよりもやや高いレイテンシで、持続的に良好なパフォーマンスを提供します。
- Apache、LiteSpeed、Caddy、およびLighttpdは持続的な負荷に苦しんでおり、高い同時実行シナリオでの障害を避けるためにチューニングが必要になる可能性があります。
テスト9: シージベンチマーク(100ユーザー - 混合ページ)
テストの目的
ウェブサーバーは、実際のアプリケーションで静的ページ、大きなファイル、および動的リクエストの混合を効率的に提供する必要があります。このテストは、異なるタイプのコンテンツを要求する100人の同時ユーザーをシミュレートし、それぞれのサーバーが多様なワークロードをどのように管理するかを評価します。これは、HTMLページ、画像、大きなファイルを同時に提供するウェブサイトに特に便利です。
ベンチマーキングコマンドとその説明
テストは、次のコマンドを使用してsiegeで実施されました:
siege -c100 -t3M -f urls.txt-c100→ 100人の同時ユーザーをシミュレートします-t3M→ 3分間実行します-f urls.txt→ 複数のURLを含むファイルを使用してテストします
urls.txtファイルには、さまざまなコンテンツタイプが混在していました:
http://server-ip/
http://server-ip/contact.html
http://server-ip/testfile10M.bin
これにより、ベンチマークは各ウェブサーバーが小さな静的ページ、標準HTMLファイル、そして大きなファイルのダウンロードを同時にどのように処理するかをテストすることが保証されました。
結果表
注意: 最後の列は結果を正規化しており、100%はリクエスト毎秒の観点から最高のパフォーマンスを発揮するサーバーを示しています。
結果の解釈
OpenLiteSpeedはこのテストで最も優れたパフォーマンスを発揮し、181.05リクエスト/秒を達成しました。その後にNGINXとLiteSpeedが続き、どちらもOpenLiteSpeedの2%以内のマージンでパフォーマンスを発揮しました。CaddyとLighttpdも混合ワークロードをうまく処理しましたが、Apacheは最もパフォーマンスが低く、トップパフォーマーよりも約9%少ないリクエストを処理しました。これは、OpenLiteSpeedとNGINXが混合ワークロードを効果的に処理するのに適していることを示唆しています。
ベストユースケースと推奨事項
- OpenLiteSpeedは、WordPress、WooCommerce、動的アプリケーションなど、さまざまなコンテンツを持つウェブサイトに最適な選択です。
- NGINXは強力な代替手段です。混合ワークロードに対して優れたパフォーマンスを提供し、一般的なホスティングに最適です。
- LiteSpeedとCaddyは優れたパフォーマンスを発揮します。LiteSpeedは組み込みキャッシングの利点があり、Caddyは自動HTTPS処理に優れています。
- Lighttpdは依然として堅実な選択肢ですが、混合コンテンツの処理においてはトップ競合に少し遅れをとっています。
- Apacheは機能的ですが、他のサーバーと比較して多様なワークロードを扱う際にはパフォーマンスが劣ります。」
グローバル比較とパフォーマンス分析
6つの異なるウェブサーバーに対して広範なベンチマークを実施した後、複数のテストシナリオにおける全体的なパフォーマンスを比較することができます。このセクションでは、静的ファイル、大きなファイル転送、高い同時接続、混合負荷の処理におけるそれぞれの強みと弱みを分析します。
全体パフォーマンスランキング
以下の表は、リクエストスループット、レイテンシ、および信頼性を考慮して、すべてのテストにおける平均パフォーマンスに基づいてウェブサーバーをランキングしています。
テスト8(シージベンチマーク - 200ユーザー、持続負荷)はランキングに大きな影響を与えました。このテストを完了したのはNGINXとOpenLiteSpeedのみで、Apache、LiteSpeed、Caddy、Lighttpdはハングや接続制限に達したため失敗しました。その結果、これらのサーバーはこのテストで0%のスコアを受け取り、最終的なパフォーマンス平均に影響を与えました。
主要な観察:
- NGINXは最もバランスの取れたサーバーとして登場しました。すべてのテストで優れたパフォーマンスを発揮し、特に大きなファイル転送や高い同時接続処理において優れています。
- OpenLiteSpeedはNGINXとほぼ同一であり、混合コンテンツの処理と静的ファイルのパフォーマンスに優れています。
- LiteSpeed(商用版)は、高性能のために最適化されました、特にキャッシングが重視されるワークロード、例えばWordPress/WooCommerceサイトにおいて。
- Lighttpdは、パフォーマンスが良いにもかかわらず、最も少ないリソースを消費するため、軽量、組み込み、またはリソース制約のあるシステムに最適です。
- Caddyは優れた性能を持っていますが、その本当の強みは使いやすさと自動HTTPS設定にあり、純粋なスピードではありません。
- Apacheは特に高い同時実行性と大きなファイルテストにおいて最も苦労しました。手動での調整が行われない限り、最適な選択肢とは言えません。
リソース使用: CPU & RAMの効率
| サーバー | CPU使用率 (%) | RAM使用量 (MB) | 低リソース環境に最適 |
|---|---|---|---|
| Lighttpd | 55% | 680MB | ✅ |
| NGINX | 60% | 710MB | ✅ |
| オープンライトスピード | 62% | 720MB | ✅ |
| LiteSpeed | 68% | 740MB | ❌ |
| キャディ | 72% | 780MB | ❌ |
| アパッチ | 75% | 820MB | ❌ |
重要なポイント:
- Lighttpdは最も効率的で、CPUとRAMの消費が最も少なく、低電力環境や埋め込みシステムに最適です。
- NGINXとOpenLiteSpeedはほぼ同じで、パフォーマンスとリソース効率の良いバランスを実現しています。
- ApacheはCPUおよびRAMの使用率が最も高く、高い同時接続時のパフォーマンスが低下する理由をさらに説明しています。
レイテンシーと応答時間の傾向
| サーバー | 低い同時実行性 (ミリ秒) | 中負荷 (ミリ秒) | 高い同時接続数 (ms) |
|---|---|---|---|
| Lighttpd | 100 | 140 | 220 |
| NGINX | 110 | 160 | 260 |
| オープンライトスピード | 115 | 170 | 270 |
| LiteSpeed | 120 | 180 | 290 |
| キャディ | 130 | 190 | 310 |
| アパッチ | 150 | 240 | 380 |
重要なポイント:
- Lighttpdはすべてのシナリオで最も低いレイテンシを持っており、応答時間が最も速いです。
- NGINXとOpenLiteSpeedは一貫して良好に動作し、レスポンスタイムはLighttpdよりわずかに高かった。
- Apacheは最も高いレイテンシを持っており、大規模なトラフィック負荷を効率的に処理するのに苦労していることを確認しました。
最終推薦: どのウェブサーバーを選ぶべきか?
| 使用例 | 推奨サーバー |
|---|---|
| 最高の全体的パフォーマンス | NGINXまたはOpenLiteSpeed |
| リソースが少ない場合に最適 | Lighttpd |
| WordPress/WooCommerceに最適 | LiteSpeed(商用) |
| シンプルな設定とHTTPSに最適 | キャディ |
| 大容量ファイルホスティングに最適 | NGINX |
| 高トラフィックAPIに最適 | オープンライトスピード |
| 最高の伝統的なセットアップ | アパッチ(必要な場合のみ) |
重要なポイント:
- もし、バランスの取れた高性能なウェブサーバーが必要であれば、NGINXまたはOpenLiteSpeedが最適な選択です。
- リソースが限られた環境では、Lighttpdが最も効率的でありながら、強力なパフォーマンスを提供します。
- WordPress/WooCommerceを運営しているなら、LiteSpeed(商用版)が最適化された最良の選択です。
- 自動HTTPSを簡単に設定したいなら、Caddyは素晴らしい選択です。
- Apacheは、高性能の使用ケースには徹底的に微調整しない限りお勧めできません。
最終結論と要約
適切なウェブサーバーを選択することは、パフォーマンス、リソース効率、およびスケーラビリティを最適化するために重要です。Apache、NGINX、LiteSpeed(商用)、OpenLiteSpeed、Caddy、およびLighttpdに関して広範なベンチマークを実施した結果、さまざまなユースケースに対する明確な勝者を特定しました。
主な発見
- NGINX と OpenLiteSpeed は、全体的なパフォーマンスが最も優れており、高い同時接続、大きなファイルの処理、混合ワークロードにおいて優れた性能を発揮しました。
- Lighttpdは最もリソース効率が良いことが証明されており、低電力または組み込み環境において強力なパフォーマンスを維持しながら優れた選択肢となっています。
- LiteSpeed(商用)は、WordPress/WooCommerce用に最適化されており、優れたスピードと組み込みのキャッシュを提供します。
- Caddyはシンプルで安全なウェブサーバーのセットアップを提供しましたが、上位の競合他社の生のパフォーマンスには匹敵しませんでした。
- Apacheは高い同時接続数のシナリオで苦労し、他のサーバーよりもより多くのCPUとRAMを使用しているため、広範な最適化なしでは理想的な選択肢ではありません。
どのウェブサーバーを選ぶべきですか?
| 使用例 | 最高のサーバー選択 |
|---|---|
| 汎用ウェブホスティング | NGINXまたはOpenLiteSpeed |
| WordPress/WooCommerceサイト | LiteSpeed(商用) |
| リソースが限られた環境 | Lighttpd |
| 静的ファイルホスティング/CDN | LighttpdまたはNGINX |
| 大きなファイルのダウンロード | NGINX |
| 高トラフィックAPI/ウェブアプリ | オープンライトスピード |
| HTTPSによる簡単なデプロイメント | キャディ |
| レガシー/互換性の理由 | アパッチ(必要な場合) |
最終的な考え
- 最高のパフォーマンス、スケーラビリティ、効率のバランスが必要な場合、NGINXまたはOpenLiteSpeedが最もおすすめの選択肢です。
- WooCommerce または WordPress サイトを運営している場合、LiteSpeed(商用)は優れた最適化とキャッシングを提供します。
- 軽量で効率的なウェブサーバーが必要な場合、Lighttpdが最もリソースに優しい選択肢です。
- 使いやすさと自動HTTPSが優先事項であれば、Caddyは素晴らしい代替手段です。
- Apacheは広く使用されていますが、慎重に最適化しなければ、現代のワークロードでは最良のパフォーマンスを発揮しません。
デフォルト設定に従うことによって、これらのベンチマークは各サーバーの工場出荷時のパフォーマンスを強調しています。しかし、特定のニーズに基づいてカスタム調整と最適化を適用することで、実際のパフォーマンスを向上させることができる。



