Magento2 Runs Slow - Developer Mode.

[tapansoda]

I have installed Magento2 and have discovered running slow in developer mode. It takes around 8-10 seconds to load pages completely, with all cache types enabled. Below are more specific details in regards to the software stack that I have.

Operating System :- Ubuntu 14.04.3 LTS - 64 Bit Processor:- Intel CORE I5 3rd Generation RAM :- 8 GB (1X8) DDR3 1333MHZ PHP Version:- 5.5.9 Apache Version:- 2.4.7 MySQL Version:- 5.6.27

1) I would like to understand what should be an ideal page load time for Magento2 in developer mode?

2) The software stack that I have mentioned above looks to meet the recommendation, although if there are any improvements that can be made then kindly highlight those.

3) Is there any specific practice that should be followed while working in M2 developer mode? Examples of such specific practice can be in regards to client-side less compilation OR any other factor that may affect the load time.

4) In general it is a good practice to have cache disabled during development, however having cache disabled looks to be a real pain with Magento2, it loads way slow around 30 seconds with cache disabled. Any suggestions?

Thanks, Tapan

[Pinimichu]

No solution but restarting the mysql service in regular base have increased my systems performance a lot.

[antonkril]

Is it time to first byte or page with all assets loaded in browser?

Normal page load time is less than a second. Usual reasons for slow page generation are xdebug debugging session, xdebug profiler, opcache turned off.

[alankent]

Restarting MySQL improves performance? I wonder if you are running out of memory and thrashing your machine. I am running Apache + php 7 + MySQL in a docker container within virtual box on my laptop and after first generation of a page most pages come back sub-second,

[johnbendi]

                                                                                  Did you say sub-second? Does this include category and product detail pages? And in developer-mode?                                                                                                                                                                                                                                                                                                                                                     

[tapansoda]

@alankent - Do you think we require any changes with the software stack that I have pointed out above? We are not using docker container with virtual box, is that recommended? If we disable cache it takes around 20-30secs for page to load? If we enable cache it works fast say 6-8 secs, but as far as I understand it is recommended to have cache disable in development mode to view the changes made.

You have mentioned after first generation of a page most pages come back sub-second - I believe you are getting sub-second due to browser cache, you can clear your browser cache and test it. Are you still getting that page in sub-second? If yes, can you please help us out of what maybe going wrong on our side.

[alankent]

I do not believe the pages are not cached in the web browser - they change when I fiddle with the server code. Also browser cached pages I would expect to be even faster. Could you check your paging rates? I am wondering if 8GB is sufficient memory. If that does not work, there is something I would be curious if I can get you to try if you have the time - please drop me an email at akent at magento.com and I will email instructions.

[tapansoda]

@alankent appreciate for your prompt response.

I am on Ubuntu 14.04.3 LTS - 64 Bit, what is the best way to check for paging rates? I will send you the output for the same.

Also I have send you an email just in case it its not a problem with paging rates. You can send me instructions on that email id.

Thanks, Tapan

[theskillwithin]

It is extremely slow on my vagrant despite having a $8000 computer and devoting lots of resources to my vagrant and php. Of course every time this question is asked people assume its for live and tell them to enable caching but this does not help while developing/theming. Infact magneto 1 is much faster on my local vagrant at work on a much worse computer to develop in. Its just impossible.

[maconeto]

When Magento 2 first release, i tried a fresh install and it was amazingly fast. Now after a while, Magetno 2.1 came out and i make a new fresh site, this time is is painfully slow. My local machine is quite good, best Ivy Core with 8GB Ram. If I upload this site to my remote server, it takes like 30 seconds to load homepage. I have read many threads about this slow issue and no one seem to understand why. Please don't tell me to enable cache or merge css,jss, as i need to work in dev mode. What's wrong with Magento 2 and their dev team? No one figure out why?

[piotrekkaminski]

@maconeto what PHP version? do you have opcode cache enabled? btw internal developers usually work with all caches enabled and flush the cache as needed.

[maconeto]

PHP version 5.6. I don't enable any kind of cache. My idea is that Magento should not be that slow even without cache. It is not reasonable. A month or two ago i tried an eariler version and it was fast, installed on the same machine, same environment. If it loads 10 - 30 seconds on local, it must be something else rather than just cache. It goes from amazingly fast to terribly slow.

[jacquesbh]

Hi!

Any news about this?

