Re: Gitweb caching: Google Summer of Code project

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jakub Narebski wrote:
1. Caching data
 * disadvantages:
   - more CPU
   - need to serialize and deserialize (parse) data
   - more complicated
CPU: John told me that so far CPU has *never* been an issue on k.org. 
Unless someone tells me they've had CPU problems, I'll assume that CPU 
is a non-issue until I actually run into it (and then I can optimize the 
particular pieces where CPU is actually an issue).
Serialization: I was planning to use Storable (memcached's Perl API uses 
it transparently I think).  I'm hoping that this'll just solve it.
It's true that it's more complicated.  It'll require quite a bit of 
refactoring, and maybe I'll just back off if I find that it's too hard.
I'm afraid that implementing kernel.org caching in mainline in
a generic way would be enough work for a whole GSoC 2008.
I probably won't reimplement the current caching mechanism.  Do you 
think that a solution using memcached is generic enough?  I'll still 
need to add some abstraction layer in the code, but when I'm finished 
the user will either get the normal uncached gitweb, or activate 
memcached caching with some configuration setting.
By the way, I'll be posting about gitweb on this mailing list 
occasionally.  If any of you would like to receive CC's on such 
messages, please let me know, otherwise I'll assume you get them through 
the mailing list.
-- Lea
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux