https://bugzilla.wikimedia.org/show_bug.cgi?id=73611
--- Comment #6 from Dan Andreescu <[email protected]> --- The slowness of limn is a complicated problem. It's not the caching, it has more to do with how it renders all the graphs even if they're not on a visible tab. I've tried to solve this but it leads to other problems. Limn will be replaced by a dashboarding system that we're trying to design right now. So it doesn't sound like there's anything simple we can do right now to make anyone's life better in the short term. One suggestion, though, is that we might want to try and make the metadata inferring logic in Limn a little smarter and able to handle a few more parameters. Right now, most graphs are added as a graphId to the dashboard. This graphId is looked up on the server, fetched and retrieved. It then loads one or more datasources which are fetched and retrieved. Those each load a datafile and that's why Limn takes forever. If you add "some valid URL" instead of a graphId to the dashboard, limn will infer the graph and datasource metadata making it much faster. So, one thing we could do is instead of just the URL we could pass some bare minimum parameters to make it draw what we want like: {url: '...', type: 'bar|world|line', title: 'Custom'} Like I say, we're working on a better way to dashboard, but if that's happening too slow, this is the most bang for our buck and I'd be happy to help make it happen. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
