8

django を使用して、mysql の json webservice フロントエンドを作成しています。EC2 インスタンスで apache と django を実行し、RDS インスタンスで MySQL を実行しています。Apache ベンチを使用してパフォーマンスのベンチマークを開始しましたが、非常に低いパフォーマンスの数値が得られました。また、テストの実行中に、apache/django インスタンスの CPU 使用率が非常に低い負荷で 100% になり、MySQL インスタンスの CPU 使用率が 2% を超えることはないことにも気付きました。

これを理解し、問題を切り分けようとしているので、いくつかの ab テストを行いました。

  1. Apache からの静的な HTML ページのリクエスト -- ~2000 リクエスト/秒。
  2. django で小さな python 関数を実行するリクエストで、db とのやり取りはありません -- ~1000 リクエスト/秒。
  3. 認証を呼び出す django Web サービス関数の 1 つを実行し、テーブルから 1 つのレコードを取得する非常に単純なクエリを実行する要求 - 11 要求/秒
  4. 3 と同じですが、認証の呼び出しにコメントを付けました -- 95 リクエスト/秒。

認証が非常に遅いのはなぜですか? 10 億桁の pi を見つけて、データベースにデータを書き込んでいますか?

URL を推測できる人に公開したくないので、これらの関数で認証の呼び出しを保持したいと思います。それ?

どうもありがとうございました!

4

1 に答える 1

8

私は認証とセキュリティの専門家ではありませんが、これが発生する理由と、パフォーマンスをいくらか向上させる方法について、いくつかのアイデアを以下に示します。

パスワードはデータベースに保存されるため、ストレージを安全にするために、プレーンテキストのパスワードは保存されず、代わりにハッシュが保存されます。このようにして、入力されたパスワードから計算されたハッシュをデータベースに保存されているものと比較することにより、ユーザーのログインを検証できます。これによりセキュリティが強化されるため、悪意のある人物がデータベースのコピーを取得した場合、プレーンテキストのパスワードをデコードする唯一の方法は、レインボー テーブルを使用するか、ブルート フォース攻撃を行うことです。

ここからが興味深いところです。ムーアの法則によれば、コンピューターは指数関数的に高速化されているため、ハッシュ関数の計算は、特に md5 や sha1 などの高速ハッシュ関数のように、時間の点ではるかに安くなります。これは問題を引き起こします。現在利用可能なすべてのコンピューティング パワーを高速なハッシュ関数と組み合わせると、ハッカーはハッシュ化されたパスワードを比較的簡単にブルート フォース攻撃できるからです。これに対抗するには、2 つのことを行うことができます。1 つは、ハッシュ関数を複数回ループすることです (ハッシュの出力がハッシュにフィードバックされます)。ただし、これはハッシュ関数の複雑さを定数だけ増加させるだけなので、あまり効果的ではありません。そのため、実際のハッシュ関数をより複雑にし、計算コストを高くする 2 番目のアプローチが推奨されます。より複雑な機能を持ち、ハッシュの計算に時間がかかります。計算に 1 秒かかったとしても、エンドユーザーにとっては大したことではありませんが、何百万ものハッシュを計算する必要があるため、ブルート フォース攻撃にとっては大したことです。そのため、Django 1.4 以降では、PBKDF2 と呼ばれるかなり計算コストの高い関数を使用しています。

あなたの答えに戻るために。この機能のおかげで、認証を有効にすると、ベンチマークの数値が大幅に下がり、CPU が上がります。

パフォーマンスを向上させる方法をいくつか紹介します。

  • Django 1.4 以降では、デフォルトの認証関数 ( docs ) を変更できます。あまりセキュリティが必要ない場合は、デフォルトの関数を SHA1 または MD5 に変更できます。これによりパフォーマンスが向上するはずですが、セキュリティが大幅に低下することに注意してください。私の個人的な意見では、セキュリティは重要であり、余分な時間を費やす価値がありますが、アプリケーションで保証されていない場合は、検討する必要があるかもしれません.
  • セッションを使用します。高価なハッシュ関数は、最初のログイン時にのみ計算されます。ユーザーがログインすると、そのセッションのセッションが作成され、セッション ID とともに Cookie がユーザーに送信されます。その後のリクエストで、ユーザーは Cookie をアップロードし、セッションがまだ期限切れになっていない場合、ユーザーは自動的に認証されます (セッション データは署名されているため、セキュリティについて心配する必要はありません...)。ポイントは、セッションの検証は、高価なハッシュ関数の計算に比べて計算コストがはるかに低いということです。ab テストでは、セッション Cookie を送信しなかったと思います。セッション Cookie の送信を追加していくつかのテストを行い、そのパフォーマンスを確認してください。JSON API を作成しているため、Cookie を送信することが実際には選択肢にならない場合は、その後、セッション バックエンドを変更して、Cookie の代わりにセッション GET パラメータを介してセッション データを受け入れることができます。ただし、それを行うことのセキュリティへの影響は何ですか。
  • nginx に切り替えます。私はデプロイメントの専門家ではありませんが、私の経験では、nginx は Apache に比べて Django に対してはるかに高速で使いやすいです。あなたにとって特に興味深いと思われる利点の1つは、複数のワーカープロセスを持つnginxの機能と、proxy_passを使用してDjangoプロセスへのリクエストを処理できることです。複数のワーカー プロセスがある場合は、proxy_pass を介して各ワーカーを個別の Django プロセスにポイントすることができます。これにより、マルチプロセッシングが効果的に Django に追加されます。別の方法として、gevent WSGI サーバーのようなものを使用する場合、Django プロセスでプールを作成してパフォーマンスを向上させることもできます。CPU負荷がすでに100%であるため、これらのいずれかがパフォーマンスを大幅に向上させるかどうかはわかりませんが、調べる必要があるかもしれません.
于 2013-01-23T05:37:12.283 に答える