Merge lp:~james-w/launchpad/drop-filecmp into lp:launchpad
| Status: | Work in progress |
|---|---|
| Proposed branch: | lp:~james-w/launchpad/drop-filecmp |
| Merge into: | lp:launchpad |
| Diff against target: |
98 lines (+14/-28) 2 files modified
lib/lp/archivepublisher/scripts/generate_ppa_htaccess.py (+6/-12) lib/lp/archivepublisher/tests/test_generate_ppa_htaccess.py (+8/-16) |
| To merge this branch: | bzr merge lp:~james-w/launchpad/drop-filecmp |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Robert Collins (community) | 2012-05-30 | Needs Fixing on 2012-05-30 | |
|
Review via email:
|
|||
Commit Message
Drop the use of filecmp from generate_
Description of the Change
= Summary =
When looking at generate_
for the common case that we suspect will be adding extra
I/O operations to the run of the script, and so not be helping
with germanium's load.
This branch drops that, and moves to just overwriting the current
.htpasswd file in all cases, even if it wouldn't change the content.
== Proposed fix ==
Do that.
== Pre-implementation notes ==
None.
== LOC Rationale ==
-14 lines.
== Implementation details ==
Deletes the code. Also drops the return value and the removal
of the file, because it will now always be renamed.
== Tests ==
Adjusts the test case for the old behaviour to just test
the new behaviour.
== Demo and Q/A ==
A run of generate_
private PPA should suffice.
= Launchpad lint =
Checking for conflicts and issues in changed files.
Linting changed files:
lib/lp/
lib/lp/
| James Westby (james-w) wrote : | # |
On Wed, 30 May 2012 22:35:20 -0000, Robert Collins <email address hidden> wrote:
> Review: Needs Fixing
>
> Do we have data on this? Replacing an unaltered file will cause apache
> to re-read it, which will increase load. That is, I believe, why the
> cmp is in there in the first place. Have we got data on how long the
> cmp is taking?
Good point. We have no data at this point, this was just something we
thought might help, but just based on considering the write side of
things, and not apache reading the files.
> I ask because this is exactly the sort of small tweak that can bite us rather hard.
Yeah, but so can performance optimisations done without data, such as
checking if the file has changed before overwriting it :-)
> Perhaps doing this under a feature flag will let it be phase in under
> examination and see if it has any impact.
If a feature flag is acceptable for this sort of thing then I agree that
it would be preferable to landing it without a trivial way to rollback
if it has an adverse affect.
Other ways to do that would be adding a config option, or a command line
option. A feature flag would definitely be cheaper if it is an
acceptable use for them.
Thanks,
James
| Robert Collins (lifeless) wrote : | # |
Feature flags are designed for this. I don't know if the cmp was added
based on data or speculation; its speculation that it was added on
speculation :)
Anyhow, lets feature flag this up, and get the load graphs on
germanium working before we test it, and subsequent to that we can
start to see if it is a net win, loss, or noise.
Unmerged revisions
- 15228. By James Westby on 2012-05-30
-
Drop the use of filecmp in generate_
ppa_htaccess. The common case in this script is for the file to have changed, as
it carefully looks for changed PPAs/tokens. Therefore confirming
that with filecmp is just extra I/O in the common case, and that
is certainly undesirable currently on germanium.

Do we have data on this? Replacing an unaltered file will cause apache to re-read it, which will increase load. That is, I believe, why the cmp is in there in the first place. Have we got data on how long the cmp is taking?
I ask because this is exactly the sort of small tweak that can bite us rather hard.
Perhaps doing this under a feature flag will let it be phase in under examination and see if it has any impact.