There are two difficult things in computer science:
Hole punching falls into category #2 :)
The best approach is to start at the lower points of the stack and optimize up to the frontend of Magento.
Database and Filesystem
Should always be the first areas to focus on. Because. I/O.
MyTop is a handy Linux ...
You need to understand the clear distinction between these two products to understand how to use them.
APC is both an OPCode Cache and Fast Backend
Memcache is just a Fast Backend
Using APC as an OPCode Cache
Simply install the module on your server
pecl install apc
And enable it in your php.ini
echo "extension=apc.so" >> /usr/lib/local/php.ini ...
We just don't - at all. Ever. We'll say this over and over again but
Caching != Performance
Your site needs to be fast without the addition of FPC (or Varnish for that fact). There is always going to be a time when the content isn't primed (your scenario above).
On an unloaded store, page load times with FPC shouldn't be that much more impressive than ...
The below code programmatically flushes cache. It worked fine for me.
Case 1: Outside Magento
$bootstrap = Bootstrap::create(BP, $_SERVER);
$objectManager = $bootstrap->getObjectManager();
$_cacheTypeList = $objectManager->create('Magento\Framework\App\Cache\...
Is Varnish right for you?
Varnish isn't the be-all and end-all of Magento performance. Its great to offset load from bots & window-shoppers - but it shouldn't be your first port of call to actually making your store faster.
In fact, implementing Varnish should be the last performance modification to your store. Only drop it in once you are seeing the ...
This is below some basic structure for create custom cache type,
create one module with,
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="urn:magento:framework:Cache/etc/cache.xsd">
<type name="custom_cache" translate="label,...
You could use siege in combination with the sitemap.xml file, like MageSpeedTest does.
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 0.5 | sed 's/.*loc>\(.*\)<\/loc.*/\1/g' > urls.txt
curl http://yourmagentostore.com/sitemap.xml | sed 's/\<url\>/\<url\>\n/g' | grep 1....
After some digging around and some useful feedback on twitter I appear to have found some stuff out.
By default this is set-up to use a Zend Server feature Page Cache. It appears to be a feature almost completely set-up on the server with the only things in Magento being.
A clean function that calls. page_cache_remove_all_cached_contents
public function ...
This issue is still reproducible on Magento 2.0.0 Stable.
There is a feature in Magento 2 exception handling, which prevents rendering of broken blocks while all other blocks are still rendered. In developer mode it is disabled and all exceptions are displayed right in browser. In default and production modes, if exception occurs during block rendering, the ...
You don't have nearly enough RAM
We have about 240k products
Available ram: 6GB
You do not have nearly enough RAM for the amount of products you have. As a rule of thumb, we recommend at least 2-4GB RAM per logical core.
If you map out your possible memory usage:
64 PHP Threads with a max_memory of ~768MB = 24GB
240,000 Products ...
The "Flush Magento Cache" button will only flush out cache records based on their tags. This uses the Zend_Cache::CLEANING_MODE_MATCHING_ANY_TAG mode when calling clean on the cache backend.
The "Flush Cache Storage" button will flush the entire cache backing (where the backend supports it), using the Zend_Cache::CLEANING_MODE_ALL mode when calling clean on ...
Hardcoding the types is a bad idea. Instead you can use the same method used by the cache:flush and cache:clean commands. The cache manager class can also pull all the cache types for you, as done in the example below.
public function __construct(
$this->cacheManager = $cacheManager;
Flush and refresh: Refreshing means that it cleans up alle the invalidated cache keys. for example: when you save a widget while the cache is active you get a message that the cache is invalid. In this instance you don't need to flush the cache, just refresh it. Flushing means that it throws all the cache away, it will rebuild everything from scratch.
It depends on what your module is rendering. It boils down to
do not render private, customer specific data server side.
The exception being on completely un-cached pages (for example the customer account dashboad).
In summary, I think it boils down to approaching module creation with a client-side first mindset. It is best to assume that GET and HEAD ...
The easiest way I've found to holepunch CMS blocks in Magento Enterprise's Full Page Caching module has a few steps:
First, let's look at the directory structure required:
Block/Cms.php # We inherit almost all functions from the Mage CMS
block, only overriding the "getCacheKeyInfo" function.
We had the same issue after enabling FPC. The following error would occur:
Fatal error: Uncaught Error: Call to a member function getIdentities() on null in /vendor/magento/module-catalog/Block/Category/View.php:177
Not the most helpful error message but after some digging we found that this was being triggered by using the block type Magento\Catalog\...
I've created a module that will let you do more bulk operations from the admin. Clicking "Flush DB" will actually execute the flushdb command.
Otherwise you have to use command line to flush them "completely"
Response is marked as cacheable in \Magento\PageCache\Model\Layout\LayoutPlugin::afterGenerateXml only in case if there are no blocks in the layout of current page marked with cacheable="false" attribute, like this:
<block class="Magento\Checkout\Block\Registration" name="checkout.registration" template="registration.phtml" cacheable="false"/>
I assume you want to disable caching of the block by PageCache module. There are two options available:
Set cacheable="false" attribute in layout. But this will make the whole product page non-cacheable, probably is not what you want. Keep in mind existing issue with cacheable="false" on product view page
Use UI components
Do not set _isScopePrivate ...
Ok, for anybody else facing a similar issue, i think i've found the best way around it. As Nicholas Miller commented, my first port of call was to look into the Block Caching system.
I looked into how Magento uses the Cache Keys for each block to understand which blocks need to be cached. From here i tried writing a few Plugin/Interceptors to change the ...
It's because of the same cache keys begin used for both the standard and ajax page.
To prevent this turn of the cache when the page is loaded with Ajax.
Create a small custom module with the following files
It is true, you can see it mentioned the Dev Docs too if you want extra confirmation :
To create an uncacheable page, mark any block on that page as
uncacheable in the layout using cacheable="false".
You can see that on this page.
What Tim means is your local.xml file inside your template directory like /app/design/frontend/default/YOURTEMPLATE/layout
If the file does not exist, create it with the following content:
No cache is the best cache.
Whilst your question is "What is the best cache", your problem is "How can I make my store fast". Sadly your question will do nothing other than solicit opinion, rather than fact, so contrary to site etiquette, I'm going to solve your problem, not answer your question - because you are asking the wrong question.
Caching != ...
I quite agree with previous answers, but here's a short precision to complete it: Yes, apc can be used as both a cache storage engine and as a PHP byte code optimiser. But two points need to be clarified:
As a fast backend, the configuration directives used by APC to understand how it must save data are managed through the apc.user_% directives. The other ...
In the <full_page_cache> tag in your ./app/etc/local.xml just define
The lifetime is defined in seconds. You need to strike a balance between content freshness, performance and the amount of storage space you actually have available.
The default is 7200 seconds.
There is no way to create a placeholder in Enterprise Edition without having a module to contain the cache.xml which in turn is home to the placeholder definition. So if you need to have a custom hole in the full page cache, you will need to create a module to define it.
The sidebar cart block which is built-in does have a placeholder out of the box. That ...
The cache is flagged as invalid but not refreshed as a performance decision (flag rather than auto-refresh), if I remember correctly. There was some discussion about this when the behavior was introduced, but it was stated as "by design" by Magento, Inc. (whether good or bad design is left to the viewer!).
As a developer though it's possible to observe ...
I had this error today.
I cleared cache, checked log files, made sure I'm using the right database and all.
After searching for an hour I got the issue. There was another xml file named "local1.xml" lying in app/etc folder. I deleted it, and everything came back to normal.
Hope this helps someone, someday.
So I got a semi-official answer from Piotr on Twitter: https://twitter.com/piotrekkaminski/status/559784661602144256?cn=cmVwbHk%3D
It's fixed from 1.14.1.
"@airbone42 @bobbyshaw not sure.coming from old times, when https was only personal, non cacheable pages"