Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Execution timeout when the account has hundreds of posts #2

Closed
9 tasks done
think-in-universe opened this issue May 22, 2019 · 6 comments
Closed
9 tasks done
Labels
bug Something isn't working

Comments

@think-in-universe
Copy link
Contributor

think-in-universe commented May 22, 2019

Description:

  • Execution may timeout when the user has a large number of posts.
  • It's a scalability and performance issue
  • The speed is too slow to build the blog for some accounts

Solution:

  • Add travis_wait to avoid no log in 10 minutes issue
  • Incrementally fetch and generate blogs for the user whose blog is already generated.
  • speed up the static page generation by hexo
@think-in-universe think-in-universe added the bug Something isn't working label May 22, 2019
@think-in-universe
Copy link
Contributor Author

fixed by set the smart duration in production mode by checking whether the blog exists or not, and fetch blogs incrementally. This helps to dramatically reduce the time cost in daily update.

@think-in-universe
Copy link
Contributor Author

think-in-universe commented May 22, 2019

@think-in-universe
Copy link
Contributor Author

performance test log:

  • robertyan

    • 22s: normal
    • 36s: try to disable tags and categories, with previous posts by andrewma
    • 21s: try to disable tags and categories, with previous posts by robertyan
    • 24s, 21s: try to disable tags and categories, run hexo clean before build
    • 17s: disable tags and categories pagination
    • 23s, 25s: with pagination of 6
    • 18s, 21s: with pagination of 10
    • 27s: _partial cache removed, with pagination of 10
    • 27s, 28s: _partial cache removed, with pagination of 6
    • 39s: _partial cache removed, with pagination of 6, add sort categories
    • 22s, 31s: pagination = 6, sort categories and tags, add tag and category cache
    • 19s: disable tags and categories pagination, sort categories and tags, add tag and category cache
    • 87s, 50s: when disk and CPU are very busy
    • 17/19/22s: cache={widget: tag/category; layout: head/footer/script}, sort={categories, tags}, pagination=6
    • 25s: cache={widget: none; layout: head/footer/script}, sort={categories, tags}, pagination=6
    • 15/16s: cache={widget: all; layout: head/footer/script}, sort={categories, tags}, pagination=6
    • 12/13s: cache={widget: all; layout: head/footer/script}, format=timeline, pagination=10
    • 12/13s: cache={widget: all; layout: head/footer/script, component:item}, format=timeline, pagination=10
    • 8/10/11s: cache={widget: +profile; as above}
    • 7/8/14s: iframe=true, +above
  • andrewma

    • 6.43 min: with cache
    • 8.05 min: remove archive widget
    • 3.98 min: disable tags and categories pagination
    • 3.63 min: cache={widget: all; layout: head/footer/script}, sort={categories, tags}, pagination=6
    • 3.45 min: cache={widget: all; layout: head/footer/script, component:item}, format=timeline, pagination=10
    • 3.4 min: cache={widget: all; layout: head/footer/script}, format=timeline, pagination=10
    • 2.47 min: cache={widget: all; layout: head/footer/script}, format=timeline, pagination=20
    • 2.68 min: cache={widget: all; layout: head/footer/script; component: item}, format=timeline, pagination=20
    • 47/48s: pjax=true, +above
    • 16s: incremental

analysis:

  • by checking timestamp of cache, we know that cached_item works

incremental build test:

  • 2-days delta: 327 files generated, ~3 min
  • 1-day delta: 324 files generated, 3.22 min
  • no change: 731 files generated, 2.46 min

@think-in-universe
Copy link
Contributor Author

think-in-universe commented May 29, 2019

incremental build implementaion:

  • diff files with previous build
  • guess the files to generate based on new state
    • smart generation
      • archives
        • archive of this month: [change: yes]
        • archive of previous month: [change: no] --> quite some
      • index
        • all because the entire list moved: [change: yes]
      • tags
        • tags of the posts: [change: yes]
        • remaining tags: [change: no] --> not much --> widget iframe
      • categories:
        • categories of the posts: [change: yes]
        • remaining categories: [change: no] --> not much --> widget iframe
      • index.html: [change: yes]
      • widgets: [change: yes]
      • posts:
        • the latest posts: [change: yes]
        • the old posts: [change: no] --> quite some
    • use /data
      • need investigation ==> no need
    • widget as iframe
      • reduce regeneration of all the categories and tags
      • generate iframe widgets --> widgets/iframe
      • include iframes
      • display iframes as widgets correctly
    • skip later process if no page loaded or no pages are different
      • what if some posts are updated? ==> diff will find
      • compare the MD files with git diff
    • trigger travis build via command line 'travis'
  • build a dynamic site instead: so it's not hexo based
    • understand steempress /cnstm.org : blog --> steem, no opposite direction
  • questions:
    • how to let tags/categories/archives/posts page know that which needs to be changed?
      • how to compare with source and figure out the diff and which pages to change?
      • implementation steps:
        1. create a branch / repo for storing 'source', clone the branch into local before download
        2. use git command to find the markdown files that need to be updated
        3. use hexo APIs to fetch the [posts, tags, categories, and archives] to be updated
        4. update generators for [posts, tags, categories and archives]
        5. write the latest source into the 'source' branch or repo
    • how to write iframe_widget_src into widgets/.html?
    • how to implement robust iframe widgets, by supporting both iframe and ejs widgets?
    • the user expereince issue with the iframe widgets => use pjax widgets
      • load performance / network
        • speed up iframe loading
          • modify the iframe and other sources' loading orders
            • start too late, later than images
            • loading resources started too late, 2s after HTML loaded
          • iframe and bundle.js are loaded at the latest time => trigger rendering at the right time, after #content is rendered
          • remove bundle.js and bundle.css if needed => ignore
      • rendering sytle / auto-resize
        • guess the width of iframe body
        • set the width of iframe body at the earliest possible moment
        • cache iframe at client to speed up rendering
      • replace iframe based solution to pjax/ajax based solution
        • use pjax to build the components
    • how to enalbe multi-core building of hexo
    • user experience issus
      • tag page loading widget is slow ==> ajax is later than image loading
      • post previous / next post button is wrong
      • Netlify build failure

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant