I am implementing an application called RadGrad (http://radgrad.ics.hawaii.edu) and the "degree planner" page takes 4-8 seconds to display:
Thinking that this was a problem with subscriptions, we implemented SubsManager for subscription caching. From profiling with Kadira, we now know that subscriptions are cached and that this is not a cause of slow page display times; going back and forth between the "home" and "degree planner" pages shows a consistent multi-second wait time, but no subscription-related events:
So we're trying to figure out what to try next (other than move to React), and one idea is to cache Templates as well as subscriptions. Arunoda showed an example of how this could help in a three minute YouTube video a while back:
https://www.youtube.com/watch?v=0EF2PAUrVvQ
Unfortunately, I can't find further details, so I'm asking the community for guidance. I am willing to pay the 4 second overhead to display the page the first time, as long as it displays quickly from then on. Are there blog posts, packages, or example code out there that we can use to implement Template caching?
I have personally never done this but have seen the video as well. You probably already found these resources, but if not, here you go.
Arunoda's discussion of this on meteor forums
Arunoda's template caching code
Discussion in ways to make blaze faster (virtual DOM, template caching, etc.)
Post back if you get something effective in place!
Related
Before I get to the question, let me say that I saw a similar question here with a fairly detailed response:
https://wordpress.stackexchange.com/questions/115211/loading-wordpress-stuff-on-laravel-site
And it was the closest thing I have found on the web to what I'm looking for, but the potential solution looked like it might end up being so laborious as to not be worth the time. Here is my situation:
I develop and maintain a small custom SaaS program that typically functions on a subdomain of a client site (say, software.client.com). The latest version of the code was rewritten using Laravel and there were a lot of gains associated with that. In the past, when the program was basically procedural spaghetti, if we had a client with a Wordpress site on their primary domain, we ran some atrocious (by best-practices standards) hack-around code to pull the Wordpress header and footer onto the pages of my program - sitting, of course, outside the CMS - while modifying meta tags and doing a number of other things. It wasn't pretty but it worked.
Now I'm in a situation where I'd like to solve the same problem - that is, to at least pull the Wordpress headers and footers onto some of the Laravel subdomain views - but nothing I have found on the web so far has enabled me to make much progress in that direction. I have found a lot of tutorials explaining how to integrate Laravel and Wordpress, or use one for frontend and the other for backend, etc., but nothing yet about the specific type of integration I'm talking about.
What I have tried so far is implementing some of the code I've used elsewhere into various parts of the Laravel codebase. Most of the recent experiments have been in public/index.php and in Controller methods. Laravel will allow me to get as far as including the Wordpress config, but if I attempt to go any further I cause a 500 error. Here's an example snippet that actually attempts to do more than I need, but I can't even get past wp_init(). Imagine the following code in a Laravel Controller method. The first two lines are OK, but:
public function index() {
define('WP_USE_THEMES', false);
require '/path_to/wp-config.php';
$wp->init(); // from here on, 500 errors occur
$wp->parse_request();
$wp->query_posts();
$wp->register_globals();
// And then, at some point, I would call and modify get_header()
(I didn't really expect this to work from the Controller, but it doesn't work from anywhere else in the codebase I've tried either.) This is not a situation where I want to hand off control from Laravel to Wordpress for these URLs (I need Laravel functions / DB queries and more flexibility, and I know I could just do that hand-off through public/index.php and routes.php if it would solve the problem). And for these intallations, I don't need to grab posts or other items from Wordpress. I would just like to find a way to pull the header and footer into these views directly from Wordpress while maintaining control of the views in Laravel. If I can't, among other things, the design team will end up rebuilding headers and footers for every program install on a Wordpress client (for the time being) and they will have to make changes in at least two places when things are modified or updated.
If we have to, we will find a way to live with that until the next program version rollout, but if I can build a solution in what my superiors will deem a reasonable amount of time, we would all be happier. I hope that I have just missed something simple somewhere and I will be embarrassed to find out that I could have solved this in less time than it took to explain the problem. Thank you for any and all helpful responses and potential solutions.
You're not going to be able to cleanly merge the two codebases together. That would cause a disaster.
The complexity of the solution depends on the complexity the information you need to share. The simplest solution possible would be to write something custom to WordPress that builds a document with no body data and just supplies a token, like {!! $body !!}. Then, in Laravel, you can do an HTTP request to localhost to fetch this tokenized content. Store the result in a memory cache and use Blade to render the final view.
Essentially, my suggestion boils down to: Create a Blade layout with WordPress.
There's a thousand different ways to do this, and all of them are wrong.
:)
We are currently having issues with long loading times in admin-mode when there are 40+ editors hacking away in our WP backend with 4000+ pages. Since we cannot use the cache here, we need another approach.
I wonder if it is possible to make the whole 'Publish'/'Update' being asynchronous instead of making a post?
I've started to look into this:
https://github.com/techcrunch/wp-async-task
However, I don't know how to implement the correct behavior.
Have this been done before?
BR / Henric
I know the question sounds a little weird, but, please, read along. I have a store based on wordpress, woocommerce and wpml - currently in two languages but with plans to add another 3. The theme is quite huge with a lot of custom integration like Infusionsoft, Xero and more. About 50 plugins, 1100 product and 1700 posts. The number of posts and products will most likely double in the near future once we add another 3 languages. The overall setup is already kind of slow although we have enough server resources: 12 cores and 31 GB of ram. On top of this, I'm looking to integrate some sort of multi store and multi domain functionality. The multi store functionality will also require to be multilingual (wpml). There are two solutions to create the multi store functionality and none of them seems to be ideal and easily replicable without hacking more into woocommerce and wordpress.
1. Another install of wp, woocommerce, wpml and then using the woocommerce API to transfer the orders, stock, etc. back to the main site.
2. Wordpress multisite - from what i read is quite buggy with woocommerce and wpml.
As a developer myself, I feel this is a overkill for the wp, woocommerce and wpml. Especially if we take into consideration that Opencart or Prestashop comes with this functionality by default - without any kind of complications. But maybe, just maybe I am missing something really clever. Did anyone faced a similar setup ? What are your thoughts about developing such a complex setup in Wordpress and Woocommerce? Do you guys think it's imminent to move to another solution like Opencart, Prestashop or Magento ?
I would really appreciate your feedback about this!
Cheers
What i would do here is investigate why the website is slow first before adding hardware to the issue. Wordpress is a great base to start with but the same as all db driven websites needs optimization as the website grows.
There are many techniques for the below so ill just point to ideas and you can re-search them yourself and decide whether they suit your website.
Test here:
http://www.webpagetest.org/
To test your server code:
Use something like microtime to measure processes especially wp queries. http://php.net/manual/en/function.microtime.php
Where possible use caching (server caching) - possibly use varnish to cache product pages and serve static pages in place of dynamically created pages.
For expensive queries like post-archives use wp-transients or your own object caching.
To test browser code:
This is probably where you will see the greatest timesavings if you have 50 plugins. Unfortunately dev's love to hook js files, css files to the footer/header. This can be a significant load time. Investigate what you can remove from your templates (un-used js scripts, css files, etc) and de-queue them. For more savings see if you can isolate the css / js actually needed for the page out of the files present - combine into 1 file of each. Most of the time you will need the header/ sidebar css and some text styles but you are loading an entire themes stylesheet.
Pretty essential:
investigate your browser caching strategy.
https://developers.google.com/speed/docs/insights/LeverageBrowserCaching
Fun project:
Did you know you can load images/js/css to the cache using js? Pre-loading!
Maybe look at post-archives that require a lot of images and see if you can preload the "above the fold" content - your user will get a pretty quick browser load time and by the time they navigate below the fold the next batch of images should be cached (if you are combining with lazy load techniques)
This might save you the need to use extra servers but if you have to look at sharding rather than using a api to transfer data using php (i presume woo commerce api uses?)
As I mention in an earlier question, I am having trouble with the performance of a web site... Some SQL queries are killing the server. But, as the title of this post mention, I looked at the OutputCache page directive to improve performance of the site.
Although, I came across some questions regarding this directive:
1- If I have a web-user control that declares an OuputCache directive in a page that has one too, which one will "win" ?
2- What's the best pratice regarding the duration ? I'd love to have a sliding window too.
Thanks for your help and please visit http://www.developerit.com
On a request where neither are cached, both the page and the control will be created, and then added to the output cache. If the page is cached, the control will not be created, regardless of whether it's in the cache or not--its markup is contained in the cached copy of the page. If the page is not cached and the control is, the cached markup of the control will be used in the page.
Here's a good article on Output caching: https://web.archive.org/web/20211020111708/https://www.4guysfromrolla.com/articles/121306-1.aspx.
Generally, you seem to be looking at Page and Fragment caching. What you want to do is cache the Page, if you can, as that will give you the best performance benefit. But, if you have regions on the page that must change dynamically per user, eg: you are saying 'Hi {username}' at the top of the page, then you need to look at Fragment caching.
Fragment caching is not as effective as page caching, since the output has to be stitched together from cached info and dynamic info, but it's usually still MUCH better than NO caching!
It's a bit of an art, to tweak the caching depending on what the page does and the load on the database, but it can make a page load many Orders of Magnitude faster than non-cached.
FYI - if the db queries are killing the site you may want to also look at taming them and/or caching their output individually, so that you don't have to keep hitting the database for the same information.
Also understand the 'varyByParam' for caching is pretty useful too - say you have a page in 3 languages, you can cache a page for each language by using the varyByParam, as long as your Url some sort of language component that the varyByParam can pick up.
HTH,
Lance
I built an online news portal before which is working fine for me but some say the home page is slow a little bit. When I think of it I see a reason why that is.
The home page of the site displays
Headlines
Spot news (sub-headlines
Spots with pictures
Most read news (as titles)
Most commented news (as titles)
5 news titles from each news category (11 in total e.g. sports, economy, local, health
etc..)
now, each of these are seperate queries to the db. I have tableadapters datasets and datatables (standard data acces scenarios) so for headlines, I call the business logic in my news class that returns the datatables by the tableadapter. from there on, I either use the datatable by just binding it to the controls or (most of the time) the object converts it to a list(of news) for example and I consume it from there.
Doing this for each of the above seems to work fine though. At least it does not put a huge load. But makes me wonder if there is a better way.
For example, the project I describe above is a highly dynamic web site, news are inserted as they arrive from agencies 24 hours non-stop. so caching in this case might not sound good. but on the other hand, I know have another similar project for a local newspaper. The site will only be updated once a day. In this case:
Can I only run one query, that would return a datatable containing all the news items inserted for today, then query that datatable and place headlines, spots and other items to their respective places on the site? Or is there a better alternative around? I just wander how other people carry out similar tasks in the most efficient way.
I think you should use FireBug to find out what elements are taking time to load. Sometimes large images can ruin the show (and the size of the image on screen isn't always relative its download size).
Secondly you could download the Yahoo Firefox plugin YSlow and investigate if you have any slowing scripts.
But Firebug should give you the best review. After loading Firebug click on the 'Net' tab to view the load time of each element in the page.
If you've got poor performance, your first step isn't to start mucking around. Profile your code. Find out exactly why it is slow. Is the slowdown in transmitting the page, rendering it, or actually dynamically generating the page? Is a single query taking too long?
Find out exactly where the bottleneck is and attack the problem at its heart.
Caching is also a very good idea, even in cases where content is updated fairly quickly. As long as your caching mechanism is intelligent, you'll still save a lot of generation time. In the case of a news portal or a blog as opposed to a forum, your likely to improve performance greatly with a caching system.
If you find that your delays come from the DB, check your tables, make sure they're properly indexed, clustered, or whatever else you need depending on the amount of data in the table. Also, if you're using dynamic queries, try stored procedures instead.
If you want to get several queries done in one database request, you can. Since initially you wont be showing any data until all the queries are done anyhow, and barring any other issues, you'll at least be saving time on accessing the DB again for every single query.
DataSets hold a collection of tables, they can be generated by several queries in the same request.
ASP.NET provides you with a pretty nice mechanism already for caching (HttpContext.Cache) that you can wrap around and make it easier for you to use. Since you can set a life span on your cached objects, you don't really have to worry about articles and title not being up to date.
If you're using WebForms for this website, disable ViewState for the controls that don't really need them just to make the page that little bit faster to load. Not to mention plenty of other tweaks and changes to make a page load faster (gzipping, minimizing scripts etc.)
Still, before doing any of that, do as Anthony suggested and profile your code. Find out what the true problem is.