Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
Спасибо отплюсовал.
Было бы интересно, как автор решает проблему настроек которые должен менять админ сайта? Гонять клиента менять файлы — несколько не кузяво. Пользователю удобней использовать GUI.
С другой стороны — разработчику проще работать с конфиг файлами и использовать везде чтото вроде Config::get('key').
В идеале, должно быть два уровня конфигов — первый это файлы которые меняют разработчики. Второй, настройки которые юзер задает из GUI.
Если одни и тот же ключ встречается в обоих слоях — уровень юзера побеждает. То есть если в конфиге 'blog.post_per_page' = 10
a юзер в GUI поставил 20, то для кода
'blog.post_per_page' = 20
Собственно я к чему — не видел ли кто ни будь уже готовой реализации такой идеи?
Было бы интересно, как автор решает проблему настроек которые должен менять админ сайта? Гонять клиента менять файлы — несколько не кузяво. Пользователю удобней использовать GUI.
С другой стороны — разработчику проще работать с конфиг файлами и использовать везде чтото вроде Config::get('key').
В идеале, должно быть два уровня конфигов — первый это файлы которые меняют разработчики. Второй, настройки которые юзер задает из GUI.
Если одни и тот же ключ встречается в обоих слоях — уровень юзера побеждает. То есть если в конфиге 'blog.post_per_page' = 10
a юзер в GUI поставил 20, то для кода
'blog.post_per_page' = 20
Собственно я к чему — не видел ли кто ни будь уже готовой реализации такой идеи?
Видел. И даже класс готовый есть -))) Не совсем так, как Вы описали, но похоже.
Но если я его сюда выложу — это потянет за собой всю CMS…
Но если я его сюда выложу — это потянет за собой всю CMS…
Ага, я знал что я не сумасшедший и такой ф-ционал в реальности нужен! :) А где ни будь в действие посмотреть можно?
собственно, имхо, самое сложное тут генерация GUI для юзера. :)
Я просто думал может где то в недрах Zend илл Pear есть чтото подобное, что бы пилить свой велосипед уже на пустом месте :)
собственно, имхо, самое сложное тут генерация GUI для юзера. :)
Я просто думал может где то в недрах Zend илл Pear есть чтото подобное, что бы пилить свой велосипед уже на пустом месте :)
Я сейчас пишу в свободное время небольшой велосипед фреймворк. Там у меня имеется два конфига. Первый в формате plain PHP, в котором я определяю массив $starterConfig, где хранятся данные, необходимые для старта приложения (пути к ядру, шаблонам, etc..., маршруты для автолоадера, параметры подключения к БД). По идее этот конфиг должен правиться вручную (не решил ещё по поводу целесообразности инсталлятора). Вот его после этой статьи думаю перевести на ini и закрыть .htaccess'ом.
А второй конфиг — это уже всё остальное. Он лежит в базе, правиться будет в гуёвой админке. Систему кэша ещё не писал, но думаю либо целиком в память положить, либо разбить на категории и кидать на диск (по-хорошему надо бы обе системы реализовать и выбирать конфиг по убыванию память -> диск -> бд).
Так вот, суть в том, что у меня главный конфиг (второй) подгружается после стартового в тот же массив. Таким образом, одинаковые ключи будут перекрыты, причём приоритет будет у того конфига, который был отредактирован в админке.
А второй конфиг — это уже всё остальное. Он лежит в базе, правиться будет в гуёвой админке. Систему кэша ещё не писал, но думаю либо целиком в память положить, либо разбить на категории и кидать на диск (по-хорошему надо бы обе системы реализовать и выбирать конфиг по убыванию память -> диск -> бд).
Так вот, суть в том, что у меня главный конфиг (второй) подгружается после стартового в тот же массив. Таким образом, одинаковые ключи будут перекрыты, причём приоритет будет у того конфига, который был отредактирован в админке.
function getConfigVar($num) {
static $conf = null;
if($conf===null){
$conf = readconf();
}
return $GLOBALS['config_cache']["var_" . $num];
}
А вобще задача крайне надуманна. Ни разу не встречал приложения перечитывающего весь конфиг при обращении к каждому ключу — это опасно!
*return $conf[«var_». $num];
Конечно надумана. Я честно об этом предупреждаю в конце поста.
Ключевое слово крайне. Какой смысл сего топика?
Писался когда-то для песочницы. Текст сохранился.
В предыдущем топике в комментах попросили выложить, я не отказался.
Выложил в личный блог, поскольку для коллективного ценность слишком мала.
Я ответил на все Ваши вопросы?
В предыдущем топике в комментах попросили выложить, я не отказался.
Выложил в личный блог, поскольку для коллективного ценность слишком мала.
Я ответил на все Ваши вопросы?
Да, спасибо :) В топике не было ссылки на этот топик и только сейчас нашел коментарий который породил этот топик.
Я не совсем соглашусь — при большой нагрузке вопрос становится актуальным.
Случай из практики — по недосмотру, не включили на продакшене кеширование конфигов. Так в час пик сервер чуть не помер, пытаясь считать из FS файл с конфигамми для каждого запроса…
Случай из практики — по недосмотру, не включили на продакшене кеширование конфигов. Так в час пик сервер чуть не помер, пытаясь считать из FS файл с конфигамми для каждого запроса…
Интересно, какой смысл хранить 1000 параметров конфига в одном файле?
Плюс, время сохранения конфига почему-то включает в себя и затраты на его генерацию.
Плюс, время сохранения конфига почему-то включает в себя и затраты на его генерацию.
Вы невнимательны, я нигде не замеряю время генерации, только время считывания. Время генерации не имеет никакого практического значения.
А 1000 параметров в одном файле создается с одной лишь целью — чтобы увеличением количества испытаний повысить их достоверность.
Азы численных методов, второй курс…
А 1000 параметров в одном файле создается с одной лишь целью — чтобы увеличением количества испытаний повысить их достоверность.
Азы численных методов, второй курс…
Ох. Тысячу раз уже выяснили на самых разнообразных тестах, что (un)serialize быстрее всех, а include самый медленный (вру, require медленнее :). Хорошо, что ничего не изменилось.
Cравнение ini, php, xml, db: www.phpro.org/articles/Application-Configuration.html
Спасибо.
Сравнение интересное, но как-то про XML странно написано, вроде он быстрее всех, а победила DB
Первый тест проходил на небольшом количестве конфигурационных опций, а во втором это было 1000 секций по 3 переменной в каждой. База показала лучший результат как раз на втором тесте.
Спасибо, теперь понял, целиком не читал. Вывод — конфиги БД (и то, что может понадобиться до старта или при ошибке старта БД) храним в XML, а все остальные в БД :)
Ну сериализация будет быстрее XML.
Я в последнее время использую такую схему:
0) Исходный файл конфигурации может быть XML или PHP, как удобней.
1) При старте проверяю наличие данных конфигурации в мемкеше (может быть и обычный файл, в котором конфигурационные данные сериализованы).
2) При наличии кеша проверяю его актуальность (по дате модификации исходного файла конфигурации).
3) Ну и собственно, юзаю данные из кеша или занова парсю конфигурационный файл.
Я в последнее время использую такую схему:
0) Исходный файл конфигурации может быть XML или PHP, как удобней.
1) При старте проверяю наличие данных конфигурации в мемкеше (может быть и обычный файл, в котором конфигурационные данные сериализованы).
2) При наличии кеша проверяю его актуальность (по дате модификации исходного файла конфигурации).
3) Ну и собственно, юзаю данные из кеша или занова парсю конфигурационный файл.
Ты еще забыл базу данных, в которой хранится табличка с конфигом, потом из нее массив и еге можно serialize и хранить хоть на диске, хоть в памяти. — на мой взгляд, оптимальный вариант
Вариант с хранением изначально всего конфига в serialize — не катит, так как забодаешься высчитывать
Вариант с хранением изначально всего конфига в serialize — не катит, так как забодаешься высчитывать
Вариант с базой данных плох тем, что подключение к БД тоже надо как-то конфигурить :)
Неидеально, согласен — все зависит от того кто будет админить сайт/аппликуху и количество файлов-конфигов.
Если админ/appmanager — то пусть все в require_once — ручками в терминалке удобней
Если юзверь — то нужна веб-морда с базой
Если админ/appmanager — то пусть все в require_once — ручками в терминалке удобней
Если юзверь — то нужна веб-морда с базой
Не поспоришь :) Но настройки которые меняет юзер, надо же гдето хранить. Конечно можно в XML сохранять… Но как то не хочется с ним связываться. Лучше уже потерплю несовершенство мира и буду считать что дефолтовое подключение к БД уже есть. :)
1000 строк? Вы postfix переплюнули.
Кстати, конфиг не влом и хранить в мемкеше (apc/memcached) и при ручном изменении — обновлять.
Кстати, конфиг не влом и хранить в мемкеше (apc/memcached) и при ручном изменении — обновлять.
Зачем в мемкеше-то?! Мемкеш наамного медленнее чем переменная в приложении. На кой черт он нужен для хранения жалких 1000 строк? И вопрос, заданный предыдущему оратору: где тогда хранить настройки мемкеша? :)
Ну конфиг, который хранится в переменной, умрёт вместе с копией скрипта. А мемкеш будет виден всем запущенным копиям. Разве не так?
А он не умрет вместе с перезапуском мемкеша, или не будет затерт более новыми значениями? Просто я с мемкешем особо не разбирался, пару статей прочёл и всё. После них у меня сложилось мнение, что мемкеш не гарантирует сохранности данных ни при рестарте, ни при исчерпании доступной памяти. То есть это именно кеш, который надо каждый раз проверять на попадание, а если не попал, то брать данные с постоянного хранилища (ну и занести их заодно в кеш, надеясь, что в следующий раз попадешь :) ). Я не понял концепцию работы с ним?
По сути, получается именно кэш. Только лежит не на жёстком диске, а непосредственно в памяти.
Memcached — это сторонний сервер, у не го открыты порты, по которым с ним можно работать. У пыха, после подключения соответствующего модуля, апи для работы с ним на уровне абстракции «положить в кеш, достать из кэша». Соответственно, данные хранятся в области памяти сервера кэша, а не пыховского скрипта. Поэтому он не умрёт вместе со скриптом.
Да, мемкеш не гарантирует сохранности данных.
При нехватке памяти очищается наиболее старый кэш.
Более новыми значениями затрёт в том случае, если в коде это будет. Нужно просто делать нормальны проверки на актуальность, тогда затираться нужные данные не должны.
Memcached — это сторонний сервер, у не го открыты порты, по которым с ним можно работать. У пыха, после подключения соответствующего модуля, апи для работы с ним на уровне абстракции «положить в кеш, достать из кэша». Соответственно, данные хранятся в области памяти сервера кэша, а не пыховского скрипта. Поэтому он не умрёт вместе со скриптом.
Да, мемкеш не гарантирует сохранности данных.
При нехватке памяти очищается наиболее старый кэш.
Более новыми значениями затрёт в том случае, если в коде это будет. Нужно просто делать нормальны проверки на актуальность, тогда затираться нужные данные не должны.
Значит правильно понял, хранить, как предложил andrew_tch («тредстартер»), конфиг в мемкеше нельзя, можно его там кешировать для разных экземпляров приложения, чтоб каждый раз не перечитывать. Но хранить его все равно где-то надо и хотя бы раз оттуда загрузить из мемкеша. А значит вопрос поднятый в посте всё равно актуален :)
Омайнготт… Ну что Вы все так к этой тысяче привязались?
Как же по Вашему достоверно измерять сравнительное время выполнения скрипта? Один раз на одной переменной?
Как же по Вашему достоверно измерять сравнительное время выполнения скрипта? Один раз на одной переменной?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вдогонку к предыдущему посту или О разных методах хранения конфигов