Strange slowness and formatting error in Changelog view

Issue #537 resolved
Gustavo Chaves created an issue

Hi there. I'm using RhodeCode 1.4.0b, installed on 2012-08-15.

On the biggest Git repository in this RC instance (24352 commits, 575MB) there is a strange slowness when I'm navigating to page 2 of the Changelog view. I'm going to attach two short videos showing the problem. In the first one I navigate in RhodeCode. In the second I navigate in the same repo using gitk.

Note that page 2 takes much longer to render and also that when it renders there is a strange whitespace at the top of the page and there are no branch lines along the left margin.

How can I investigate this further?

Comments (8)

  1. Gustavo Chaves reporter

    I've upgraded RhodeCode to d2f552429ef3. I also migrated the database from SQLite to MySQL and increased beaker.cache.sql_cache_long.expire to 86400.

    I could perceive no noticeable change.

  2. Marcin Kuzminski repo owner

    Hmm as for the white-space issue it must bee something in graph generation, hard to debug for me without having this repository.

    As for performance, how does the tricke below work for you ?

    diff --git a/rhodecode/lib/base.py b/rhodecode/lib/base.py
    --- a/rhodecode/lib/base.py
    +++ b/rhodecode/lib/base.py
    @@ -283,17 +283,17 @@ class BaseRepoController(BaseController)
         c.repository_forks: number of forks
         """
     
         def __before__(self):
             super(BaseRepoController, self).__before__()
             if c.repo_name:
     
                 dbr = c.rhodecode_db_repo = Repository.get_by_repo_name(c.repo_name)
    -            c.rhodecode_repo = c.rhodecode_db_repo.scm_instance
    +            c.rhodecode_repo = c.rhodecode_db_repo.scm_instance_cached()
     
                 if c.rhodecode_repo is None:
                     log.error('%s this repository is present in database but it '
                               'cannot be created as an scm instance', c.repo_name)
     
                     redirect(url('home'))
     
                 # some globals counter for menu
    
  3. Gustavo Chaves reporter

    (Reply via gus...@cpqd.com.br):

    Unfortunately, I don't own the repository and cannot make it available. I'll try to dig it further.

    As for the patch, I applied it (on RC as of d2f552429ef3b<https://bitbucket.org/marcinkuzminski/rhodecode/changeset/d2f= 552429ef3bbbaa03e791fc50aa7a94c9b3c72>) but the tests were unconclusive.

    Before applying the patch I hit the first and second pages of the Changelog and got these timings for them to render completely:

    Page 1 - 7.9s Page 2 - 36.4s (particularly bad) Page 1 - 8.5s Page 2 - 15.0s

    After having applied it and restarted RC, I got these results:

    Page 1 - 6.0s Page 2 - 12.9s Page 1 - 5.4s Page 2 - 15.0s Page 1 - 7.0s Page 2 - 14.2s

    It seems a little better but discounting the "particularly bad" try above (which might have been a glitch), it doesn't seem to have solved the problem, I'm sad to say.

    2012/8/25 Marcin Kuzminski <issues-reply@bitbucket.org>

  4. Marcin Kuzminski repo owner

    HI can you try out latest version ? I made one big improvement receantly for the changelog page for git

  5. Gustavo Chaves reporter

    Great news.

    I'm preparing to upgrade from 1.4.0b to 1.4.0 in the following days. I'll let you know as soon as I can.

    Thanks!

  6. Gustavo Chaves reporter

    I've upgraded yesterday from 1.4.0b to 1.4.1. The performance was much improved but it had to do with a different thing... When I installed 1.4.0b for the first time I used SQLite. Later on I moved the database to a MySQL server using taps. I didn't notice though that this process did not create indexes in the MySQL database.

    So, when I upgraded yesterday I used mysqldiff to grok all the schema differences from my production database to a newly installed 1.4.1 instance. Then I noticed all the missing indexes and created them on production.

    I guess the missing indexes were the main cause of slowness in my instance, which is now resolved.

    With regards to the formating error I didn't notice it again. But the repository has evolved and it affected a particular page of the ChangeLog view. I'll open another issue if it ever come back again.

    This is solved now.

    Thank you.

  7. Log in to comment