По поводу боли, это огромное преувеличение.
У Drupal с обновлением всё значительно лучше, чем у большинства других популярных движков.

Такая проблема будет только в том случае, если модули действительно не правильно удалялись.

А по поводу обновления есть простое решение, надёжно защищающее от проблем: обновиться надо сначала в тестовом окружении, посмотреть, что получается, и что надо чинить, и с пониманием того, что всё уже хорошо и/или как этого хорошо добиться, обновлять продакшен.

Вероятно, вам не нужен memcache, как писали выше. Сам по себе он не решит проблем с медленной загрузкой страниц.
И, скорее всего, вам надо разобраться с кешированием как таковым, а не с местом хранения кеша.

Но если, всё-таки он будет нужен, надо попробовать воспользоваться расширением php memcached, вместо memcache. Возможно, его версия установленная на вашем хостинге будет устраивать ваш модуль кеширования.

А он ответит, что на этот вопрос невозможно ответить не глядя на запускаемое...

Общий план того, как это делается:
Создаётся кастомный модуль, в него пойдёт часть кода, которая выполняет основную работу.
Обращения к базе переписываются используя DBAPI(https://api.drupal.org/api/drupal/includes%21database.inc/group/database...), работа с формами используя FormAPI(https://api.drupal.org/api/drupal/developer%21topics%21forms_api_referen...) и.т.п.

Не надо создавать какие-то произвольные php файлы где-то, вызывать их напрямую, и в них что-то делать.
Надо почитать о том, как делаются модули, темы оформления, иначе говоря, как правильно расширять возможности Drupal. И сразу отпадёт масса вопросов.

Для поиска по тексту есть solr, sphinx и подобные вещи. Mysql с такими задачами справляется куда хуже.
Смотреть время запроса.

20 в день, это очень мало. Было бы 20 в минуту, имело бы смысл написать фильтр для какого-нибудь fail2ban, и прикрыть этот поток нечистот.

Правильно сделал, опрос в шапке куций очень.

1, 2(только я больше как-то xhprof), 4(несколько раз только было нужно), 5(иногда, и не только о php), 7(но tcpdump, и с php обычно не связано), 9(но не в таком варианте, и используя анализаторы логов всякие).
Ещё часто помогают всякие top-alike: htop, iftop, iotop, apachetop(анализатор лога), mytop, и.т.п.

Дело не в тюнинге - дело в том, что это не более чем полуфабрикат. Есть много вещей, связанных с безопасностью, например, которые надо настраивать.
Установка панельки, это только небольшой кусочек необходимых работ, иными словами. И часто просто не нужный к тому же.

И если нет соответствующих знаний, то надо либо использовать совсем готовое решение, в виде шаред хостинга, либо опять же готовое - managed VPS где тоже всё сделает хостер, либо нанимать кого-то всё же.

Он и близко не готовый - он слегка работоспособный. Надо отчётливо понимать, что установка любой панельки, это отнюдь не настройка сервера.

Выше никто не устанавливал mod_php - не смущает?

Не спасёт, а позволит хоть как-то работать.

Ещё как возникают: масса народу живёт в продакшене с настроенной первым попавшимся школьником за 3 копейки, по первому попавшемуся мануалу, виртуалке, и думают, что у ни всё ок.
Вон там "серверист" не знает как php поставить же - вполне похоже.

Кстати, если это действительно академический интерес, то есть готовые докер контейнры под это, поднять которые, можно практически где угодно. А вот в продакшене, я бы не стал такое рекомендовать.

Для нормального ответа на вопрос, надо бы уточнить, хотя бы, куда надо ставить, какой дистрибутив, для каких целей - продакшен или разработка и.т.п.

Не всё так однозначно - кеширование хороший приём, но не панацея. и не всегда применимо. И производительность без кеширования бывает весьма важна.
И даже при кешировании, надо не забывать, что кеш надо иногда и перестраивать.

Это по меньшей мере не совсем так; используются некоторые компоненты Symphony.
Переписать в специализированное решение на том же Symphony, будет не легче чем 7, если подумать. И в том и в другом случае придётся просто делать приложение с нуля.

А по sftp? Какой вообще доступ имеется?
И если не имеется, может вам и не стоит туда лезть?
Или вопрос вообще имеет не техническое, а административное решение?

Если защита правильно построена, то даже закинув, не получится воспользоватся.

При правильном развёртывании пользователь/группа от которой запущен php не должны иметь прав записи вне sites/*/files и временной папки, просто из соображений безопасности, а в этих папках должна быть запрещена обработка скриптов...

Именно поэтому сделан такой костыль с использованием ftp для обновления. И как мне кажется, лучше вообще бы отсутствовала возможность обновления из админки - для этого есть куда более разумные методы.

Я вам даже больше скажу: не работает так, как задумано автором, или не работает универсально(и не сказано в каких случаях должно работать), более 90% таких пошаговых инструкций. И не надо их плодить. Особенно тем, кто даже сам не понимает, что делает.

Написание подобной инструкции, это реально большая и сложная работа, требующая довольно высокой квалификации, чтобы хотя бы грамотно написать область применимости инструкции, и продумать все последствия описанных действий.

Если вам нужен только форум, то выбирайте специализированный форумный движок. Раз освоили темизацию в Drupal будет просто, возможно, даже очень просто.

Если вам нужна интеграция с другими, не свойственными форумам функциями, можно либо реализовать всё нужное на Drupal - это не так и сложно, но не очень эффективно, либо воспользоваться готовой интеграцией с каким-нибудь phpBB или ещё чем-то.

Если используется nginx + apache, и терминируется ssl на nginx, то проксирующий локейшен должен передавать параметр
proxy_set_header X-Forwarded-Proto $scheme;

А в конфиге виртуального хоста апача надо прописать:
SetEnvIf X-Forwarded-Proto https HTTPS=on

Иначе апач просто не знает, что работаем мы по https.

Ну а редирект это уже по вкусу, если он нужен.

Это один из кусков, работоспособный, и даже не плохой. Но, обычно, куда выгоднее, в итоге, использовать простаивающие процессоры на серверах хранения/раздачи.

Можно как из кубиков собрать всё решение, хранить в облаке, стримить из специализированного CDN, конвертить в zencoder, но всё равно надо будет разработать промежуточный слой, который всё это свяжет воедино и с CMS.
Это будет дешевле, конечно, в разработке, но в перспективе, это будет просто золотое решение, если будет хоть какой-то трафик. И заодно, это будет очень жёсткий vendor lock.

Это тоже не решает задачу, кстати. Для бложека какого-нибудь пару видео вставить сокнвертировав на ютубе, а ещё лучше даже с него и вставить - да. А для сайта, где видео основной контент, это, конечно, не вариант.

Вообще с конвертацией всё не так плохо, как раз. Конвертация выполняется по очереди, и не так много на это ресурсов и надо, обычно - редко где добавляются видео 24/7 и по многу. Ну и она очень легко масштабируется горизонтально, если это нужно и видео много.

Но вот нормального решения, которое объединяет: