グロムニオがメールボックスのパフォーマンスを向上

すでにコミュニティリリースに含まれており、まもなくパッケージ化され、すべてのgrommunioのお客様にご利用いただけるようになります：grommunioのメールボックスデータベースの処理方法の変更により、メールボックスのパフォーマンスが大幅に改善されます。

問題は複雑ですが、広範囲に及んでいます：例えば、会議の準備のように、複数のユーザーが同時にメールボックスに長い検索クエリーを実行する場合などです。一度に一人のクライアントだけがメールボックスのデータにアクセスし、変更を加えることができます。この “シリアル “アクセス（つまり、次々にアクセスすること）は、特にデータセットが大きい場合（そして同時にアクセスしたいクライアントが多数いる場合）、長い時間がかかる可能性があります。この問題はグロムニオに限ったことではなく、原理的にはすべてのウェブ・サービスやメール・サービスに当てはまる：一貫性のあるデータが欲しければ、アクセスを次々に処理しなければならないし、高いパフォーマンスが欲しければ、アクセスを並列化しなければならない。しかし、このジレンマを解決するスマートなソリューションがある。グロムニオはそのひとつを導入し、パフォーマンスの大幅な向上を実現した。

書き込みと読み取り専用：シリアルかパラレルか？

問題の解決策：書き込みアクセスと読み取り専用アクセスを区別する。読み取り専用アクセス（たとえば、メールクライアントが共有フォルダーを更新する場合）は、サーバーが複数のクライアントに同時に並行して許可することができ、キャッシュも可能である。そうでない場合、データに矛盾が生じたり、あるクライアントが他のクライアントの変更を上書きしたりする可能性がある。

これを技術的に実装するには、grommunio（あるいは他のメール・データベース・サーバー）がどのように動作するかをある程度理解する必要がある。grommunioでは、メタデータとユーザのメタデータのキャッシュのために中央のMySQLデータベースがあります。

また、ユーザーごとにSQLiteデータベースがあり、すべての電子メールを含む特定のユーザーデータが格納されています。個々のユーザーにとっては、メールボックスの中心的な構成要素でもあるが、同時に多数のリクエストが来た場合にはボトルネックになることもある。とはいえ、このシステムは柔軟性があり、必要に応じて拡張することができ、グロムニオの高いメールボックス・パフォーマンスの重要な一部となっている。

しかし、例えばクライアントが大きなメールボックスで検索を行った場合、検索要求が完全に処理されるまで、他の要求に対してブロックされる。サーバー側ではMutexを使ってこの処理を実装しています。他のクライアントは待たされ、最悪の場合タイムアウトになり、ユーザーにエラーメッセージが表示されます。

状況判断を行う管理サーバーのおかげでメールボックスのパフォーマンスが向上した。

データベースが変更されないため、検索クエリや同様の読み取り専用アクセスではミューテックスは意味をなさないので、grommunioの開発者はこのボトルネックを取り除くソリューションを実装した。開発者は、この目的のために管理サーバー(exmdb)を適応させた。このサーバーは複雑で、すでに120以上の関数でアクセスを調整している。読み取り専用アクセスの並列化を組み込むために、開発者は18,000行以上のコードを適応させなければならなかった。以前は1つのメールボックスにつき1つのミューテックスで競合を防いでいたが、時には輻輳を引き起こしていた。新しいシステムは「大きな」ミューテックスなしで管理し、代わりに各リクエストを検査し、安全に並列化できるかどうかを状況に応じて判断する。

“このアプローチは、特に日常業務において、共有メールボックスを使用して作業するすべてのチームにとって、より速く、より柔軟で、顕著であることが証明されました。典型的な例は、チーム・ミーティングの共同準備で、参加者全員がミーティング前の数時間に互いを素早くアップデートしたい場合です。しかし、これはほんの一例に過ぎず、ユーザーは、この変更によって大幅にスピードアップした他の状況について、熱心に語ってくれます。「とグロムニオCTOのマイケル・クロマーは言う。

その他のgrommunio **機能**についてはこちらをご覧ください。