Time To First Byte (TTFB) is unstable

December 12, 2018 2.4k views
Server Optimization Ubuntu 18.04 Caching PHP

Hello!

I’ve deployed my site on a droplet.

All seems fine, I have TTFB ~80ms, which is great for me.

I use caching with simple “file” driver, so cache data is stored in the files on FS.

I’ve noticed that with time (probably when there is no FS activity, about an hour maybe), TTFB goes down to ~500ms (on the same page, with the same cache).

If I flush all the application cache, TTFB goes back to ~80ms.

Is it the normal behavior?
Should I use Redis for cache?

Thank you!

3 Answers

I’ve noticed that with time (probably when there is no FS activity, about an hour maybe), TTFB goes down to ~500ms (on the same page, with the same cache).

Do you mean it goes down to 50ms? Because 500ms is much higher than the TTFB you reported of 80ms with the same cache. Memory will definitely give you deterministic caching more so than “file” caching. So yes, Redis and/or Varnish will help you achieve that. The reason you can never guarantee a TTFB when caching on disk has to do with the fact that all VMs on a server share disk IOPS fairly. So someone else on the node could be serviced before you (or misbehaving). Memory on the other hand is guaranteed.

Cheers

  • @unixynet Thank you for your response,

    No, I meant 500ms, which is worse (that’s why I’ve written “go down”, sorry if it was confusing).

    I’ve tried Redis from the first day, but it gave the same ~80ms TTFB, that’s why I’ve decided to use a simple “file” caching.

    I can understand that VMs share disk IOPS, but I don’t understand why flushing of the file cache helps immediately.

    And it’s pretty unstable; today it was fine almost all day.

    Anyways, even if Redis would not provide TTFB performance in my case (no actual load), probably it will give the TTFB stability, which is good too.

    Thank you!

I can understand that VMs share disk IOPS, but I don’t understand why flushing of the file cache helps immediately.

Perhaps the disk is slow hence it’s faster when the stack doesn’t need to seek the files/objects off the disk (this is what happens when you flush it). Maybe run a non-aggressive benchmark against the disk to see if there are any irregularities.

Are you connecting to Redis via TCP or a socket? Try connecting to it via socket to see if that makes a difference.

Cheers

@unixynet I switched to Redis yesterday.

And today I’ve seen ~500ms with Redis…

So, I’ve debugged my code carefully and found a problem in it.

Thank you very much for your help and useful advice!

Have another answer? Share your knowledge.