Что быстрее Memcache или file_get_contents()

[fixxxer]

5). Обязательно один раз в коде делаем realpath() и получаем реальный путь до текущей версии. Далее ходим только по нему.

ну неактуально же сто лет как realpath cache появился я уже и не вспомню где.

или это в смысле безопасности переключения симлинка? а не проще без симлинка? =)

 

[~WR~]

Нет, без симлинков становится возможен вот какой сценарий.

1). Запустили длинный скрипт. Он работал какое-то время и прочитал часть файлов конфига.
2). Разложили новую версию конфига.
3). Скрипт продолжает работать и читать другие части. Но они уже от новой версии.

Идея с realpath в том, чтобы один запуск скрипта всегда работал только с одной версией конфига no matter what.
Даже если будет раскладка новой версии, ранее запущенные скрипты спокойно продолжат пользоваться старой.

 

[fixxxer]

ну я вот делаю так, чтобы где-то в $_SERVER всегда был полный путь от корня, что я делаю не так? )

 

[~WR~]

По смыслу, эта сущность живет и раскладывается независимо от кода.

Скажем, активная версия кода живет в /local/www/
Активная версия конфига в /local/config/223/
Симлинк на активную версию конфига: /local/config/current/

Путь в $_SERVER будет смотреть на сам скрипт.

Мы же хотим один раз получать реальный путь к конфигу: $this->config_path = realpath('/local/config/current');
И потом использовать его для всех остальных запросов в рамках этого скрипта.

 

[fixxxer]

$_SERVER['APP_PATH'] = /local/application/344/
$_SERVER['CFG_PATH'] = /local/config/254/

в чем проблема?

вот тебе кстати вопрос на засыпку. конфиг nginx - это приложение или конфигурация?

 

[~WR~]

А, я понял. Нет проблем По сути, то же самое, только вид сбоку.

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

Здесь уже не всё так однозначно.
Но, если таких сложностей не нужно, то разницы нет.

 

[fixxxer]

А зачем на продакшене перебирать варианты? Там можно сразу разложить смердженное для данной среды.

На девеле то да, у меня вообще рекурсивный мержинг CFG_PATH/$configName.config.php + CFG_PATH/$envName/$configName.config.php

UPD
Кстати, с realpath надо аккуратно - некоторые опкод-кэшеры вполне могут оверрайдить realpath cache на персистентный. Кажется, новоявленный ZendOptimizerPlus такое делает при определенных настройках.

 

[~WR~]

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

В нашем случае, физически файлы конфигов и версии одинаковы для продакшна, стейджинга и девела.
Разграничение по environment'у делается на стадии проверок в коде. И оно инкрементальное.

Например:

env=0 //выключено совсем
env=1 //включено на девеле
env=2 //включено на девеле и стейджинге
env=3 //включено на девеле, стейджинге и продакшне

Включить что-то только на продакшне, но выключить на девеле в принципе нельзя. Специально сделали такое ограничение, чтобы тесты всегда проверяли версию, максимально близкую к продакшну.
Без него будет возможна ситуация, когда у QA на стейджинге нет никаких проблем, а на продакшне всё сломалось, т.к. для продакшна что-то внезапно оказалось включено.

 

[fixxxer]

чото сложно.

не проще ли на staging делать стандартный деплой с продакшен конфигурацией, и если все окей, те же tarball-ы на прод?

 

[~WR~]

Кстати, с realpath надо аккуратно - некоторые опкод-кэшеры вполне могут оверрайдить realpath cache на персистентный.

К счастью, пока не сталкивался. Вот ведь негодяи!

 

[~WR~]

Наоборот - так сильно проще.

Реальная ситуация: добавляется новый метод оплаты в Зимбабве.
С одной стороны - нужны изменения в коде, которые будут показывать формочки и обрабатывать реквесты.
С другой стороны - ему сразу нужны цены в конфиге.

Выкатываем новые конфиги на стейджинг и продакшн.
Выкатываем код на стейджинг. Смотрим, что всё работает.
Выкатываем код на продакшн. Он сразу же начинает работать точно на тех же конфигах, которые только что были проверены.

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

 

[~WR~]

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

Если это будет не так, то базы продакшна и девела очень быстро разойдутся.
Поддерживать их одинаковость всем в лом - проверено. Особенно если там 50+ таблиц.

И девел должен максимально повторять поведение продакшна. Тесты должны гоняться в условиях, максимально приближенных к боевым.
Отсюда такой интересный финт, который, тем не менее, приходится часто объяснять новеньким.

 

[fixxxer]

Так, ну подожди, а я разве не о том же самом?

Есть production сборки конфигов, тегом stable мечено то, что на прод. Есть новый конфиг (head). Есть новый код.
1) выкатили config/head на staging
1.5) тут тоже неплохо проверить, что с новым конфигом старая прод-версия - которая пока еще на staging - внезапно не ломается
2) выкатили новый код на staging
3) протестировали, работает
4) меняем тег, выкладываем новый (уже -stable) конфиг на прод
5) деплоим новый код на прод

В каком месте разница, чото не пойму

 

[fixxxer]

Девел-конфиг, конечно, не должен писаться каждым с нуля.
Я ж говорю - подкаталог с именем devel-среды (у каждого своя), там только оверрайды (рекурсивный аналог array $defaults + array $custom). Базовый devel-конфиг максимально приближен к production.