On Tue, 13 May 2008, Lars Hjemli wrote: > On Tue, May 13, 2008 at 8:55 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> >> But please take into account that gitweb performance, and I guess any >> git web interface performance, is I/O bound and not CPU bound (at least >> according to what I remember from J.H. emails). So a little more >> processing is I think less important than avoiding hitting the repos. > > Yeah, that's a pretty convincing argument for "cache the data, not the > output", at least for gitweb (cgit never touches the repos to generate > the project list/search). First, this is less argument for "cache data" against "cache output", only against disregarding "cache data" for assumed performance reasons, while it "cache data" can be useful in some places. Second, gitweb's projects list page contains "Last Changed" column, and you _*have*_ to hit repositories for this data, and backwards compatibility prevents from removing that. You can configure gitweb in such way that project name, owner, and project description are read from single 'project_index' file with "gitweb: Allow project description in project_index file" patch. repo.or.cz can do this. On the other hand mechanism to scan directory, getting owner from filesystem owner (plus GECOS) or repository's gitweb.owner configuration, and project description from 'description' file in projects repository, allow to treat gitweb in similar way to mod_userdir i.e. as service. You don't need to register project with gitweb; you need only to create it in appropriate place (or put symbolic link there). kernel.org functions this way. I wonder how Freedesktop.org does it: it offers both gitweb and cgit interfaces, if I remember correctly... -- Jakub Narebski Poland -- 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
