That first response from the web server must come in under 200ms in the UK
There is no frontend to the site at the moment, it is style free and image free.
You won't achieve those figures without the aid of either Varnish or FPC (or both). I would certainly hope that figure doesn't also have to include static content (whenever you decide to ...
You're getting into a broad, broad world of optimisation here and there certainly isn't a one size fits all approach.
Do you mean the page load time for a single user, or the overall capacity/total concurrency? The two are very distinctly different - and not strictly related. It is entirely possible to have a fast store with limited ...
Interesting to know if we can get the product URL without loading whole product. Sorry to answer your additional question and not the main question, as I am also not sure if we can get it :)
For getting a single attribute without loading whole product, you can use getAttributeRawValue() if you are using Magento CE version 1.6+
[DISCLAIMER] This answer is only meant for the compiler in Magento 1, the compiler in Magento 2 has a complete different purpose/effect
You should use it never.
Because PHP has developed several mechanics to improve applications containing lots of files.
Means: the php opCache in current php version gives way better performance improvements, if correctly ...
First look at getBaseUrl() at Mage.php
public static function getBaseUrl($type = Mage_Core_Model_Store::URL_TYPE_LINK, $secure = null)
return self::app()->getStore()->getBaseUrl($type, $secure);
In a simple word we can say:
Mage::getBaseUrl(Mage_Core_Model_Store::URL_TYPE_WEB) indicated Your Magento Site Url from this url ...
tl;dr -> "Can Magento handle 1M products", the answer is yes, but with some considerations. At this scale one would assume you have volume to support a decent investment into infrastructure and personnel to merchandise a catalog of this proportion.
Magento CE sample data, as you may have seen, has only a handful of products from varying ...
Its important to understand what indexes are slow and why
Catalogue complexity and ultimately store architecture will dictate how long a re-index will take - combined with the underlying infrastructure.
If you've got 50,000 products and 10 store views, you can guarantee the few million rows in catalog_url_rewrite will take time to process.
If you've got ...
In your app/etc/di.xml, replace the line:
<preference for="Magento\Framework\DB\LoggerInterface" type="Magento\Framework\DB\Logger\Quiet"/>
<preference for="Magento\Framework\DB\LoggerInterface" type="Magento\Framework\DB\Logger\File"/>
You’re on a great path with that cluster configuration. I recommend adding a dedicated cache host for Redis; select one with high CPU power and a lot of RAM (~64 GB).
Here’s the full list of configurations I’ve used for a highly available, fault tolerant, distributed, and load balanced LEMP cluster. It includes app/etc/local.xml, the core_config_data table, ...
From personal experience, disable the Mage_Rss module which forces a 'cache clean' 4 times in checkout process -- very expensive if you are using filesystem cache, probably still expensive if you are using database or memcached.
CE Only Disable Mage_Downloadable for similar reasons as long as you aren't using Downloadable product, this will speed up checkout ...
Here are some thoughts on evaluating 3rd Party Modules:
Current Magento Version Support - Does it support the latest version of Magento (including the current one we are developing it for)?
If a module does not support the latest release of Magento, it will probably be difficult to make it work without spending precious development time on it.
Yes it does. First of all, less modules means less code to (potentially) load and process. Next to that, a lot of modules, like for example the Mage_Rss module run a lot of code in the background like forcing reindexes on certain events.
On the method best to use: disabling a module using System > Configuration > Advanced only suppresses the output of ...
(copied from my own blog at https://www.gui.do/post/101-ways-to-speed-up-your-magento-e-commerce-website)
A) Hosting environment/ General tips
Get a dedicated server.
Host your site in the country where your customers are.
Don't host files on your web server that you do not use, large or small.
Goto MySQL Admin and select all the tables and ...
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 ...
It depends on your request. For instance, lastly, I had been removed all Prototype scripts from the Homepage of the Magento store which I didn't face any problem. But as I said, it depends on your theme, extensions etc.
To moving the script :
Find the following line in page.xml of your theme
<block type="core/text_list" name="before_body_end" as="...
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 ...
There are two problems with moving the tag. The greatest problem is that for some reason Magento injects a lot of JS that is dependent on prototype directly into the <body/> tag. Moving the scripts to the end of the document (though good for load times), will break a lot of the pages in Magento.
The other problem is actually doing it. There doesn't ...
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 ...
We've got a fairly vast experience of MySQL clusters - and Percona have worked with us on a number of occasions when pushing the boundaries of complex configurations.
Can Magento natively handle read-only slaves
Magento is natively capable of splitting off reads/writes to different database servers (with the exception of a few broken releases, eg. EE 1.11) ...
You should really use
for this purpose, as it exists purely for the performance reasons you mentioned.
Otherwise, you can use a slightly less elegant solution using a loop with setPageSize - there's a good example here, https://stackoverflow.com/questions/3786826/how-to-loop-a-magento-collection
One thing which can speed up the whole site is to remove all references to Varien_Profiler on your production site. Even if the profiler is disabled, it always checks whether it is enabled so every call to Varien_Profiler:: will result in an additional if statement.
Of course, removing all these calls comes at the cost of not being able to use the profiler ...
This question may be opinion based but I'm just going to enlight some results from the offical white paper regarding Magento 2 performance and scalability
Magento Enterprise Edition 2.0 with PHP7 and Varnish caching
Magento Enterprise Edition 1.14.2 with PHP5.6 and Full-Page Caching
Comparison between Magento EE 1.14.2 and Magento EE 2....
TL;DR: Just switch on the config caches.
I've had the same issue and have been playing around a bit.
Steps to reproduce (in developer mode):
reload frontend or backend in a browser
When reloading and monitoring with htop, the system 'spams' some PHP processes, totally utilizing all CPUs.
This is when I ...
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....
In Magento 1.x this is a fool's errand. There are simply too many inline scripts littered throughout the template files in Magento that will break if you relocated the core JS files from the <head>. Potentially in Magento 2, this situation will change but it's straddling Prototype and jQuery as Magento migrates away from Prototype.
For other scripts, ...
When executing a lot of saves on Magento models it's best to disable the Magento indexer which slows the process down:
$processes = Mage::getSingleton('index/indexer')->getProcessesCollection();
And enabling it when your done:
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 ...
Despite being late with an answer I would like to answer the question
You gain even more performance if you physically remove the files.
Simply all of them, except Mage_Core ;-)
But to disable tight couple modules you need to install another module which takes care that nothing will break. Therefore I've developed: https://github.com/Zookal/magento-mock
As far as I can see/know this table is included in the event log_log_clean_after.
If you look under the file app/code/core/Mage/Reports/etc/config.xml you will see the following snippet.
That looks like they tried to make sure to destroy the image resource, but instead introduced a memory leak. I cannot think of a valid reason for this code, to be honest, but I can explain what has been changed:
Originally, imagedestroy() would have been called in the desctructor __destruct()