y-matsui::weblog

電子楽器、音楽、コンピュータ、プログラミング、雑感。面倒くさいオヤジの独り言

BASP21でDBからバルクメール・・の方法(案)←とりあえず言いたい放題

今回作ろうとしているメール送信機能は、ほぼすべてを高機能なCOMコンポーネントBASP21”に負っている。(一礼)
FlushMailメソッドやSendMailExなどの機能を存分に活用してみたい。加えてSMTPAuthやPOP before SMTPなんかにもアプリとして対応しておかないと、せっかく作った機能が使えない(メールサーバにはじかれる)結果になりそうだ。DNS逆引き問題、Senderアドレス問題なんかも想定しなきゃいけない。(面倒だぁ・・認証の話って)
文書登録の通知を複数の関係者宛てに送信する程度であれば、ASPから直接SendMailメソッドで送信してもOKなのだが、問題はメールマガジンのように、何万という単位でメール送信を行う用途をターゲットにする場合。さすがにキューを使った非同期送信が必須だろう。さもなければスクリプトの実行制限時間内に送信が終わらず、Webアプリで応答がなくなってしまうという悲惨な結果に。
過去にLotusScriptでメール送信したケースでは、(ノーツのメールキューの仕組みがあるので)スクリプトはメールファイルを生成して、即座に開放されるのであるが、それでも2万通のメール送信でたっぷり3時間は掛かっていた。結局、このケースではノーツDBからの条件検索した結果を、送信先リストCSVとして書き出し、定期実行エージェント(スクリプト)が10分おきに1000通程度を処理しては、管理者にメール通知するという仕組みにしていた。(Webアプリでは送信条件を指定して、送信リストを生成したら即座に開放されるようにした)
送信処理では、メール本文を1通1通変数付きで生成できるというなかなか凝った仕組みなのであるが、その部分で時間を使ってしまっていることは間違いない。
また、別の例では、宛先リストの生成、1通1通のメッセージ内容の送信キューレコードをSQLスクリプトで生成し、送信前にDBを参照して送信可否を判断していたのであるが、こちらは配布リストをCSVで書き出す方法よりもWebインタフェースからのモニタリングがやりやすい。DBアクセスが頻繁に発生するため、物凄い負荷になる。特に、参照アクセスよりも、更新処理が恐ろしく遅い。1通送信する毎に、送信済みフラグやら再送ステータスを書き込んでいたためである。スクリプトではなく、VisualCからコンパイルされたexeであったのでプログラム実行自体は高速な部類のはずであるが、5分で1000通程度の性能。(あれ?LotusScriptの場合と変わってないかも・・・送信前処理が違うから単純な比較できないけど)
さて、これらの実体験を参考にしつつも、今回どのような仕組みにしようかと思案する。
目標値としては、10分1000通がクリアできないと今回新たに開発する意味が無い。できれば1000通5分。10万通を半日で送れると、CRMツールとしてかなり現実的。複数サーバ運用でDB内のメッセージテンプレートやユーザリストを共有できるっていう(負荷分散上の)逃げ道も必要かな。

BASP21のFlushMailメソッドで送信時間を短縮できるという前提で・・・。
宛先リストを別ファイルで用意して、本文テンプレートに差込で?%