Flying

Если в посмотрите в исходный код, то увидите что Request::getScheme(), которую использует Request::getSchemeAndHttpHost() вернёт вам https в зависимости от того признан ли запрос безопасным или нет методом Request::isSecure().

Сам метод isSecure(), как видно по коду, возвращает true в двух случаях:

1. Либо это HTTPS запрос и есть соответствующий заголовок
   
2. Либо это запрос от доверенного proxy сервера и сервер передаёт информацию о том что оригинальный запрос безопасен
   

Таким образом я бы предположил что у вас используется схема nginx + php-fpm и либо nginx некорректно сконфигурирован и не передаёт нужные данные либо nginx не указан в качестве trusted proxy.

Здесь есть несколько путей:

1. Если это что-то простое и вы работаете с Symfony Framework (т.е. не со standalone контейнером) - то вам просто необходимо описать ваш сервис в конфигурации сервисов (в Symfony 4 и выше это config/services.yaml). Как это делается - описано в документации. Описание стандартного controller_resolver можно увидеть здесь, в Yaml это будет выглядеть вот так:
   
   

   services:
     controller_resolver:
       class: Full\Name\Of\Your\Implementation
       arguments:
        - '@service_container'
        - '@?logger'
      tags: 
        - {'name:':'monolog.logger', channel: 'request'}

   
   ваша реализация, конечно, может отличаться по зависимостям.
   
   
2. Если это что-то более сложное - то настройка сервисов производится через compiler pass. В них вы имеете полный доступ к ContainerBuilder и можете программно сформировать в нём всё что вам необходимо. Однако сомнительно что в данном случае вам это потребуется.
   

В целом все эти вопросы очень подробно разобраны в документации компонента Dependency Injection.

Проблема Composer'а с потреблением памяти при обновлении с большим количеством зависимостей - весьма известная, достаточно посмотреть в их issue tracker (1,2 и множество других).

Jordi Boggiano, один из авторов Composer говорит (к примеру здесь) что проблема будет принципиально решена во второй версии, которая сейчас в разработке.

Aside note: обычно команды, модифицирующие список пакетов (и требующие для этого кучу памяти) стоит запускать только при разработке (т.е. к примеру на вашей локальной машине), для деплоя проекта необходимо использовать composer install, а он много памяти не требует.

1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.
   
   dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
   
2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
   
3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack
   

Criteria - это просто возможность сформировать какое-то относительно сложное условие для QueryBuilder, не более того.

Вам необходимо определиться с тем что именно вы хотите сделать:

• Если вы хотите выбрать данные из связанных таблиц - то это можно сделать через QueryBuilder с гидрацией, к примеру, в массив. В этом случае запрос будет ровно один - тот что вы запускаете
  
• Если вы хотите выбрать entities - то логика этих выборок определяется UnitOfWork и в общем может как приводить к 10 запросам так и не приводить в зависимости от содержимого identity map. Т.е., условно говоря, если бы связанные entities уже были бы в identity map - повторной выборки бы не происходило. Также выборки бы не происходило если бы вы обращались к identity полю связанной entity. Однако вы запрашиваете данные из связанной entity, причём делаете это раздельно для каждого entity, почему же вы ожидаете что Doctrine не полезет в базу за этими данными?
  

Использую связку puppeteer и pm2. Scraper запускается в несколько instances, контролируемых pm2, каждый из них использует свой puppeteer. Scraper прогоняет N циклов и корректно выходит, закрывая браузер, но pm2 настроен на автоматический перезапуск - это позволяет избежать выедания всей памяти. Всё это крутится на пачке самых дешёвых vps по 1-2 евро в месяц за штуку, такого обычно хватает на 3-4 instance'а (из-за прожорливости Chromium).

В зависимости от специфики цели параметры могут варьироваться, в частности можно неплохо сэкономить если можно не запускать Chromium, а сделать всё средствами самой node.js, но тут надо знать специфику вашей задачи.

Это следствие разных алгоритмов обработки суб-пиксельных вычислений т.к. браузерам всё равно в конечном итоге приходится рисовать страницу на экране, состоящем из пикселей. В случае hi dpi экранов, где за один логический пиксель отвечает несколько физических задача решается проще, но для экранов с dppx=1 приходится делать выбор и вот этот выбор делается по-разному.

На больших контейнерах это незаметно, а для маленьких - да, есть шанс того что элемент будет выглядеть "криво". Какого-то универсального решения здесь, судя по всему, нет, остаётся только подгонять, добавляя отступы в 1px туда или сюда для разных браузеров. Для того чтобы добавить CSS код только для какого-то конкретного браузера можно воспользоваться, к примеру, информацией с browserhacks, хотя, конечно, тут надо быть осмотрительным.

Ваша задача по сути сводится к динамическому обращению к переменным. Sass так не умеет. Для реализации вам необходимо сменить структуру данных и использовать maps.

Т.е. ваш код мог бы выглядеть как-то так:

$vars: (
  1 : #333,
  5 : #111,
  100 : #222,
);

@mixin div-color($id) {
  @if (map-has-key($vars, $id)) {
    color: map-get($vars, $id);
  }
}

Посмотреть в действии можно на Sassmeister.

https://gs.statcounter.com/