We use cookies on this site to enhance your user experience. By clicking "OK, I Agree" or using our site, you consent to the use of cookies unless you have disabled them. View our cookie policy to learn more.
OK, I AGREE
TRACK
Dev Tools >
COURSE
Blackfire.io: Revealing Performance Secrets with Profiling

Using a Caching Layer & Proving its Worth

Video not working?

It looks like your browser may not support the H264 codec. If you're using Linux, try a different browser or try installing the gstreamer0.10-ffmpeg gstreamer0.10-plugins-good packages.

Thanks! This saves us from needing to use Flash or encode videos in multiple formats. And that let's us get back to making more videos :). But as always, please feel free to message us.
Previous Chapter

Next Chapter
Edit on Github

Whenever we make something more performant, we often also make our code more complex. So, was the property-caching trick we just used worth it? Maybe... but I'm going to revert it.

Remove the property caching logic and just return $this->calculateUserActivityText($user):

51 lines src/Twig/AppExtension.php
... lines 1 - 10
class AppExtension extends AbstractExtension
{
... lines 13 - 26
public function getUserActivityText(User $user): string
{
return $this->calculateUserActivityText($user);
}
... lines 31 - 49
}

And... we don't need the $userStatuses property anymore:

57 lines src/Twig/AppExtension.php
... lines 1 - 10
class AppExtension extends AbstractExtension
{
... lines 13 - 14
private $userStatuses = [];
... lines 16 - 55
}

We could stop here and say: this spot is not worth optimizing. Or, we can try a different solution - like using a real caching layer. After all, this label probably won't change very often... and it's probably not critical that the label changes at the exact moment a user adds enough comments to get to the next level. Caching could be an easy win.

Adding Caching

Back in AppExtension, autowire Symfony's cache object by adding an argument type-hinted with CacheInterface - the one from Symfony\Contracts\Cache. I'll press Alt+Enter and select "Initialize fields" to make PhpStorm create a new property with this name and set it in the constructor:

61 lines src/Twig/AppExtension.php
... lines 1 - 7
use Symfony\Contracts\Cache\CacheInterface;
... lines 9 - 12
class AppExtension extends AbstractExtension
{
... line 15
private $cache;
public function __construct(CommentHelper $commentHelper, CacheInterface $cache)
{
... line 20
$this->cache = $cache;
}
... lines 23 - 59
}

Down in the method, let's first create a cache key that's specific to each user. How about: $key = sprintf('user_activity_text_'.and then $user->getId():

61 lines src/Twig/AppExtension.php
... lines 1 - 12
class AppExtension extends AbstractExtension
{
... lines 15 - 30
public function getUserActivityText(User $user): string
{
$key = sprintf('user_activity_text_'.$user->getId());
... lines 34 - 39
}
... lines 41 - 59
}

Wow, I just realized that my sprintf here is totally pointless.

Then, return $this->cache->get() and pass this $key. If that item exists in the cache, it will return immediately:

61 lines src/Twig/AppExtension.php
... lines 1 - 12
class AppExtension extends AbstractExtension
{
... lines 15 - 30
public function getUserActivityText(User $user): string
{
$key = sprintf('user_activity_text_'.$user->getId());
return $this->cache->get($key, function(CacheItemInterface $item) use ($user) {
... lines 36 - 38
});
}
... lines 41 - 59
}

Otherwise, it will execute this callback function, pass us a CacheItemInterface object and our job will be to return the value that should be stored in cache.

Hmm... I need the $user object inside here. Add use then $user to bring it into scope. Then return $this->calculateUserActivityText($user):

61 lines src/Twig/AppExtension.php
... lines 1 - 12
class AppExtension extends AbstractExtension
{
... lines 15 - 30
public function getUserActivityText(User $user): string
{
$key = sprintf('user_activity_text_'.$user->getId());
return $this->cache->get($key, function(CacheItemInterface $item) use ($user) {
... lines 36 - 37
return $this->calculateUserActivityText($user);
});
}
... lines 41 - 59
}

I think it's probably safe to cache this value for one hour: that's long enough, but not so long that we need to worry about adding a system to manually invalidate the cache. Set the expiration with $item->expiresAfter(3600):

61 lines src/Twig/AppExtension.php
... lines 1 - 12
class AppExtension extends AbstractExtension
{
... lines 15 - 30
public function getUserActivityText(User $user): string
{
$key = sprintf('user_activity_text_'.$user->getId());
return $this->cache->get($key, function(CacheItemInterface $item) use ($user) {
$item->expiresAfter(3600);
return $this->calculateUserActivityText($user);
});
}
... lines 41 - 59
}

So... does this help? Of course it will! More importantly, because we decided we don't need to worry about adding more complexity to invalidate the cache, it's probably a big win! But let's find out for sure.

Move over and refresh. Boo - 500 error. We're in the prod environment... and I forgot to rebuild the cache:

php bin/console cache:clear

And:

php bin/console cache:warmup

Profiling with Cache

Refresh again. And... profile! I'll name this one: [Recording] Show page real cache. Open up the call graph: https://bit.ly/sf-bf-real-caching.

This time things look way better. But let's not trust it: go compare the original profile - before we even did property caching - to this new one: https://bit.ly/sf-bf-compare-real-cache.

Wow. The changes are significant... and there's basically no downside to the changes we made. Even our memory went down! You can also compare this to the property caching method: https://bit.ly/sf-bf-compare-prop-real-caching. Yea... it's way better

And really, this is no surprise: fully caching things will... of course be faster! The question is how much faster? And if adding caching means that you also need to add a cache invalidation system, is that performance boost worth it? Since we don't need to worry about invalidation in this case, it was totally worth it.

Next: let's find & solve a classic N+1 query problem. The final solution might not be what you traditionally expect.

Leave a comment!

Edit on Github
Previous Chapter
Next Chapter