5

私たちの問題の 1 つは、送信メール サーバーが時々うまくいかないことです。ユーザーはアプリケーションで電子メールをトリガーし、アプリケーションが実際に送信するのに 30 秒程度かかる場合があります。さらに悪いことに、バックグラウンド スレッドでこれを行っていないことを認めましょう。この間、ユーザーは完全にブロックされます。SQL Server データベース メールは、基本的にメッセージ キューを実装し、サード パーティの電子メール ホストよりも物理的に近く、はるかに応答性が高いため、この問題の解決策として提案されています。SmtpClient.Sendまた、1 回の呼び出しをストアド プロシージャの実行に置き換えるだけなので、実装も非常に簡単です。私たちのアプリケーション電子メールのほとんどには PDF や XLS などが含まれており、これらの添付ファイルのサイズが 20MB に達するのを見てきました。

データベース メールを使用してアプリケーションのすべての電子メールを処理するのは嫌なにおいがしますが、実装コストが非常に低いことを考えると、データベース メールをやめさせるのに苦労しています。私たちの実稼働データベース サーバーは非常に強力なので、負荷を処理できないかどうかもわかりません。アイデアやより安全な代替案はありますか?

4

2 に答える 2

1

SMTP サーバーを介して実行するだけでよく、大量のメールを送信する予定がある場合は、サーバー (および 100K の送信を計画している場合は DNS サーバー) の負荷を分散するだけでなく、 + メールは一度に) ただし、バウンスバックを防ぐために、送信メール サーバーの DNS に適切な A レコードが登録されていることを確認してください。

これは安価なソリューションです (ロード バランサーのコストを差し引いたものです)。

于 2012-10-16T20:28:21.713 に答える
0

はい、内部 LAN とインターネット用にサーバーをデュアルホームにし、それが送信専用サーバーであることを確認してください。1 台の SMTP サーバーから始めて、すぐにボトルネックが発生した場合は、それがメモリ、ディスク、ネットワーク、または負荷に関連していないかどうかを確認します。負荷が関連している場合は、負荷分散を検討する時期かもしれません。メモリ関連の場合は、より多くのメモリを投入してください。ディスク関連の場合は、raid 0+1 アレイを投げます。ネットワーク関連の場合は、より大きなパイプを使用してください。

于 2012-10-16T21:20:46.220 に答える