VasyOK wrote: После этого он работает по адресу:
http://:8983/solr/

В этом случае, возможно лучше повесить его на 127.0.0.1:8983

VasyOK wrote: Couldn't index items. Check the logs for details.

Что я сделал не так?

Надо почитать логи, как предлагают, и станет понятнее...

Всё потому, что кешированием должно заниматься приложение, а не веб сервер или ещё что-то стороннее.
Соответственно, решать что кешировать, и что ещё важнее, что и когда инвалидировать правильно там, где есть данные для этого. С varnish это ещё теоретически возможно, с nginx fastcgi microcache каким-нибудь или кешом на стороне apache, и вовсе нет.

В общем, нет какого-то лучшего кеша для drupal(или чего-то ещё), есть более или менее подходящие хранилища для разных случаев.

Вот только нафига при этом, иметь хотьт одну версию Apache на машине, я не знаю.

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

Потому что в nginx они есть. Fastsocket например

Это не о том. Это о работе с клиентами по сети.

Естественно - mod_php экономит на межпроцессном взаимодействии запускаясь внутри процесса apache.
Но это всё ничтожно на фоне выполнения сколько-то сложных скриптов.

А зачем вообще сетевые сокеты использовать, если php-fpm и apache на одной машине? Unix сокеты имеют меньший оверхед, и когда говорят о сокетах, в данном случае, имеют в виду именно их.

Это просто не нужно никому. Чаще всего используют в таких сценариях другие web серверы.

Есть group, но это больше о доступе к контенту групп, не о пользователях.
Но может задача такова, что этого будет достаточно.

Здесь вы присваиваете алиас команде /opt/php8.2/bin/php -d memory_limit=500M ~/composer.phar. Если она у вас в таком виде нормально работает, и с алиасом должно быть всё ок.

Очень зависит от запроса. До этого могут происходить разные join и сортировки, которые и составят основную нагрузку которую создаёт запрос...

Советую познакомиться поближе с отладкой sql запросов, начиная с EXPLIAN.

дубль

Крайне не рекомендую слепо следовать этим рекомендациям не понимая, что меняется и зачем.
Это совсем не кнопка "сделай хорошо". А как и различные pagespeed, и подобные инструменты, это набор общих рекомендаций, исполнение которых, в определённых условиях, может помогать, может не помочь вообще в конкретной ситуации, а может сделать даже хуже в определённых ситуациях.

Например, такой здоровый innodb_log_file_size не часто нужен в принципе. innodb_buffer_pool_size делать такого объёма, возможно, тоже не нужно в вашем случае, даже если базы суммарно в вас и больше и.т.п.

Автоматизацию работающую не на паре тройке простых случаев будет _очень_ сложно написать...

Так это не техническая проблема - если клиент не хочет оплачивать реботу, вероятно её не стоит вообще делать.

Обновление с 7 до следующих версий это фактически создание нового сайта и миграция данных... Это не какая-то дешёвая рутинная операция. Если клиент этого не понимает, ну увы. Может и не надо с ним работать?

Ну во-первых, надо наверное почитать документацию о логе медленных запросов, установить нужный лимит на длительность запроса и.т.п.
Также в realtime можно посмотреть что происходит в mysql/mariadb с помощью утилиты mytop.

При этом, надо смотреть ещё потребление ресурсов. Там куда интереснее будет картина - потребление памяти в случае apache должно быть заметно больше, и больше зависеть от количества подключений. А именно в скорости разница не велика, собственно всё время почти в php-fpm, который тут одинаков.

Ну и сравнивать имеет смысл c apache + mod php. Apache + php-fpm в принципе довольно странная связка.

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

Я, вот, всё это неплохо умею, но почта моих доменов обслуживается одним из хостеров за мелкую копеечку, а не на одном из моих серверов.

Вообще-то не совсем всё так плохо. Часть адресов действительно находится в блек листах, если на них были кривые почтовики, или ими пользовались спамеры, но это решаемая проблема.

SPF это просто TXT запись, и она должна быть просто правильно указана. Т.е. указано откуда можно принимать вашу почту.
А вот с DKIM, всё куда сложнее. Это криптографическая подпись письма на стороне отправителя. Оно не только в DNS, оно и на сервере, собственно, подписывать должен какой-то софт, который надо настроить, сгенерировать пару ключей, и публичный ключ поместить в ту самую DNS запись.

То нужно что-то что позволит с ним работать, по нужному протоколу. Например, если это smtp, то это может быть и https://www.drupal.org/project/smtp, и https://www.drupal.org/project/symfony_mailer с smtp транспортом и наверняка ещё есть что-то.

Если не используется внешний почтовый сервер, конечно нужно - чем-то посылать-то всё равно нужно.

Всё что ставится на стороне Drupal, требует чего-то внешнего:

• это может быть и внешний сервис
• почтовый сервер на стороне той же виртуалки
• почтовый сервер на стороне хостера

Модули просто дают разные дополнительные возможности, например, делать атачи, использовать не только php mail(), использовать какие-то не smtp сервисы для отправки и.т.п. Т.е. расширяют возможности взаимодействия с почтой, но не доставляют её клиентам непосредственно.

Так она чаше всего и будет в спаме - этого мало.
Как минимум, надо настроить SFP запись, DKIM, например с помощью opendkim, и PTR соответствующий имени хоста почтовика.

С минимальными знаниями внешний сервис. Их много.

Чтобы доставлялось как-то со своего сервера, минимально надо проверить и настроить SPF, DKIM, PTR. А также пробить ip виртуалки по спам листам.

Sendmail такое себе решение, сложное и устаревшее.
Лучше и проще настроить postfix или exim.
Чтобы настроить почтовик надо немало знать, на самом деле о том, как это всё работает, чтобы настроить его для своей задачи. Брать какой-то пошаговый howto довольно бесполезно в любых ситуациях, а в этой и подавно... Даже если будет работать, доставляемость чаще всего будет никакая. Без этих знаний куда разумнее будет использовать готовый внешний сервис.