Max - good answers re: caching concerns. That leaves studying if the bytes
transferred on average mobile article view increases or decreases with lazy
section loading. If it increases, I'd say this isn't a positive direction
to go in and stop there. If it decreases, then we should look at the
effect on total latency, number of requests required per pageview, and the
impact on backend apache utilization which I'd expect to be > 0.
Does the mobile team have specific goals that this project aims to
accomplish? If so, we can use those as the measure against which to
compare an impact analysis.
On Mon, Feb 11, 2013 at 12:21 PM, Max Semenik <maxsem.wiki(a)gmail.com> wrote:
On 11.02.2013, 22:11 Asher wrote:
And then I'd wonder about the server side
implementation. How will
frontend
cache invalidation work? Are we going to need to
purge every individual
article section relative to /w/api.php on edit?
Since the API doesn't require pretty URLs, we could simply append the
current revision ID to the mobileview URLs.
Article HTML in memcached
(parser cache), mobile processed HTML in memcached.. Now individual
sections in memcached? If so, should we calculate memcached space needs
for
article text as 3x the current parser cache
utilization? More memcached
usage is great, not asking to dissuade its use but because its better to
capacity plan than to react.
action=mobileview caches pages only in full and serves
only sections requested, so no changes in request patterns will result
in increased memcached usage.
--
Best regards,
Max Semenik ([[User:MaxSem]])
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l