Home

March is a Mail ARCHiving system - hence the name.

It has undergone extensive redevelopment over time as we attempted to deal with a variety of performance issues and system limitations that have impacted the primary deployment.

March was developed to support Codehaus; with over 900 email lists and 500000 messages this represents a pretty good test bed for most mail system solutions.

The architecture elevator pitch

  1. You
  2. Apache HTTPD
  3. HAProxy
  4. Thin Cluster
  5. Ruby on Rails app
  6. Memcached
  7. Postgres 8.3+

Why Postgres 8.3+

Using a single database type lets us use database specific features such as

  • TSearch (TSearch is used for full-text indexing - GIN indexing)
  • stored procedures / functions
  • triggers (as part of our indexing solution)

It also means we can reduce our technology stack - no longer relying on Ferret / Solr means our memory footprint is smaller than if we had to split our

Why HAProxy

HAProxy is totally awesome for queuing connections while waiting for our thin instances to complete serving page requests. If any single thin stalls; HAProxy just sends to the other servers.

Using Apache's load balancing (in Apache HTTPD 2.0 at least) did not let us do fair load-balancing; a single stalled thin instance could take down the whole app

Why memcached

Disk I/O is phenomenally expensive. Codehaus' main mail server runs hot 24x7; by caching page fragments in memcached we lower the disk load on the server and deliver correct pages to clients much faster than ever before.

memcached lets us do some really neat caching things to ensure we're always getting up-to-date data.

Why thin

Thin seems to be the new actively maintained server of choice for Rails apps.

Why not mod-rails

Tried it. It locked up our whole Apache. Couldn't be bothered debugging it.

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (1)

 

  1. Mar 22, 2009

    Asanga Bandara Wijekoon says:

    Hi all, We can give more control to the administrators of the mail archive. Som...

    Hi all,

    We can give more control to the administrators of the mail archive. Some of them are,

    1. Be able to create, edit, delete the policies of controlling mails.

    2. Be able to see the traffic, who are the most users, kind of detail online in detail in reports. 

    3. Be able to define the time limit for the mails. As an example mails will automatically delete after we define this.

    4. Be able to easily change the storing area, mail server configuration kind of things.

    Other than these to read more emails we may need to tune the model relationships. Think some times we don't need record other column values we just need only to build the relationship we just can use records id. 

    [http://www.bencurtis.com/archives/2007/08/5-tips-to-speed-up-your-rails-app/            Tip 4: Magic is not the friend of processing efficiency ]