Magento2: Improve Dev Experience Performance ( aka Magento 2.1 RC1: Static Asset Application too Slow Without Caches )

[astorm]

Per https://github.com/magento/magento2/issues/4681#issuecomment-221671239, Magento's static asset serving application is too slow without caches enabled.

Default application state after installation should be with caches on.

Baseline cache-less Magento performance should be improved.

Please see original ticket for reproduction steps and actual/expected behavior. https://github.com/magento/magento2/issues/4681#issuecomment-221671239

[astorm]

Tagging original participants so ticket isn't lost after original ticket was closed. Participate/ignore as you would the initial ticket /cc @pboisvert @redboxmarcins @tkacheva @choukalos @dsikkema @piotrekkaminski

[dsikkema-magento]

Internal ticket MAGETWO-53474

[dsikkema-magento]

What was exact composer command to download code? I just copied the exact install command from previous thread, only modifying database credentials and the like, and the caches were enabled on a rc1 codebase retrieved via:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.1.0-rc1

[dsikkema-magento]

dug around a bit, looks like this issue appears when upgrading via CLI

[choukalos]

Clarifying this Github issue for ensuring caches are turned on after upgrading via CLI. We're tracking that internally as ( MAGETWO-53474 ).

@astorm - Static asset serving too slow when caches are being turned on is a feature request. Is this feature request valuable? What use cases would a developer have where caches are all disabled and new assets are being generated?

[mazhalai]

@choukalos yes re MAGETWO-53474

[astorm]

@choukalos

1. The inevitable use cases similar to the one that prompted the original ticket
2. There are UI and command line features for turning the cache on and off. If the user has cache turned off, they'll be hindered by this problem anytime they add new files to the system, or move/rename a file (implicit -- if there are no use cases for a developer to turn caching off, why can they?)
3. Hiding significant performance problem behind a caching layer encourages sloppy/poorly-performing code across the system, increasing the chances of future bad experience (both developer, trial merchant, and existing users alike), and increasing the cache state complexity of the system.
4. Not addressing long term performance problems (other than to hide them behind a caching layer) indicates to a team with short term goals, and not long term goals. Improving the performance of an uncached Magento bootstrap indicates a team that's in it for the long haul, and interested in making open source Magento as good as it can be in the years to come.

[choukalos]

Hey @astorm - would be great if you (and others in the community) can help by providing analysis/suggestions on what we can do to speed things up? PR's would really help. I'd recommend draft an HLD in an issue and CC me so I can get it to our performance architect asap if you want to help. That way we can best align efforts/etc.

We are pursuing near term improvements to the developer experience (of which this could fall as one we'll pursue; internally MAGETWO-54047) and optimizing our bootstrap process (internally MAGETWO-47299). In addition to the above we've also identified several areas where legacy M1 code has been wrapped in large classes called by controllers that should be re-factored to improve uncached performance (MAGETWO-54048).

Thanks!

[astorm]

Chuck,

That request is a little cart before the horse.

The sort of uncached (and cached) performance issues with Magento 2 are due to things happening on the framework and architecture level. Magneto's engineering team (or whomever is in charge/ultimately responsible) are the ones who need to spearhead that effort, or provide the parameters of how contributions can/should happen.

I'm sure there's tons of folks in the community who would love the help out, but when you (inadvertently I'm sure) frame the work to be done as unpaid consulting you're going to turn a lot of people off.

On Aug 12, 2016, at 6:20 AM, Chuck Choukalos [email protected] wrote:

Hey @astorm - would be great if you (and others in the community) can help by providing analysis/suggestions on what we can do to speed things up? PR's would really help. I'd recommend draft an HLD in an issue and CC me so I can get it to our performance architect asap if you want to help. That way we can best align efforts/etc.

We are pursuing near term improvements to the developer experience (of which this could fall as one we'll pursue; internally MAGETWO-54047) and optimizing our bootstrap process (internally MAGETWO-47299). In addition to the above we've also identified several areas where legacy M1 code has been wrapped in large classes called by controllers that should be re-factored to improve uncached performance (MAGETWO-54048).

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[astorm]

Assuming this isn't a priority, closing out.

[SyedMuneebb]

Magento 2 is not slow by default. You have to do some optimization to make it fast like Image Optimization, CSS and JS Optimization and many other things. Here's a simple guide on it: Why Magento 2 is slow