Hint missing for Allowed memory size of x bytes exhausted

I am not sure that this is a Drupal CMS issue, but a Drupal issue as the steps to reproduce are on a specific stack, but the Drupal CMS tooling.

However, I can be confident that this is not an SEO track issue.

Moving it to the Infrastructure track, but assume this is a Drupal core issue.

Drupal CMS has a much bigger footprint than Drupal core, so it makes sense that we would recommend more RAM than the minimum suggested by core. That said, there's not much we can do to enforce this at a code level, but for documentation purposes, sure. Perhaps the installer can do a requirements-alter or something.

I profiled the steps to reproduce with xhprof.

Loading the 'recommended' page takes a long time, this looks like it might be package_manager related, didn't look into that yet.

Installing the recipe, this is the xhprof summary:

Total Incl. Wall Time (microsec):	14,518,042 microsecs
Total Incl. MemUse (bytes):	167,312,128 bytes
Total Incl. PeakMemUse (bytes):	167,674,928 bytes
Number of Function Calls:	25,288,488

I didn't see more than about 40-50mb of RAM usage on the previous Drupal CMS requests I profiled, including a full cache clear, so something is going on. Will open (probably core and project browser) issues and link from here if I get a bit further.

Just 📌 RecipeRunner::processInstall() installs modules one by one Active is responsible for so much extra work it's not worth profiling beyond it for the actual recipe install request. Once that's fixed, and maybe testing against 11.2 core too, it would be worth profiling again and seeing what's left. Right now installing the recipe is rebuilding the container ten times, rebuilding the router and menu links ten times, etc. etc.

Opened 🐛 Drupal\project_browser\Element\ProjectBrowser::getDrupalSettings() is uncached Active for the 'recommended' page issue. That's one flag for Drupal settings is so expensive to build (several seconds) that it'll need to be profiled again once it's fixed, so also hard to untangle any other issues until that's fixed.

I did some more testing with all the installer-recommended recipes installed, and didn't hit over 58mb requesting pages with a cold cache, which is within the recommendations that core sets. So for me personally, I would treat those two issues as critical bugs, and not change anything here - OOM is one of the single things that is hardest to workaround on shared/budget hosting, you can hit it with drush commands on pantheon for example (not really budget or shared).