Лучше всё же csv, т.к. большие объёмы данных + импорт из xls = огромное потребление памяти и проблемы, а сохранить из excel csv дело пары кликов...

При том, что скачивается с помощью curl, архив с модулями, а ошибка там вылезает, при проверке сертификата drupal.org. Надо либо обновить curl, что часто, можно сделать только с обновлением версии дистрибутива, либо подсунуть ему свежие коневые сертификаты.

drush выдаст ту же ошибку, а с -v можно будет посмотреть, в чём действительно дело...

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

Drush использует тот же curl, и те же корневые серитфикаты. И проблему в данном случае не решит...

Чаще всего, такая ошибка бывает, если старый curl и у него проблемы с сертификатами.

Если это шаред хостинг, и обращение в техподдержку не решает проблему, то да - смена хостинга, т.к. у вас нет возможности исправить данную ошибку.

Создать какого-нибудь пользователя, и всё, кроме настройки сервера, и установки серверного ПО делать из под этого пользователя, а не из под root, конечно.
Предупреждение не мешает запустить composer, но оно вполне обосновано, и помогает избежать ошибок...

Начать стоит с чтения логов. И хотя бы, рассказать, как настроена почта, что используется для отправки, где хостится сайт.

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

По домену лукавство, если бы это было так, то никакой атаки на drupal.ru бы не проводилось. А dru.io спокойно развивался бы как хотелось его создателям. Но домен и посещаемость, на самом, деле являются ключевым активом...

Тогда надо ставить вопрос об упрощении страниц, вероятно.
Но на деле, не бывает практически никогда так, чтобы при 3 секундах загрузки не было бы проблем, которые надо было бы решить... А то, что нет в calltrace какого-то одного блока выполняющегося очень долго, в общем-то не показатель, надо смотреть самые вызываемые, может быть, что-то вызывается слишком много раз просто.

И этот прогретый кеш будет использоваться на доли процента, кушая массу памяти при этом? И это будет маскировка проблемы, а не решение...

На самом деле, надо взять профайлер, найти причину долгого построения страниц, и исправить.
А память отдать туда, где она будет действительно полезна, например, тому же mysql. Или для кеширования entities в memcached, или ещё для чего-нибудь полезного.

Что происходит с mysql можно посмотреть с помощью mytop, например.
Вероятно, там продолжает выполняться какой-то тяжёлый запрос.

Ну тогда мистика же какая-то?
Нормально-ли прошло обновление базы(запуск update.php), и нет-ли чего-то по этому поводу на странице отчёта о состоянии?
Может быть всё же был перепутан архив?

У меня на нескольких сайтах вполне штатно прошло обновление, правда, я использую drush для этого, но он по сути делает то же самое...

Но ведь так и должно быть, если в архиве был 7.50, как у вас написано выше. Нужно было заливать 7.57 чтобы не предлагалось обновление...

Это можно сделать на своём VPS, или сервере. На шаред хостинге-то не выйдет...

1. Какой у вас дистрибутив?
2. В зависимости от дистрибутива надо поставить wkhtmltopdf через пакетный менеджер. А если это невозможно(нет пакета, например), то поставить с его помощью все зависимости хотя бы(zlib, fontconfig, freetype, libX11, libXext, libXrender) - просто скачивания исполнимого файла совершенно не достаточно...
3. Класть что-то в /usr/bin руками, не очень хорошая идея. Для таких вещей больше подходит /usr/local/bin тогда уж.

Тут не подключаются внешние скрипты через file_get_contents().
Ошибка-то тут: https://api.drupal.org/api/drupal/includes%21locale.inc/function/_locale...

А вот как и где на, самом деле, подключён jQuery c гуловского CDN, и почему он обрабатывается этой функцией, надо посмотреть...

Кеш фрагментов всегда разумнее делать на уровне приложения, где можно правильно проводить инвалидацию и регенерацию кеша, а не где-то снаружи, где это можно делать только по жёстким ttl...

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

В большинстве случаев никто этот reject не прочитает всё равно, тем более автоматически, а письмо доставлено-то в итоге не будет...
А смысл моего комментария был в том, что эту задачу, в принципе, лучше решать иначе, например, разместив ссылку на файл (судя по коду он один для всех писем), вместо атача, например.

Последние два бывают нужны, как раз... А вот память которую скушает varnish всегда можно применить более разумным образом.

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

Но вот одно наблюдение:
Практически всегда, когда разговор заходит о varnish, это говорит о том, что разработчики не понимают, как надо решать проблемы с производительностью, или хотя бы как их найти, и думают, что он станет "таблеткой для решения всех проблем", а в реальности этого, конечно, не происходит - это в 90% случаев просто не подходящий инструмент, а в остальных 10% плохо работающий...

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

Если речь про Linux, то есть inotify и icron. С помощью icron можно что-нибудь выполнять при каких-то действиях с файлами. Например, запускать скрипт. Но, кстати, не уверен, что можно будет класть в корзину этот файл, если не будет где-то ещё его копии...

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

Всё верно. Каждый процесс php выполняется только на одном ядре, как и каждый запрос mysql.
Для масштабирования, если оно вообще нужно, можно использовать, например очередь сообщений и множество обработчиков.

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