Reloading a page in any web project in development (so without cache) should not be too slow. It's time consuming.

[treestonemedia]

Hi!

Magento folks, we cannot develop sites if when in dev mode it takes two minutes for each page to load. Either we all missed the boat, or you need to address this issue ASAP

[theskillwithin]

I am starting to use NPM-scripts instead of Gulp because it is faster and easier. (see here) https://github.com/theskillwithin/hrtcup/blob/master/package.json

however, I don't think this will solve the speed issue.
I attended a meetup about 6months at magentoHQ in culver, pretty much every other frontend dev I have spoken to does not have an answer to this problem and has given up, including me.

(ps here is my vagrant povision https://github.com/theskillwithin/intelliamor2/blob/master/scripts/install.sh )

[carylewis]

We run mag2 under centos and every page reload in developer mode takes upwards to two minutes.

But, some people here are reporting fast load times, so I have to think that it is a configuration issue.

[denchev]

I also had (maybe still have) performance issues with Magento 2. But with a couple of modifications to the virtualization configuration and Magento env I was able to speed it up to a workable pace.

On the virtualization site you can:

• Give more memory (2GB should be fine but depends on the size of the catalog and overall application size)
• Give more processor cores/threads. This is key.

On the Magento 2 site:

• Configure the cache to use either APC or Redis. Setting up the sessions to use Redis as storage, instead of my files system, greatly improved things.

On the server config:

• Enable apache prefork module. That way you will have usage of the multiple cores you gave via the virtualization.
• Don't forget to bump up the PHP memory_limit via the php.ini settings and the .htaccess file.

Make sure you don't have any 404 static resources. When there is a 404 by default it will load the Magento 404 page which will choke the server even more. God forbid if you have another 404 resource in that 404 page. That is a good way to max you CPU and be killed by a spinning fan :) That sh*t usually happens if you are like me - think you know DevOps but actually you don't :)

Hope I helped.

[ipascual]

This way my speed time came down to half:

• No virtualize, using Ampps on Mac, php7
• xdebug: I've been using a local compiled xdebug, I had to disable it :-/
• redis server for cache (configuration bellow)

        array(
            'frontend' =>
                array(
                    'default' =>
                        array(
                            'backend' => 'Cm_Cache_Backend_Redis',
                            'backend_options' =>
                                array(
                                    'server' => '127.0.0.1',
                                    'port' => '6379'
                                ),
                        ),
                    'page_cache' =>
                        array(
                            'backend' => 'Cm_Cache_Backend_Redis',
                            'backend_options' =>
                                array(
                                    'server' => '127.0.0.1',
                                    'port' => '6379',
                                    'database' => '1',
                                    'compress_data' => '0'
                                )
                        )
                )
        ),

Hope it helps

[snez]

@alankent this has been a problem for quite a while, but testing just now on an uncompiled Magento 2.1.2 with all caches enabled, pages can take 20-30s to first byte, and 2mins+ for the dom to load. php-fpm seems to go crazy, for example during the entire 2 minutes it took to load, here's how activity looked like:

A compiled Magento 2.1.2 will load with a 5-6s to first byte and 6-8s for dom load, but many 3rd party extensions may not work with compilation mode, which should be considered the default development environment for many merchants building their sites. Even when compilation works, whenever a recompilation is needed, recompiling takes 8-10mins which is just too long of a time to waste.

Apart from figuring this out, if it's fast for you in docker, can the Magento team please publish a docker image with all of the optimal defaults for development, php7 + opcache + redis for sessions etc?

[carylewis]

You have to use php7, otherwise magento 2. for all intents and purposes, is unusable.

On Sat, Dec 24, 2016 at 12:48 PM, Christos Constantinou < notifications@github.com> wrote:

@alankent https://github.com/alankent this has been a problem for quite a while, but testing just now on Magento 2.1.2, pages can take 20-30s to first byte, and 2mins+ for the dom to load. php-fpm seems to go crazy, for example during the entire 2 minutes it took to load, here's how activity looked like:

[image: screen shot 2016-12-24 at 17 42 47] https://cloud.githubusercontent.com/assets/249977/21468275/c192bade-ca00-11e6-9b89-fedd5c5e0427.png

