How can I boost my performance in a CakePHP application? - performance

I'm currently using CakePHP for my training plan application but I have rendering times of 800 ms per page.
Do you have any tips on improving the performance?
Thanks in advance.
br, kms

In general the tool that will give you the greatest speed boost is caching, and CakePHP has a dedicated helper. The second most useful thing to do is optimizing the queries, only asking for the data you need - this can be done with the containable behavior.
You can find more detailed tips in this post.

Install APC, if you dont have it. that will instantly make it < 500ms. also without touching a single line of code.
Make sure your tables have all the proper indexes so that queries are as fast as they can be.
Next up look at some things about caching routes / urls as that is a huge drain.
Those will give you the most speed boost for the least amount of work

Have you tried any of the CSS/JS asset combiners for CakePHP? They combine/compress/minify your CSS/JS scripts and cache them where applicable. Here's one that's quite recent.
Not specific to CakePHP but you could go through all the factors in Google Page Speed, it will help you speed up your page loading times by suggesting what scripts you could combine and advice on how to reduce requests.
Other than that, look into the containable behaviour, see if you can cut out any necessary info/queries by only selecting what you need at any time.

This question is well-populated with information on speeding Cake up.

Related

Performance tools (Lighthouse) show very slow "Time to Interactive" on my Gatsby site. How can I improve it?

I'm looking for some help. My website is getting a very low time to interactive score (over 10 seconds).
It tells me I need to "Minimize main-thread work" and "Reduce JavaScript execution time".
Could you share some advice/tips on what I can do? How do you improve these metrics in your projects?
From googling, it seems like the main thing people do is code splitting, but Gatsby does that automatically already, right?
What else can be done?
You have quite a good Lighthouse Score. Try to test your page in anonymous mode to disable extensions.
However, you can improve it.
Load bundle-analysys and check what is inside your bundles. Try to find duplicated scripts or scripts you are not using.
Check importing strategy for the big scripts. If you are doing smth like import * from 'lodash' change it to import {groupBy} from 'lodash'
Find possibility to use lazy loading. This is not done automatically. The best candidates for this would be other pages of your site.
Then do revision for all scripts you have. Might be you can remove something that is not very important for you. Some people using jQuery for the querying page only.
Do general performance improvements:
Reduce image sizes (on your landing page you have one quite big image for the 450KB).
Reduce the number of fonts (you have 4 of them 547kb)
Think about removing analytics or change it for something simpler
For tracking performance changes use perfrunner or lighthouse-ci

CodeIgniter + Smarty - is it relevant?

I'm starting a new website, using CodeIgniter for the first time. In the views, there is PHP code written. I was thinking of completely separate the code from display, as I did few years ago using Smarty.
I found a template engine provided by CodeIgniter : http://ellislab.com/codeigniter/user-guide/libraries/parser.html
But inside of the page, I found this note :
Note: CodeIgniter does not require you to use this class since using pure PHP in your view pages lets them run a little faster. However, some developers prefer to use a template engine if they work with designers who they feel would find some confusion working with PHP.
So, I wanted some help to choose the right thing. Should I use pure PHP ? What would be the advantage of using a template engine like this one, when the coding style is already MVC ? Would it be better to use Smarty, that I already know a little ?
The website will need to be very secure AND very fast, a lot of AJAX will be used (I was thinking to install a websocket as well, but there is no link to the current question).
Thanks for your help !
If you require your application to be fast, then you've been quite inspired in choosing Codeigniter, as it's a very lightweight framework and it's going to solve most speed concerns quite easily, when caching isn't involved.
There's a saying that you shouldn't scale unless you need to, and I think that it applies very well here. Unless you're displaying megabytes of data, I don't see how choosing a templating engine might harm the overall speed of your application. In the event that it does happen, you can always have a look at caching some responses/various other bits of information or third party solutions (i.e. Gearman) which may be overkill for now.
If you want to learn something new, go with the Codeigniter templating library; if you need to develop something fast, use the tools that you know best. As a matter of preference, I love Twig, and there is a CI implementation for it, called Twiggy: http://edmundask.github.io/codeigniter-twiggy/
As for security, I'd say it's not as robust as an enterprise level framework, like Symfony or ZF2, which place higher emphasis on that. They are more complete packages in themselves, and with caching, they perform super-fast, but they come with a higher learning curve.
Update: What I meant by the the idea that unless you're displaying huge amounts of data you shouldn't consider the speed of templating engines is that there will be a negligible effect on your page rendering speed. Don't imagine that it's something that a user would ever notice, as the order of 0.0x in execution time isn't noticeable. Take a look here for a comparison between SMARTY and Twig: http://umumble.com/blogs/php/249/
0.058 seconds of execution time for Smarty vs. 0.083 seconds of execution time for Twig. Templating engines always carry an overhead, their facility is that they make development easier, and it helps out when working with designers.
If you want to go with a templating engine, I suggest Twig. http://twig.sensiolabs.org/

