"Node is a good choice for this kind of task. If the total size of all unique banners is relatively small you might even be able to cache the banners in-memory instead of doing backend cache requests."
Though, not very explicitly proposed; but I was thinking that the best plan would be to have both node and varnish on the proxy box. I'd rather not write a caching layer in node when varnish does a fine job at it; but I also think it's somewhat silly to have symmetric traffic on the proxy when I can avoid it by having varnish on box. And the amount of data is small enough that we can easily fit it into < 16GB RAM. (Probably less than 8; but I don't know how it's all going to work itself out in production.) ~Matt Walker Wikimedia Foundation Fundraising Technology Team On Thu, Sep 19, 2013 at 8:48 AM, Gabriel Wicke <[email protected]> wrote: > On 09/18/2013 06:06 PM, Matthew Walker wrote: > > Hey all, > > > > I've been scheming for a while on how to reduce the number of calls up to > > the server for CentralNotice. At the same time I want to greatly reduce > the > > number of objects I have in cache. > > > > To do this I propose to change the architecture to having an intermediate > > proxy server with a static head JS section in mediawiki page head. The > > proxy would map down all the variables to only what is required at the > time. > > +1 for limiting the application logic in regular text Varnishes, both > from a performance and risk management perspective. Having your own > banner proxies should make it easier to tweak its behavior to your needs > without the risk of taking down the entire site. > > Node is a good choice for this kind of task. If the total size of all > unique banners is relatively small you might even be able to cache the > banners in-memory instead of doing backend cache requests. > > Gabriel > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