Apart from figuring this out, if it's fast for you in docker, can the Magento team please publish a docker image with all of the optimal defaults for development, php7 + opcache + redis for sessions etc?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/2824#issuecomment-269093828, or mute the thread https://github.com/notifications/unsubscribe-auth/ABkAvZ_5zIhwy2jCz8a_9TU35-GWRAAuks5rLVsBgaJpZM4G72ap .

[joshuapack]

I am running Magento 2.1.3 on PHP 7.0.15. Running on CentOS 7 using Digital Oceans 16GB Memory and 8 Core plan. Apache 2.4.6. MySQL Ver 15.1 Distrib 10.1.20-MariaDB.

Developer mode takes 12-30 seconds for first byte for home page with a fresh install using the setup wizard.

Production mode has never worked without some type of error.

This was the best result i got:

I was wanting to go to magento 2, but i feel like maybe Magento is not for me. Right now I'm running Magento 1 on Production (Dedicated servers). However, without caching I was able to get Magento 1 running at 1-3 seconds at the application level. With caching as fast as 100ms. This doesn't seem possible with Magento 2 with my tests. :(

[snez]

It seems to me that there is a compilation issue with Magento 2.1.3 that adds to all this - I am getting similar performance with either compiled or uncompiled 2.1.3. Is anyone else able to confirm this?

[joshuapack]

@snez I am able to get application down to 250ms on developer mode as long as caching is enabled and it is the 2nd time accessing the page. However, it is still unacceptable that I must rely on FPC in order for the home page to load in under 3 seconds. What kind of processing is going on that this is needed? Maybe I came in at a wrong time and 2.1.3 is not ready for production.

[tapansoda]

What we observed in our operations – performance parameters at development workstation level really lies into machine’s hardware.

Back in last days, we tried several combinations in development workstation hardware for Magento 2x programmers – and a machine with a Ubuntu (or a lightweight Linux Mint) Desktop environment over the Intel i7 CPU, SSD disk and 12GiB DDR4 RAM works exceptionally well.

M2 involves massive file-system disk i/o as per our noting and if someone gives try with this hardware options – developers would have pretty smooth application along with overall ease with implementing and evaluating custom codebase over the latest M2 build.

[snez]

@tapansoda I'm sure those specs are not far from what most of us are using, I'm personally on Intel i7 CPU, PCIe SSD and 8GiB DDR3 RAM, but really struggling with performance. It's definitely not a disk issue or memory issue with me, there seems to be a CPU bottleneck as this is what happens when Magento has been compiled successfully, all of the Magento caches have been enabled, and all of the browser caching is enabled as well through Nginx configuration:

My best single page loading time for the standard /customer/account/ page is ~10 seconds with all caches enabled, compiled successfully and in developer mode.

However, we are developers - it would be sensible for the platform to perform well with all caches off and a single user loading a page. Caching is meant to be useful when scaling to hundreds of simultaneous page requests per second, not for the standard development speed to be "acceptable".

[bardkalbakk]

Disabling css merging in developer mode reduced page-load-time dramatically for me, although caching was already enabled.

[surfer190]

@bardkalbakk That was probably full page cache

[woutersamaey]

+1. Something needs to be done about this, seriously.

[01000101]

Is this really a production (or heck, even developer) ready product? It takes roughly 5-10 seconds per page in developer mode (even using some of the tricks above). Maybe it's a robust product, but it's useless if it takes a full work day to make and test a module.

[treestonemedia]

+1 very difficult to develop a theme under these circumstances - there must be a better way

[abhishekramkrishna002]

Any solution, yet? I did a fresh install of magneto 2.1.7 with the following stack: Os: windows 7 Php: 5.6.3 Mysql: 5.0.12 apache: 2.4.25

Enabled the developer mode & disabled the cache. The customer site takes around 8-10 sec to load.The admin taken 6-8 sec to load. Created a module and was able to get it up. However any changes to css of the module , results in re deploying the static files with the cli (takes around 4-5 minutes) and on refresh page takes 8-10 sec . So development has become time consuming.

Later, I tried to improve the dev performance: 1: upgraded php to 7.0.18 2: increased memory_limit in php.ini (10 GB) 3: Workflow type : client side less compilation 4 Merging, minifying and bundling js has been disbaled.

The performance was enhanced a bit by a second . Any help? . The delay is hindering my performance.

Thanks.

[maconeto]

No, there is no solution. You have to turn on all the cache to develop that how they suggest us. I know companies that are moving away from Magento to use different solution because the time to develop has increased a few times since Magento 2.

On Fri, Jun 9, 2017 at 10:12 AM, abhishekramkrishna002 < notifications@github.com> wrote:

Any solution, yet? I did a fresh install of magneto 2.1.7 with the following stack: Os: windows 7 Php: 5.6.3 Mysql: 5.0.12 apache: 2.4.25

Enabled the developer mode & disabled the cache. The customer site takes around 8-10 sec to load.The admin taken 6-8 sec to load. Created a module and was able to get it up. However any changes to css of the module , results in re deploying the static files with the cli (takes around 4-5 minutes) and on refresh page takes 8-10 sec . So development has become time consuming.

Later, I tried to improve the dev performance: 1: upgraded php to 7.0.18 2: increased memory_limit in php.ini (10 GB)

The performance was enhanced a bit by a second . Any help? . I hate staring the screen , during development.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/2824#issuecomment-307283980, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiTH7kqRzVaAMpRgU6tlCFXUxmlIY7Sks5sCLgegaJpZM4G72ap .

-- Best Regards,

Anthony Nguyen

maconeto.com http://maconeto.commeet, connect, benefitE: mail.maconeto@gmail.com mail.maconeto@gmail.com

[denchev]

@abhishekramkrishna002 Your problem probably lies on the fact that you are using Windows. My impression is that Magento 2 is build to work on Linux and all other OSs are just "supported". Magento 2 is very I/O intensive. It writes a lot. It uses quite a lot of symlinks which are not supported on Windows so Magento fallback to copy.

I would highly recommend reading this article https://magento.com/blog/technical/set-your-magento-2-development-environment-faster. You could also use Vagrant but be aware Vagrant + Windows + Symlinks is again a tricky combination so you need to be clever. For example: Use shared folder for app/code only. You could also use a hosted solution somewhere "in the cloud". There are pretty cheap options. I won't mention a name but I am using 6 CPU + 16GB RAM + 50GB ssd for 12 EUR per month. A small price to pay to be able to run multiple dev instances. So on that machine you can install Magento on top of some Linux distro, it will be fast. And you need to hook up to it with some IDE (PHPStorm for example) and FTP your files to it.

There are various types of ways I am dealing with Magento's slow development. Again I am using Windows so this is the core problem. If we were to use Linux this won't be an issue.

[maconeto]

No Marush. I'm on Linux, SSD disk, 8GB Ram, Core i7 3770, if I don't turn on all caches, the speed is still more than 10 times slower than Magento 1. Magento 1.9 is extremely fast on the same environment

On Fri, Jun 9, 2017 at 11:20 AM, Marush Denchev notifications@github.com wrote:

@abhishekramkrishna002 https://github.com/abhishekramkrishna002 Your problem probably lies on the fact that you are using Windows. My impression is that Magento 2 is build to work on Linux and all other OSs are just "supported". Magento 2 is very I/O intensive. It writes a lot. It uses quite a lot of symlinks which are not supported on Windows so Magento fallback to copy.

I would highly recommend reading this article https://magento.com/blog/ technical/set-your-magento-2-development-environment-faster. You could also use Vagrant but be aware Vagrant + Windows + Symlinks is again a tricky combination so you need to be clever. For example: Use shared folder for app/code only. You could also use a hosted solution somewhere "in the cloud". There are pretty cheap options. I won't mention a name but I am using 6 CPU + 16GB RAM + 50GB ssd for 12 EUR per month. A small price to pay to be able to run multiple dev instances. So on that machine you can install Magento on top of some Linux distro, it will be fast. And you need to hook up to it with some IDE (PHPStorm for example) and FTP your files to it.

There are various types of ways I am dealing with Magento's slow development. Again I am using Windows so this is the core problem. If we were to use Linux this won't be an issue.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/2824#issuecomment-307291497, or mute the thread https://github.com/notifications/unsubscribe-auth/ABiTH0dHGymFI9WZXuYOI2h6ELbiazUbks5sCMgngaJpZM4G72ap .

-- Best Regards,

Anthony Nguyen

maconeto.com http://maconeto.commeet, connect, benefitE: mail.maconeto@gmail.com mail.maconeto@gmail.com

[denchev]

Hi @maconeto, I mentioned @abhishekramkrishna002 because he mentioned he is using Windows.

But you are also right. Without the cache you will have slow dev time. What I am doing is - turn on all cache but disable FULL PAGE CACHE. And then I learned how to flush only cache that matters to my case.

For example if I change something from the Configuration I simply run "php bin/magento cache:clean config". That way I only flush the config cache but all the rest remains and doesn't slow down Magento to rebuild it. When I work with layouts I run "php bin/magento cache:clean layout". Again I will be cleaning the layout cache but all the rest, including "config" will not be cleaned.

And if all cache is enabled (without FPC) and you work with app/code your development is not affected by the cache.

[01000101]

After speaking about a dozen Magento certified developers, the consensus is that Magento 2 is not production-ready (bugs, unexplained sluggishness, lack of extensions by contrast) and they almost all suggest developing in Magento 1 (even for new sites not yet in production). Magento 1 might turn into the new Python 2.

[SyedMuneebb]

<redacted by moderator> // self-promoting is not allowed here

[jacquesbh]

We are talking about Magento in Developer mode, not in production @SyedMuneebb.

[Detzler]

I think it's time for Magento 3

[sulabh]

This is very disappointing. Every time a theme change happens, it does not reflect till in developer mode with cache disabled. deployment to live is another headache. it takes a few minutes to deploy and till then it goes in maintenance mode. Sometimes you have to flush cache twice, for no apparant reason.

Why oh Why did Magento Team release an untested platform?

[sulabh]

This ticket is open since December 2015. Any chance of resolving this issue till Dec 2017?

[woutersamaey]

Magento wants you to buy Enterprise Edition. That's why they are focused on adding more features (like B2B stuff) in EE only. Developer comfort is not their priority (as anyone can clearly see here). At our company, we've built our own tools and have been able to fix almost all headaches.

[joshuapack]

@woutersamaey I have the Enterprise edition, and it is still a nightmare to use. We are looking at dropping Magento for another solution now.

[woutersamaey]

@joshuapack aren't you getting better service through the official support channels? And, which solutions are you looking at? I'm very much interested to hear what you consider.

[joshuapack]

@woutersamaey not at all. They want us to use 3rd party partners that cost us more money. I have never had a great experience with their support team. We just switched over to the revenue tiered pricing and brought the pricing up. It would be fine if their support was fast at fixing issues. We had a URL issue where new products and even older products stopped creating the url key automatically. Still not sure why that happened and I had a ticket open for 3 months.

I thought Magento 2 would be much better, especially since the webinars spoke so highly of it and the development process, but this has caused us more of a headache. Needless to say, we are looking into other options.

[woutersamaey]

@joshuapack Being an independant Magento developer it's hard not to acknowledge that there is something going wrong here. I do recognise similarities with M1 back in the early days, but that got resolved over a few years.

M2 has the potential to be great, but you need a lot of time, skill and courage to hack into the core and make the best out of it so it can work for you. At least that's what we're doing. With every project, things are looking a bit better.

Please do let me know what you are considering. I'm curious.

[treestonemedia]

I'm ok with a software having bugs that need to be ironed out and I understand that it's part of being eraly adapters. But we're almost 2 years into this and it doesn't seem like things are moving in the right direction or that someone @magento really cares about the bugs that are important to developers. Their #1 priority is selling the EE

[carylewis]

Magento 2 is unusable with vagrant / box as box uses virtual networking to access the files from the host. There is just so much file access going on.

Running it on a vmware workstation is workable, or inside a docker container.

On Fri, Jul 7, 2017 at 9:33 AM, treestonemedia notifications@github.com wrote:

I'm ok with a software having bugs that need to be ironed out and I understand that it's part of being eraly adapters. But we're almost 2 years into this and it doesn't seem like things are moving in the right direction or that someone @magento https://github.com/magento really cares about the bugs that are important to developers. Their #1 https://github.com/magento/magento2/issues/1 priority is selling the EE

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/2824#issuecomment-313681918, or mute the thread https://github.com/notifications/unsubscribe-auth/ABkAvYnGFHmRjE69zMFtY5PJTktJiaUgks5sLjPHgaJpZM4G72ap .

[phoenix128]

@carylewis , we develop Magento2 using Vagrant every day. Secret is using NFS share instead of VirtualBox disk shares and redis as caching engine.

I agree that docker is performing better for obvious reasons, but using Vagrant is possible as well.

[magento-engcom-team]

@tapansoda please refer to the Community Forums or the Magento Stack Exchange site for advice or general discussion about this issue. The GitHub issue tracker is intended for Magento Core technical issues only.