How to optimize get helper and reduce TTFB

Developer help
1

I am working on a large ghost instance with 5000+ articles and use the following ghost version:
Ghost-CLI version: 1.13.1
Ghost version: 2.37.2

I keep getting logs such as:

[2019-12-28 20:33:31] WARN
NAME: HelperWarning
CODE: SLOW_GET_HELPER
MESSAGE: {{#get}} helper took 241ms to complete
level: normal
ERROR DETAILS:
    {"api":"v2.postsPublic.browse","apiOptions":{"limit":"3","filter":"tags:javascript+id:-5ceb78c9e17b4228e018650b"},"returnedRows":3}

Which are originated from get helpers similar to the ones used in the default casper theme

{{#get "posts" filter="tags:{{primary_tag.slug}}+id:-{{comment_id}}" limit="3" as |related_posts|}}

That being said, the load on any of our resources such as Nginx, db, etc seems to be normal.

Not sure if it is related but TTFB has dramatically increased and performance has been affected as a result.

I was wondering if there is a way to optimize get helper queries and/or improve performance for this particular case.

live site
theme-repo
additional config

Thank you.

1 Like
2

Hey @ahmadabdolsaheb :wave: The 241ms timing showed in the logs is definitely not the best performance, but should not be causing huge degradation in TTFB all of the sudden. One reason why it might be problematic is when a similar query is executed repeatedly during a single page load (for example in a loop).

Don’t see anything out of ordinary with the query itself. Think we’d need a little more debugging to narrow down the root of the issue. What were the timings in the Nginx logs for the long TTFB requests? Did you notice any spikes in the hosting server’s CPU, memory or disk i/o? Can you pinpoint the slowdown to any specific change on your side, e.g.: Ghost version update, configuration change in Nginx?

3

Thank you for your response @naz. Although we checked all of the above scenarios and could not find any irregularity, we were able to resolve this issue by changing our architecture. I will update this post with more details once our postmortem is finalized.

4

any findings you can share? Interested to know what your arch changes were.

I am seeing similar on a ghost blog running in the official docker image with sqlite in K8s behind Nginx Ingress.

Here’s one I captured from a Statuscake check on the site. seems to all be on http traffic, no https…maybe the redirect I set up, or because i started the blog http and switched to https…
:man_shrugging:

I am a total n00b with ghost and nginx tuning, so could totally be settings and such, so any hints on where to go bang my head, i’ll take!

thanks!

Screen Shot 2020-01-30 at 9.46.45 AM
Screen Shot 2020-01-30 at 9.46.45 AM2744×1120 302 KB

5

Have you considered going the HeadlessCMS route? At the end, you get a fully optimized static website while keeping the editor experience of writing in Ghost.

We can say it’s possible to have your cake and eat it too.

2 Likes
6

TIL that the logs inside the docker image provide more verbosity vs the stdout/stderr I posted above. will google more. Still wondering if the arch change above was a move from sqllite to mysql, or something different…

Screen Shot 2020-02-04 at 4.28.36 PM
Screen Shot 2020-02-04 at 4.28.36 PM2712×1596 431 KB

7

I’d love to know what your architecture changes were, I’m finding the same issue and would appreciate any insights you might have.

8

Thanks for your patience.

The TTFB issue was associated with some config on our hosting service.

I am still experiencing the slow get helper issue, but I believe as @pascalandy mentioned going HeadlessCMS would help with optimizing your get requests in general.

10

Thanks for sharing your conclusion. I felt it was something like this.

1 Like
11

Thanks for the update. As best as I’ve been able to determine, reducing the number of get helpers on a single template has been the most effective way to resolve the slow get helper warnings.

12

If I go headless with Gatsby;
does my membership will still work aka my stripe and mailchimp integration ?

Also, why my old wordpress is 3 times faster than my Ghost while Ghost team claim to be 6times faster than WordPress ?

I means, why Ghost don’t do responsive image and/or resizing image for different purpose like it is possible with Gatsby and WordPress and others…

13

Use a Content Delivery Network.
Optimize the application code.
Optimize the database queries.
Reduce HTTP requests.
Ensure a faster server response time.
Use Respond First, Process Later (RFPL) cache.. .

14

You almost answered yourself, Ghost position himself as a headless CMS, so as a backend. Everything related to the frontend would be relay to something like Gatsby.

To reduce the TTFB, at least with Ghost, it is mostly related to where you host it
Does the provider have a fast and reactive internet, does the server have a fast and reactive hardware (CPU, MEM, HD)…

After that, the nodejs code have to exploit async function and the theme also.