caching snippets (modX)

I was simple cruising through the modx options and i noticed the option to cache snippets. I was wondering what kind of effect this would have (downsides) to my site. I know that caching would improve the loading time of the site by keeping them 'cached' after the first time and then only reloading the updates but this all seems to good to be true. My question is simple: are there any downsides to caching snippets? Cheers, Marco.
Great question!
The first rule of Modx is (almost) always cache. They've said so in their own blog.
As you said, the loading time will be lower. Let's just get the basics on the floor first. When you chose to cache a page, the page with all the output is stored as a file in your cache-folder. If you have a small and simple site, you might not see the biggest difference in caching and not, but if you have a complex one with lots of chunks-in-chunks, snippets parsing chunks etc, the difference is enormous. Some of the websites I've made goes down 15-30 levels to parse the content in come sections. Loading all this fresh from the database can take up to a coupe of seconds, while loading a flat-file would take only a few microseconds. There is a HUGE difference (remember that).
Now. You can cache both snippets and chunks. Important to remember. You can also cache one chunk while uncache the next level. Using Modx's brilliant markup, you can chose what to cache and what to uncache, but in general you want as much as possible cached.
You ask about the downside. There are none, but there are a few cases where you can't use cached snippets/chunks. As mentioned earlier, the cached response is divided into each page. That means that if you have a page (or url or whatever you want to call it), where you display different content based on for example GET-parameters. You can't cache a search-result (because the content changes) or a page with pagination (?page=1, ?page=2 etc would produce different output on the same page). Another case is when a snippet's output is random/different every time. Say you put a random quotes in your header, this needs to be uncached, or you will just see the first random result every time. In all other cases, use caching.
Also remember that every time you save a change in the manager, the cache will be wiped. That means that if you for example display the latest news-articles on your frontpage, this can still be cached because it will not display different content until you add/edit a resource, and then the cache will be cleared.
To sum it all up. Caching is GREAT and you should use it as much as possible. I usually make all my snippets/chunks cached, and if I crash into problems, that is the first thing I check.
Using caching makes your webserver respond quicker (good for the user) and produces fewer queries to the database (good for you). All in all. Caching is a gift. Use it.
There's no downsides to caching and honestly I wonder what made you think there were downsides to it?
You should always cache everything you can - there's no point in having something be executed on every page load when it's exactly the same as before. By caching the output and the source, you bypass the need for processing time and improve performance.
Assuming MODX Revolution (2.x), all template tags you use can be called both cached and uncached.
Cached:
[[*pagetitle]]
[[snippet]]
[[$chunk]]
[[+placeholder]]
[[%lexicon]]
Uncached:
[[!*pagetitle]] - this is pointless
[[!snippet]]
[[!$chunk]]
[[!+placeholder]]
[[!%lexicon]]
In MODX Evolution (1.x) the tags are different and you don't have as much control.
Some time ago I wrote about caching in MODX Revolution on my blog and I strongly encourage you to check it out as it provides more insight into why and how to use caching effectively: https://www.markhamstra.com/modx/2011/10/caching-guidelines-for-modx-revolution/
(PS: If you have MODX specific questions, I'd suggest posting them on forums.modx.com - there's a larger MODX audience there that can help)

What's the optimal amount of queries an ExpressionEngine page should load?

I saw #parscale tweet: How many queries are you happy with for a home page? When do you say this is Optimized?
I saw responses that < 50 is good, 30 or less is best, and 100+ is danger zone. Is there really any proper number? And if say you do have > 50 queries running on your pages, what are some ways to bring it down?
I generally have sites that run the gamut that are under 50 queries and some more, though the "more" don't seem to be too slow, I'm always interested in making it faster. How?
How to reduce queries will vary from site to site, template to template, but there's been a few articles on EE optimisation and performance:
http://expressionengine.com/wiki/Reduce_Queries/
http://expressionengine.com/blog/entry/troubleshooting_site_performance_issues/
http://www.netmagazine.com/tutorials/optimise-your-expressionengine-site
http://www.leezilla.net/post/12377053779/ab-seeing-your-sites-performance
http://eeinsider.com/articles/using-cache-wisely-with-expressionengine/
But if you've done all that and still need to speed things up, then your next step is to look at add-ons like CE Cache.
Thing to remember is not all queries are created equal. You can have 1,000 queries that do very little in the way of impacting performance, or a single query that can slow everything way down.
In EE its actually better to look at the template debug output and identify key slow down spots in the template build then to always focus on just the query count.
As others have pointed out products like CE Cache, Solspace's Template Morsels, or even adding a varnish caching server in-front of an intensive EE web site can do wonders, though with the added work required to fully get a varnish setup in front of EE setup, I would currently stick to the other solutions/directions first.
There is not a magic query number. In my opinion, your server environment dictates what can be supported. The more resources you have, the more complex your code can be.
With that said, there are lots of options you can use if issues do arise on an EE website. The links in the answer above give you a solid list but here are some first things to check:
Remove search:field_name="" parameters
Reduce use of channel tags, combine if you can
Add disable="" parameter to channel tabs to disable what you don't need
Reduce use of embeds
Turn off all EE tracking code
Stop using advanced conditionals if you have a channel tag inside
Following on from Nevin's point. I find that the JB Graphite is a huge help, it turns the debug output into a pretty graph, so you can easily spot bottleneck queries.
http://devot-ee.com/add-ons/jb-graphite
I'll expand on MediaGirl's point number 6 - you can often greatly simplify conditionals by using Croxton's Ifelse and/or Switchee add-ons. Definitely worth a look.
I used CE Cache on a really intensive build and it reduced page load from 6 seconds to 0.7 seconds. Awesome addpon, with incredible documentation and the best support you can get anywhere.

Why is codeigniter $this->load->view rendering so slow?

I have been using codeigniter for quite sometimes and i really love it. But for some reason i am not sure why but rendering a view in 1 of my application takes 18-23 whole seconds. Well i really wonder why as such time is to be taken for rendering the output.
I am sure about this as i measured the time from it reaching the Index Page till the data collection / preparation from the system. All took not less then a second. Just this rendering of the view page screwed up - taking 19 / 23 random seconds.
I really want to understand why as so and will like to get a proper through solution to work around on the same.
As for now i am caching the output and storing it and playing around with it but i too know it is not so full proof solution. There must be a way to analyze as where and why the rendering takes so much time on the server. If anyone knows anything about the same, please please do update / share on the same.
Have you tried using XDebug? There are a lot of online resources for how to use it in profiling your PHP apps, such as this one by Eric Hogue.
But if you included some sample code of what is happening in your controller and view then perhaps we could offer some specific guidance in this instance.
Removing a call to $this->carabiner->empty_cache(); speeds up our views quite a bit.

Resources