I need some help with Cloudflare, I'm not being able to purge the cache using the prefix option. For example if I go to Cloudflare portal and go to Caching section -> Purge Cache -> Custom purge, then I select Prefix and put something like this www.myexamplesite.com/mypath. Nothing happens, the only option that is really purging the cache is by hostname and in that case I have to use www.myexamplesite.com but that's not a good option because it affects so many pages.
Does anyone know if there are "common" reasons for failing the cache purge by prefix? I haven't found any clue about the issue, so if you have any idea it could help to find a solution.
I had similar frustrations that in the end came down to capitalization.
The cache is case-sensitive and prefix matching is also case-sensitive. My solution was to purge all of the most common capitalizations that people might use for the given folder. You can have up to 30 prefixes per purge request, so it wasn't too bad to have it purge:
www.mysite.com/mymainfolder, www.mysite.com/MyMainFolder, www.mysite.com/MYMAINFOLDER
Any of those references that aren't used in your system won't have anything to purge anyway, so the extra clearing is not a performance problem.
Related
Laravel 8 has config files for auth, mail, broadcasting, queue, services, session .etc, but I am not using those functionalities for my specific application.
Is it fine to leave the config files (and corresponding .env settings) untouched, or is it better to delete those files?
I am talking about both in terms of performance, execution correctness and security, but not in terms of code readability here. In other words I am talking about "real effects to my application".
Short answer:
it's not recommended to do something like that if you don't wanna go out from laravel's ecosystem.
TL;DR:
Since Laravel version 5.1 there was some general changes about the configurations. It means it for your v8 as well.
In every today's laravel project you have bootstrap/cache folder, which includes some bootstrap/cache/.gitignore file for ignoring other files. That ignored (3-4) files are actually cached files, which were creating automatically, and you can't do anything about that in-the-box.
The bootstrap/cache/config.php file is responsible for all the configurations, and it's creating as from config/*.php config files, as well as from all the config files from vendored dependencies. It means, everytime when you're using your laravel app, that file will be created automatically using
all the project-specific configurations
all the vendored configurations
environment variables from .env.
Note: there might be a case, when some in-box package (like laravel's default mail.php config file) or some 3rd-party package (unlikely, but anyway) could not have their own config file, so in vendor core codes there may be a confidence, that it can get some configs exactly from their apropriate config/*.php file, so in that case it's not recommended to delete that. For example, when you're deleting config/mail.php, and you're using that, in both cases you'll have approximately the same cached config, except some small mail-config-features (optimization there only approx. ~60 lines of human readable lines), but in that case you can't use laravel's Mailing functionality.
The sense is that when you want to override some configs, you're just creating some own config file(s) (in general with the same name as it's in vendor's appropriate location), so that laravel can do caching from config/*.php, but not from vendor/username/package/path/to/config.php.
So for optimization, laravel doing that caching process once, and after whole usage it will retrieve conifigs only from bootsrapped bootsrap/cache/config.php configs.
That's why everytime you're changing something in some config/*.php file or/and in .env file, you need to clean (manually) and it will be created again automatically
OR just:
there's a in-build command like:
# this will clean all the application caches
php artisan optimize
# or only for cleaning and recreating config
# this is an old-school version, but still used
php artisan config:cache
All this means, that you don't need to delete some config file from config/*.php, because laravel will check is the cached file exists, (if not, then it will create caches anyway from vendor configs), and all the time it will read them from cached files.
Conclusion: All this means, that
that is not related with security and there's nothing to do about that
if you feel that decreasing the cached bootstrap/config.php file content from 1566 lines to 1500 lines it's a way of optimization, then you're free to do that, but you should know that it could make some problems in future.
Subjective recommendation: in human language, i don't recommend to do something like that. Anyway you can do that, may you can improve something, that couldn't do another contributors yet. But it will not give a real effect to your app.
We are using freeswitch to make outbound calls. For performance and better quality we have installed its mod_http_cache. And its caching the file and working fine. But the problem is sometime we need to change some audio files and so we also need to update its specific entry in freeswitch cache. So that freeswitch won't play older version of that file from cache.
The mod_http_cache is having method called http_clear_cache which empty the whole cache. But I don't want to clear the whole cache. I want to remove specific entry from it.
One way is to find the specific file entry in cache folder and remove it manually, but that's not ideal when we need to update cache for more than one file.
Can someone suggest some better way for this?
Thanks.
Add file version or creation data to the filename. Change it on update. But you should also change the link to the updated file of course.
I have been developing a web page named: directorioelectronico.com and I have specially issues now, I will be very grateful that someone can be help me.
The web page is loading very slow in the first loading (5,000ms - 20,000ms) (latest are speeded normally) I tried to install APC module but my host is shared and the administrator can not install it, so I resize realpath_cache_size to 2M and the performance is now better (4,000 - 16,000 ms) somebody knows how I can perform it much more?
In advance, Thank you very much for you help.
My issue was that my share host haven't APC cache and for symfony2 is mandatory have it for have a good load so I change my host provider and now I have a VPS where I can install APC and now it is very fast.
The first time a Symfony program is run with env=prod, it has to create a significant amount of cached code - parsing the routes, annotations, converting configurations files and preparing CSS and Javascript.
It will always be a lot slower the first time, so that the rest of the time it will be fast. If you can run it before the website goes live (eg, with app/console), then that work can happen offline.
After clear:cache the next call on the application will have to rebuild a number cached files. That can be slow - so why make a site visitor trigger it?
If you're clearing the cache in production, try using the cache:warmup command to pre-build the the cache. It will mean the next visitor won't have to wait while the heavy lifting is done.
Something like this should help:
$ php ./app/console clear:cache --env=prod
$ php ./app/console clear:warmup
More info in the Symfony documentation.
I'd also suggest to enable query and result caches for doctrine (did you install/active apc cache for your php installation?). This might further reduce the loading time. Just have a look here :-)
Also try to use a deployment script to automatically trigger the cache clear/warmup, mentioned above. This way you won't forget to call those.
Do you use assetic for css/js? Then combine those files, minify them via assetic filters
Good candidates for deployment scripts are ansible, capifony or just a simple shell script.
I'm trying to compare the performance of different Solr queries. In order to get a fair test, I want to clear the cache between queries.
How is this done? Of course, one can restart the server, I was curious if there is a quicker way.
I'm using version 4.2.1 and even with autowarmCount="0" the cache is not updated after doing a Dataimport.
In that case, on Solr Admin (usually http://localhost:8983/)
Go to Core Admin and click Reload.
When refreshed, you should see a green check mark on the "current" field.
Disable all the caches from solrconfig.xml.
Note that the Lucene FieldCache will still be enabled.
Just for thorough details
If you want to disable a cache (or all), comment out those sections in solrconfig.xml and restart solr.
example diable queryResultCache
<!--
<queryResultCache class="solr.LRUCache"
size="5000"
initialSize="5000"
autowarmCount="2000"/>
-->
I am using memcache.
I want to understand what is stored in Magento cache and how?
Do magento stores cache variable with website scope or store scope?
I have googled and greped the code but couldnt conclude anything,
Please if someone can direct me to correct links and path
Thanks & Regards,
Saurabh
If you go to the Cache Management section of the admin area you can see what it caches (configuration, layout configuration, block html output, translations, eav types, etc). I am no expert on Magento's caching mechanisms but here are a few random tidbits that might be helpful (maybe). (Also note that I am only familiar with Magento 1.3.x, not 1.4.x so things could have changed).
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configuration - This source for the configuration is varied. Your app/etc/local.xml, and all of the config.xml files (that are in each module's etc dir) are combined together to make one big configuration object. Then Magento reads from the core_config_data table to update the configuration object. Then the configuration is written to a cache file so that next time a request is made it doesn't need to open a ton of config files and hit the database. Somehow this info gets stored in a bunch of files under var/cache. For some insight do a ls var/cache/mage*/*CONF*.
Layout - This is a lot like the configuration... there are a bunch of xml files in the app/design/frontendOrAdminhtml/yournamespace/layout/ directory and all these are merged into one layout configuration object, then cached in the cache directory.
Block HTML - The actual html generated by a block is cached. Each block is able to decide how long it is going to be cached.
Lastly, to (not really) answer your question about if the cache is per website or store, I can't really say since I haven't had the need to setup a multi-website/multi-store shop yet. It looks like there may be some store/website-specific files, but I can't see that they are really organized in a logical way. For example, in one of my instances I see a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE0_DEFAULT_BLANK_SEO file and a var/cache/mage--f/mage---LAYOUT_FRONTEND_STORE1_DEFAULT_BLANK_SEO... but then again, I only have one store configured and those two files have the same contents. Good luck with that!
You could also use some of the very great memcached analysis and reporting tools available
http://code.google.com/p/memcached/wiki/Tools
The best solution I have come up with is to use a two level cache.
Consult app/etc/local.xml.additional to see how to put memcached server nodes in there. Note that within the <servers> tag you will have to have tags like <server1> and <server2> encapsulating each memcached node's settings.
<cache>
<backend>memcached</backend>
<slow_backend>database</slow_backend>
</cache>
In this way all cache is shared.
To clear it the way I do it is to:
1. shut down apache
2. connect to mysql and connect to the magento db and run truncate core_cache; truncate core_cache_tag.
3. I then bounce the memcached nodes.
4. I restart apache but I keep it out of the load balancer until I have hit it at least once to generate the APC opcode cache. Otherwise the load can shot up through the roof.
This all seems extreme but I have found it works for me. Clearing cache using the backend is REALLY slow. I have around 100k entries in the core_cache table and close to 1 million entries in core_cache_tag. If I don't do it this way sometimes I get strange behavior.
Your Memcache configuration in ./app/etc/local/xml will dictate what Memcache is actually caching.
If you are only using a the single-level cache (without ), then Magento will store its cache (in its entirety) in Memcache.
HOWEVER without the slow_backend defined - it is caching content, without cache_tags - ie. without the ability to differentiate cache items
Eg. configuration, block, layouts, translations etc.
So, without the defined, you cannot refresh caches individually, in-fact, you'll almost always have to rely on "Flush Cache Storage" to actually see updates take effect.
We wrote a nice article here which covers your very issue - http://www.sonassi.com/knowledge-base/magento-knowledge-base/what-is-memcache-actually-caching-in-magento/
Memcached is a distributed memory caching system. It speeds up websites having large dynamic databases by storing database objects in Dynamic Memory to reduce the pressure on a server whenever an external data source requests a read. A Memcached layer reduces the number of times database requests are made.
The caching is actually stored in the var/cache directory. There are a ton of directories in there (mage--0, mage--1, mage--2) and each directory has the cache files. Do a ls var/cache/mage*/* to see all the files.
Configure Memcache Magento 2
Magento 2 also supports Memcached for caching objects but it isn’t enabled by default. You need to make simple changes to the $Magento2Root/app/etc/env.php file to enable it.
In env.php, you will see a large number of PHP arrays with different settings and configurations. Open the file in your favorite code editor and locate the following code:
array (
session' =>
'save' => 'files',
),
Modify this chunk as:
'session' =>
array (
'save' => 'memcached',
'save_path' => '<memcache ip or host>:<memcache port>'
),
Note that the default value for memcache ip is 127.0.0.1:11211. Similarly, the default value for memcache port is 11211.
For complete manual please look into it:
https://www.cloudways.com/blog/magento-2-memcached/
https://devdocs.magento.com/guides/v2.4/config-guide/memcache/memcache_magento.html