On Oct 11, 2013, at 1:13 PM, Matthew Wild <[email protected]> wrote: > On 11 October 2013 11:28, Valérian Saliou <[email protected]> > wrote: >> Our server implementation (courtesy of Marco Cirillo aka Maranda) is also >> working well in production environment, with more than 300 unique users >> simultaneously using the module (and much more over a larger timespan). > > How is memory usage? If I recall you were storing each user's archive > entirely in memory.
Memory usage is pretty good. We don't see any difference (just a tiny one). We also configured the Lua GC to be triggered more often: AFAIK it's now being triggered when memory is multiplied by 1.25 (instead of the default x2 coming from Prosody, which was not efficient enough and caused allocated memory, which was not used at most, to grow rapidly). And yes, we're storing each user archive entirely in memory for retrieval efficiency. But we don't keep it in RAM if an archive is not used for a prolonged period of time. > >> Our >> server module has been coded from scratch, we considered the Prosody MAM >> module as too performance scratching for production and large-scale >> environments (as it serializes the whole message stanza before storing it as >> an XML/Lua object in DB and then unserialize it to send it back on retrieval >> - where on our side we only store the body and some critical information). > > MAM explicitly allows you to do this is you want. I'll defend Prosody > not only storing the body by default, as I think people would like to > preserve various extensions (off the top of my head: XHTML-IM, chat > markers, security labels, signatures...). I don't think either you nor > anyone on the Prosody team has done any benchmarks on our stanza > storage API yet, so judging performance just because you think it will > be slow isn't a valid technical argument :) > > In any case, rest assured that we'll be doing benchmarks before the > 0.10 release that this is targeted at, to be sure we do have the most > efficient storage solution for MAM archives. Well I'm just repeating what Marco told me. I did not do any benchmark on my side, but I suspect he judged this as not-efficient-enough just by giving a look to the code. > >>> Also in my todo queue are updates related to message hints. After >>> deletion and hints are in, I think we're ready to push for draft! > > Having had time to think about it now, and considering the general > consensus forming in this thread, I'm not sure deletion is going to > get in. A new XEP perhaps if you want to attempt it :) > All right. A new XEP might be a better option yes. > Regards, > Matthew -- Valérian Saliou Jappix & FrenchTouch Web Agency founder. Waaave Network co-founder. Uno IM product lead. More about me on my personal page.
smime.p7s
Description: S/MIME cryptographic signature
