Performance issue on 2 tier architecture

I am seeing amajor issue where the YamlForm entity is not being cached because it is a config entity and this is causing its elements are being initialized multiple times. This would lead to a performance issue for very large forms.

This is going to take a little work to figure out the best solution.

Yep, this is an issue that is being worked on in Core.

#1885830: Enable static caching for config entities

My best option is probably going to be implement a temporary static cache for just a YAML Form's elements.

@robpowell There is no guarantee that this will fix your performance issue. I will look into starting to benchmark the YAML Form module.

Let's see if the attached patch passes all the tests.

I don't have an immediate benchmarks but the patch does prevent multiple YAML Form config entities loads when submitting a form.

I added a new test that confirms single YamlForm::load() calls are cached while YamlForm::loadMultiple() calls are not cached.

@robpowell can you please test the patch? BTW, is Bigpipe enabled on your site.

If you don't have time to test the patch, I can just commit this patch since the tweaks are very basic and include test coverage.

Memcache (or Redis) is a must if you want good performance. Varnish is also a good idea but it won't help much with a YAML Form's performance. Using PHP7 with the YAML extension will also boost performance.

The below URL might help you a little...
http://drupal.stackexchange.com/questions/217274/why-drupal-core-form-fo...

How are other pages performing in your 2 tier architecture? How is the YAML Form module's default Contact form performing?

For local development, I am going to try to install Blackfire.io and see what metrics I can capture.

I am going to commit the patch but keep this ticket open.

Changing title to be more generic and include the word performance.

@robpowell I created #2824272: Add wizard test forms with 100, 200, and 300 element.

I definitely need you to benchmark other forms, especially the long test forms included in the yamlform_test.module.

You will need to add the below setting to your settings.php to be able to enable the yamlform_test module

/**
 * Allow test modules and themes to be installed.
 *
 * Drupal ignores test modules and themes by default for performance reasons.
 * During development it can be useful to install test extensions for debugging
 * purposes.
 */
$settings['extension_discovery_scan_tests'] = TRUE;

Memcache always helps, even with anonymous user traffic. For example, any POST request will bypass Drupal internal page cache and Varnish's cache. Also Memcache will reduce PHP's memory usage which is a huge help for Apache (but not so much for NGINX).

For 2-tier custom server environment you are going to want to mirror Pantheon's and Acquia's caching stack. https://pantheon.io/features/advanced-caching.

Installing the PHP's YAML extension will result in your form's YAML being parsed much faster.

Also checkout this older video. https://drupalize.me/videos/overview-performance-scalability

In Drupal, anytime a form is submitted (aka a POST request) the page cache is bypassed and the form's submit handler is processed. The YAML Form wizard does trigger a rebuild of the entire form because the submitted and displayed has changed.

It is worth noting that when page's cache is bypassed and in our case a form is rebuilt, Drupal is still using caching for things like entities and especially blocks and this is where you get decent performance improvement by using Memcache since the cached blocks are pulled from Memcache (memory) and not the database (disk).

Right now you should just benchmark page load times and memory usage. I don't want to look at the load stack until I feel there is any issue.

A few pages worth benchmarking as anonymous (and authenticated when possible) ...

• Default Contact module contact form
• Default YAML Form module contact form
• Front page
• User login
• A basic page
• The module pages (/admin/modules)

It is also worth comparing the Bartik themes performance to your custom themes performance, just incase there is a performance issue at your theme layer.

@robpowell Did you workout your performance issues?

Glad to hear that you figured out the issue.