Module Feedback & Suggestions

There are several issues with this checklist besides Nginx, which is not contemplated.

1. If you have a reverse proxy there's no need for fast_404.
2. There's no mention of things like labJS for script loading parallelization.

This if we stay on the medium-sized site. If we try to address high traffic sites running Nginx with caching/load balancing then things like server level tuning is required.

My unrequested opinion is that this should be split in several submodules where each adress a specific concern and verify as much as possible the setup by invoking things like hook_requirements().

All feedback is more than welcome! I didn't create this module because I was the expert; I created it because my customers wanted it and I thought it deserved to exist. I need help to make it serve more than my own limited needs. I think splitting the checklist up is a great idea. Perhaps it should have a configuration screen where you select your stack (which HTTP server, DB, object cache, and reverse proxy you use, etc.) and environment details, like whether you have access to install software on your server. That way tasks can be tailored to your exact setup. The details of recommendations could even be tailed based on things like CPU power and available memory. I like where this conversation is headed. Please continue with your input, and include links to documentation as much as possible—not only to support your arguments but so I can add explanation and links to resources in the checklist itself. Thanks so much!!

Updated issue summary.

Yeah, I guess that something along the lines of separated tests and profiles would be great, so as @perusio suggests tests are split into submodules, but also various 'profiles' can be too, and maybe you could activate multiple ones, so the system could detect that it's running on Apache and add in the Apache profile tests, but if you could also add in the profile for 'Small blog site' and then it would check for very different things that if you added the profile for 'High traffic blog' for example.

I very much like the idea behind the Performance and Scalability Checklist but it seems to me there might be some conflict between this module and http://drupal.org/project/qa_checklist which also has a Server and Drupal optimization checklist.

Either the QA checklist would have to be more high-level to let all checklists modules be doing the deep dive (PASC, Security Review, SEO Checklist...) or maybe the idea would be to merge this module with it to bring in more community involvement.

What do you all think?

Thank you, @anavarre. I've actually been given maintainership of QA Checklist, and I intend to remove the conflicting tasks from it with a reference to this module. High level, delegation to "deep dive" modules, as you say, I think is a better approach in that module's case.

Updated issue summary.

I like the idea of 3 different modules (or sub-modules, whichever makes more sense). In fact, that was the point of abstracting the checklist API: so that anybody who wanted to could easily make a checklist for their own use cases. So:
PASC-hosted
PASC-medium
PASC-LSD
PASC-GoDaddy
PASC-Apple-IIe-onamodem
etc.

should all be doable if someone has the knowledge, the will, or both. (preferably both)

I think you could get this conversation off the ground, Travis, by setting up 3 different issues, one for the 3 most common use cases and then soliciting feedback from the community on them.

It may be time to make some good docs and a video on making your own Drupal checklists. If you write the docs, I'll make the video.

By the way, consider adding Advanced CSS/JS Aggregator https://drupal.org/project/advagg

Here's a list of more stuff to consider:
http://colans.net/blog/drupal-7-performance-optimization-options-and-che...

Okay, @Ben Finklea; so let's explore how this breaks down, shall we? What are the differentiators that determine what you can or should do to optimize your site? The biggest one is doubtless whether or not you can install software (e.g. APC, Memcached, Varnish) on your server. What else is there?

So, isn't the point here to come up with a widely accepted list of known performance wins that the module could ship with, and then let people create their own additional checks, which could be specific for a particular site?

Here's an example: in #1 @perusio said that Fast 404 shouldn't be recommended with reverse proxies and I'm sure he has very good reasons to believe so. In my experience (with nginx/Varnish on Acquia Cloud) I did notice numerous times that the very early Fast 404 bootstrap helped tremendously to keep a site up.

Does it mean that one of us is wrong? No, because it depends upon your VCL and nginx configuration, for how long you cache 404s (or not), etc. With this in mind, we should maybe make sure that certain checks would be granular and customizable. Leveraging a logic similar to https://drupal.org/project/conditional_fields would be interesting because it could display/hide fields depending upon if a checkbox is checked or not, etc.

That is indeed the point here, @anavarre. This issue isn't generating many concrete suggestions so far, though. Is there a better way to solicit best practice advice?

Okay, should we start suggesting "widely accepted" performance wins then? Something like:

• Disable all UI modules
• Disable the Database Logging module
• Disable the update manager module
• Cache your views and panels
• etc...

Yes, @anavarre; that would be the way to begin. Let's keep a working list of recommendations (list items) in the issue summary above. We'll want to include enough explanation in the details that people can make intelligent decisions for their actual use case. Links to documentation and other resources will be preferred.

I added a modules considerations tab in the D8 version to start capturing some of the "widely accepted" performance wins in terms of modules as suggested above.

Changing the version as I'll mainly be working on the D8/9/10 versions

Glad to see you picking up the baton g_bomb.