I am using the Bitnami Magento 1.9 Stack and want to disable every kind of cache. I made these attempts:
I disabled Magento Caching (as described here)
I disabled Apache2 Caching (as described here) for (html|htm|js|css|phtml|php) and checked the HTTP-Header as described here
I disabled Browser Caching with Clear Cache
Unfortunately, my phtml-files are still being cached. CSS- & JS-files are gladly not changed anymore.
Is there any further cache that I have forgotten to disable?
I found one last cache which I had not yet disabled:
OPcache
It is installed by Zend.
To disable this cache, open the file php.ini (in my case C:\Bitnami\magento-1.9.2.4-2\php\php.ini) and set
opcache.enable=0
(solution from Bitnami Wiki)
Related
for very first time I have problem like that.
I tried to make staging envirioment with Prestashop 1.6 which production server use Litespeed Ent. with LSCache. My staging use openlitespeed, but on document I have litespeed-cache: hit - so it's working.
After problems with CSS, Unexpected char with ESI Block I decided to uninstall module. What I did:
Purged All Pages, Entire Cache Storage,
Disable cache system in module,
Disable module (I got info about .htaccess modyfication)
Checked .htaccess
Checked /tmp/lscache dir - doesn't exist
After that, I have same problem - on homepage, many products I can see ESI block at the begining document and info cache: hit it means still working...
Any ideas?
You can use PrestaShop on OpenLiteSpeed but it will not work with cache since OLS doesn't support ESI. For the OLS case, the default cache folder is located /usr/local/lsws/cachedata/, please try to remove the folder and restart the web server.
I am trying to get a simple apache stack running and came across something I have not seen before. This is an AWS instance running the Bitnami LAMP stack. If I create an incomplete html file as:
<h1>Something Here</h1>
Apache is prepending to the response. E.g.
<head/><h1>Something Here</h1>
I am serving an angular2 app from this stack and loading of the component templates is failing since they are being seen as malformed. Does anyone know what apache setting or module might be doing this?
Thanks
PageSpeed is the one that's adding that <head/>. PageSpeed is enabled by default on the Bitnami LAMP Stack.
This is added by the default mod_pagespeed add_head filter. You can disable it adding the line below to /opt/bitnami/apache2/conf/pagespeed.conf:
ModPagespeedDisableFilters add_head
However, note that this filter is needed for many other filters which will only write contents in the element.
You can also disable PageSpeed as explained in the guide below to check that the header disappear:
https://docs.bitnami.com/aws/infrastructure/lamp/#how-to-disable-the-cache-in-the-server
Recently I have been plagued by an error on committing to a single SVN repo using TortoiseSVN (1.8.7.25475) or AnkhSVN (2.5.12471.17):
Error running context: The server sent an improper HTTP response
Here is a screenshot of the error in TortoiseSVN:
The pixels differ of course, but the error is the same in AnkhSVN.
This only seems to affect attempts to commit modifications, not additions or deletions; and I can commit mods to several other SVN repos on the same server just fine.
Since my teammates continue to commit mods to the repo in question and the issue has only struck my commits to that repo, I tried committing simple mods after a fresh checkout of the repo: a few one-mod-at-a-time commits worked, but then...same error.
I also searched for, reviewed, and tried some possible solutions (e.g. in a thread on the TortoiseSVN forums to which Stefan Küng replied) - a registry tweak (deleting HKEY_CURRENT_USER\Software\Tigris.org - after exporting it for backup of course), checking my global properties, and ensuring that I am not using a proxy. Same error.
Finally, I tried both repairing and downgrading TortoiseSVN. Same error.
Has anyone else encountered this error under similar circumstances and found a solution to it?
Note that some related search results mention tweaking httpd.conf or other aspects of the SVN server, but server tweaks seem inappropriate to me. Again, my teammates continue to commit mods to the same repo using the same version of TortoiseSVN, the same OS (Win 7 Pro 64-bit) etcetera. Maybe I have missed something on the server that could just happen to affect me, though.
Upgrade your Subversion client to the latest version.
Outdated answer:
ON THE CLIENT MACHINE! Open %APPDATA%\Subversion\servers in a text editor and add the line http-bulk-updates = yes, save the file and see if it helps.
If it helps, you'd better configure Apache HTTP Server's httpd.conf with SVNAllowBulkUpdates prefer directive so that all Subversion 1.8 clients could connect without any errors.
If there are more than just you who get this error in your organization and adjusting server's configuration is still unacceptable, you can change the setting http-bulk-updates = yes via Windows Registry so adjusting this on all affected machines can be done via AD Group Policy.
Read more info in Apache Subversion 1.8 Release Notes.
P.S.: faulty network hardware / firewall / antivirus is still the root cause here. The above is just a workaround to revert to the behavior of Subversion 1.7 and older client with neon network library. BTW, I guess that the installed antivirus is NOD32 or BitDefender.
In my case it was problem with nginx's gzip (I run SVNEdge SVN server behind Nginx).
I disabled gzip and everything started working.
When using XAMPP (1.7.5 Beta) under Windows 7 (Ultimate, version 6.1, build 7600), it takes several seconds before pages actually show up. During these seconds, the browser shows "Waiting for site.localhost.com..." and Apache (httpd.exe, version 2.2.17) has 99% CPU load.
I have already tried to speed things up in several ways:
Uncommented "Win32DisableAcceptEx" in xampp\apache\conf\extra\httpd-mpm.conf
Uncommented "EnableMMAP Off" and "EnableSendfile Off" in xampp\apache\conf\httpd.conf
Disabled all firewall and antivirus software (Windows Defender/Windows Firewall, Norton AntiVirus).
In the hosts file, commented out "::1 localhost" and uncommented "127.0.0.1 localhost".
Executed (via cmd): netsh; interface; portproxy; add v6tov4 listenport=80 connectport=80.
Even disabled IPv6 completely, by following these instructions.
The only place where "HostnameLookups" is set, is in xampp\apache\conf\httpd-default.conf, to: Off.
Tried PHP in CGI mode by commenting out (in httpd-xampp.conf): LoadFile "C:/xampp/php/php5ts.dll" and LoadModule php5_module modules/php5apache2_2.dll.
None of these possible solutions had any noticeable effect on the speed. Does Apache have difficulty trying to find the destination host ('gethostbyname')? What else could I try to speed things up?
Read over Magento's Optimization White Paper, although it mentions enterprise the same methodologies will and should be applied. Magento is by no means simplistic and can be very resource intensive. Like some others mentioned I normally run within a Virtual Machine on a LAMP stack and have all my optimization's (both at server application levels and on a Magento level) preset on a base install of Magento. Running an Opcode cache like eAccelerator or APC can help improve load times. Keeping Magento's caching layers enabled can help as well but can cripple development if you forget its enabled during development, however there are lots of tools available that can clear this for you from a single command line or a tool like Alan Storms eCommerce Bug.
EDIT
Optimization Whitepaper link:
https://info2.magento.com/Optimizing_Magento_for_Peak_Performance.html
Also, with PHP7 now including OpCache, enabling it with default settings with date/time checks along with AOE_ClassPathCache can help disk I/O Performance.
If you are using an IDE with Class lookups, keeping a local copy of the code base you are working on can greatly speed up indexing in such IDEs like PHPStorm/NetBeans/etc. Atwix has a good article on Docker with Magento:
https://www.atwix.com/magento/docker-development-environment/
Some good tools for local Magento 1.x development:
https://github.com/magespecialist/mage-chrome-toolbar
https://github.com/EcomDev/EcomDev_LayoutCompiler.git
https://github.com/SchumacherFM/Magento-OpCache.git
https://github.com/netz98/n98-magerun
Use a connection profiler like Chrome's to see whether this is actually a lookup issue, or whether you are waiting for the site to return content. Since you tagged this question Magento, which is known for slowness before you optimize it, I'm guessing the latter.
Apache runs some very major sites on the internets, and they don't have several second delays, so the answer to your question about Apache is most likely no. Furthermore, DNS lookup happens between your browser and a DNS server, not the target host. Once the request is sent to the target host, you wait for a rendered response from it.
Take a look at the several questions about optimizing Magento sites on SO and you should get some ideas on how to speed your site up.
I am using Memcached in my Ruby on Rails 3 app. It works great with action and fragment caching, but when I try to use page caching, the page is stored in the filesystem instead of in Memcached. How can I tell Rails to use Memcached for page caching too?
In my development.rb file:
config.action_controller.perform_caching = true
config.cache_store = :mem_cache_store
You cant. The equivalent of page caching in memcached is action caching, because the request must be served through Rails. Page caching is meant to bypass Rails, so the data must be stored in a file that can be served from the server, like Nginx or Apache. The reason page caching is so fast is that it does bypass Rails entirely. Here is what the Rails documentation says:
Page caching is a Rails mechanism
which allows the request for a
generated page to be fulfilled by the
webserver (i.e. apache or nginx),
without ever having to go through the
Rails stack at all. Obviously, this is
super-fast. Unfortunately, it can’t be
applied to every situation (such as
pages that need authentication) and
since the webserver is literally just
serving a file from the filesystem,
cache expiration is an issue that
needs to be dealt with.
You can find more information here.
check this :
http://globaldev.co.uk/2012/06/serving_memcached_pages_from_nginx/
Cutting it shortly, install "memcaches_page" gem (add it to GemFile then bundle), then change caches_page directive to memcaches_page, then configure Nginx to serve page memcached server before hitting the application (described in the article) .