Вадим Степанов

Deployer создает при каждом запуске новую папку с увеличивающимся номером в releases. Но при этом последний успешный релиз всегда доступен по символьной ссылке в current
Т.е. получается что-то типа
releases/1
releases/2
releases/3
current ---> releases/3
shared

Чем вас не устраивают символьные ссылки? Они достаточно удобны в данном случае.

Разве что надо после деплоя надо перезагружать php-fpm, т.к. иначе активные рабочие процессы будут пользоваться старым значением символьной ссылки (в смысле будут обращаться к предыдущему релизу).

Настройте ваш web-сервер, чтобы загружал проект из папки current.

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

А каким образом ElasticSearch узнает что надо фразу "Коммутатор Connexium 14TX/2 бюджетный" разбить на несколько вариантов с перебором слов, причем каждый раз "Коммутатор" должно быть в начале?

Как вариант - попробуйте вручную генерировать варианты запросов. Например, для приведенной вами фразы должно получиться дополнительное поле с массивом:
["Коммутатор", "Коммутатор Connexium", "Коммутатор бюджетный", "Коммутатор Connexium 14TX/2"]

И уже по этому полю можно будет писать аггрегацию.

Первое что приходит в голову - используйте вариант, описанный тут: https://www.elastic.co/guide/en/elasticsearch/guid...

Хорошо описан вариант как сделать ре-индекс без остановки приложения.

По поводу того, что делать с документами, которые могут быть изменены в процессе выполнения реиндекса. Есть несколько вариантов.

Можете использовать вариант, предложенный Захаров Александр - дополнительное поле с датой обновления документа. В таком случае вам надо будет после реиндекса сделать еще дополнительно проход по старому индексу и найти документы с отличающимися датами.
Второй вариант - использовать вместо дат версии документов. Но! Для этого документы во время реиндекса надо переносить вместе с номерами версий (иначе, они все будут добавлены с _version=1).
Третий вариант - комбинация первых двух - использовать свое специальное поле для версий документов и сказать об этом ES - у него есть поддержка использования "внешних версий".

И во втором и в третьем варианте, все равно после реиндекса надо проходить по старому индексу и определять какие документы поменялись.
Худший случай, который вы можете получить: вы делаете реиндекс, в это время в старом индексе меняют документ X. Реиндекс завершается, начинается поиск изменений. В это время документ X снова меняют, но уже в новом индексе. В процессе поиска изменений вы видите что документ X был изменен в старом индексе и его надо перенести в новый - а тут он уже тоже снова изменен. Что делать в таком случае - решать вам. Все зависит от важности данных и можно ли объединить изменения.

Скорее всего ES выполнил стандартный поиск с помощью Term Query. В этом случае не происходит никакой сортировки, кроме как по "score" (по релевантности).
Для вашего случая вам скорее надо использовать
Prefix Query - https://www.elastic.co/guide/en/elasticsearch/refe...
или
Match Phrase Prefix Query - https://www.elastic.co/guide/en/elasticsearch/refe...

Если это будут просто массивы данных, то достаточно использовать стандартный маппинг для поля и обычные запросы query term/terms.

Минимальный маппинг (ES 5.0+)

...
"param": {"type": "keyword"}
...

При заполнении данных просто передаете массив значений. Дополнительно ничего настраивать не надо.

Поиск по одному значению (пример запроса для Sense)

GET your_index/your_type/_search
{"query": {"term": {"param": {"value": "2"}}}}

Поиск по нескольким значениям (пример запроса для Sense)

GET your_index/your_type/_search
{"query": {"terms": {"param": ["2", "1"]}}}

Примерно вот так.

Для ES 5.0+ есть DeleteByQuery API
https://www.elastic.co/guide/en/elasticsearch/refe...

POST index_name/type_name/_delete_by_query
{
  "query": {
    "bool": {
      "must": [
        {"term": {"SITE_ID": "z"}}
      ],
      "should": [
        {"term": {"FILE_ID": "x"}},
        {"term": {"FILE_ID": "y"}},
        ...
      ],
      "minimum_should_match": 1
    }
  }
}

8 Мб изображение JPEG при обработке будет заниматься гораздо больше места в памяти, т.к. происходит его распаковка.

Похоже что после обработки каждого изображения вы не вызываете метод
imagedestroy()

Переход на imagick может и не помочь, если корректно не освобождать ресурсы после обработки.

Перевод с английского искали? Imagick ругается на то, что ему не хватает памяти. Варианты действий:

• добавить скрипту памяти (не самый лучший)
  
• после создания каждой thumbnail-картинки принудительно очищать память для объекта Imagine
  

Какой вопрос - такой ответ. Вынесите код, выполняемый при условии истинного Yii::$app->request->isAjax в отдельный метод и вызывайте его где надо. Всего-то.
Если не то - уточняйте вопрос - что именно и как вы хотите чтобы работало.

Перечитайте еще раз примеры в документации. Во втором примере ( https://www.rabbitmq.com/tutorials/tutorial-two-py... ) они как раз рассказали про Message Durability. Укажите что ваша очередь и обменник durable и тогда чтобы ни произошло RabbitMQ будет хранить добавленные сообщения даже если полностью выключен.

Смотрим https://github.com/2amigos/yii2-file-upload-widget...
Есть одна зависимость от bower-пакета - blueimp-file-upload.

Если вы корректно установили fxp/composer-asset-plugin (composer global install "fxp/composer-asset-plugin:~1.0.3") то проблем не должно быть никаких.

Прочитайте основы CSS. Элемент с float свойством по умолчанию не следит за своей высотой. Для этого требуется сброс в виде<div style="clear:both;"></div>после всех div-ов с любыми значениями float.

Вам на выбор подходят 2 опции:
www.yiiframework.com/doc/api/1.1/CAssetManager#lin... - создает символьные ссылки на assets, когда меняете файлы - они сразу же доступны

или

www.yiiframework.com/doc/api/1.1/CAssetManager#for... - будет всегда принудительно копировать assets при каждом запуске приложения. Отличный вариант поставить в качестве значения константу YII_DEBUG, чтобы только в режиме отладки использовалось это свойство.

В вашем примере behavior описывает только ограничения по типу запроса (GET, POST) на действия. Скажите подробности, что вы конкретно имеете ввиду под автосохранением?

А что пишет? Ошибка какая? Класс прописали в use?