Issue #36: Displaying big changesets/out of memory
| Reported by: | Bernhard Weitzhofer |
| State: | new |
| Created on: | 2014-09-10 12:33 |
| Updated on: | 2014-12-08 23:19 |
Description
We have to manage a handful of rather big Git repositories (>1GiB, don't ask), which our untuned test-instance of Kallithea handles just fine - with one exception: displaying big changesets in the browser.
Kallithea warns about this (after a minute or so of occasionaly heavy CPU usage): "Changeset was too big and was cut off... ", but leaves the option to "Show full diff anyway", which in our case leads to more heavy CPU usage and out-of-memory-errors sooner or later.
This enables users only having read access to easily bring our server to its knees.
I'd argue that there is no common use case requiring to display gigabytes of diff in the Browser. Would it be sensible to add an option that disables showing the full diff (or otherwise handle this more gracefully)? Or is this just a misconfiguration on my part?
Attachments
Comments
Comment by Mads Kiilerich, on 2014-09-10 12:49
The default ini file has cut_off_limit = 256000 but there is no way around having a server that is big enough to handle the repo. I don't use git and do not know if it could be used in a more efficient way.
Comment by Bernhard Weitzhofer, on 2014-09-10 13:38
Thanks for the quick response!
I get (of course) that the server should be able to handle the repos, but I'd like to add:
-
As far as I can tell, displaying big diffs is by far the most resource-hungry operation in Kallithea (I reckon this is true for hg repos as well), and it seems odd to have to dimension a server around this single requirement - especially since in my opinion there is no real use for gigabytes of diff in HTML format.
-
cut_off_limit seems to get ignored when asking to Show full diff anyway (disclaimer: haven't looked at the source yet)
EDIT: to clarify, the only cases where we have diffs of this size are the initial commits of our few big repos.
Comment by Mads Kiilerich, on 2014-12-08 23:19
What would that graceful handling be?