Simon Wistow (deflatermouse) wrote,
Simon Wistow

Mariachi revisited. again

Mariachi has scaling issues caused by the fact that it doesn't arbitarily break stuff up over month boundries because, well, threads don't stop just because it's the end of the month. That plus threading meant that it slowed to a crawl around the $n thousand messages mark, even when adding messages incrementally. This is sub-optimal.

A while back Ben Trott submitted patches to make Mariachi Atom aware which, AFAIK were never applied. That weekend I decided it would be better to let users write plugins without needing us to patch the main branch and ended up completely rewrting Mariachi to be Email::Store (for speed) and plugin (for extensibility) based which was nifty but, incredibly, even slower than before.


Then I got caught up in Buscador and the idea fizzled out but I think i might have another crack at refactoring Mariachi back to be plugin based and make some changes (one thread per thread page, oldest mails at chronological1.html and the latest as chronological${n}.html) to amke it faster and more intuitive (each message would be at ${message-id}.html). Then each plugin could take care of its own caching if needs be and how ever it wants - maybe using Netscape style summary files or DBM::Deep

Tags: afaik, break stuff, caching, chronological, dbm, email, html, intuitive, mariachi, message id, messages, netscape, nifty, plugins, refactoring, scaling, style summary, sub optimal, threading

  • Post a new comment


    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.