С версии 5.3 php в стандартную сборку входит расширение phar аналог jar в java. В связи с этим, относительно недавно начал использовать новый способ установки портальной системы. Суть в следующем. Заливаем всю систему в одном phar архиве и настраиваем на него .htaccess Дополнительно в файловую систему закидывается файл конфигурации баз данных и директорию для хранения загружаемых файлов. И все. Архив уже содержит в себе все необходимое. Изображения, скрипты установки, исполняемые файлы и шаблоны страниц. В наличие несколько десятков модулей с интернет магазинами, гостевыми книгами, фото архивами и визуальными редакторами. При необходимости любой файл можно заменить положив рядом файл. Архив при исполнении сам найдет и подменит каждый файл вашей заменой. Очень удобно хотел поделиться. Не встречал подобных способов установки портальной системы. Получается что для работы достаточно два файла. .htaccess mpak.phar .htaccess можно взять отсюда https://raw.githubusercontent.com/mpak2/mpak.su/master/.htaccess mpak.phar доступен отсюда https://github.com/mpak2/mpak.su/raw/master/phar/mpak.phar Плюсом в системе будет автоматизированное создание админки, Правится все и вся. Ключи связывваются автоматически вам нужно только правильно указать их имена. И система пересборок при выводе данных в шаблон. Очень удобная штука. Если кратко, работает так: Все таблицы доступны по их именам внутри разделов к примеру cat - категория статей, index сами статьи таблица статей связана с категориями по вторичному ключу cat_id Чтобы перебрать все категории статей а в них все статьи с этих категорий пишем так так Код (Text): <? foreach(rb("cat") as $cat): # Перебираем массив со всеми категориями ?> <? pre($index); # Отображаем поля категории ?> <h2><?=$cat['name']?></h2> <? foreach(rb("index", "cat_id", "id", $cat['id']) as $index): Перебираем все статьи из категории $cat ?> <!-- Все поля статьи сейчас доступны в массиве $index --> <? pre($index); # Отображаем поля статьи ?> <h3><?=$index['name']?></h3> <div><?=$index['text']?></div> <? endforeach; ?> <? endforeach; ?> функции pre($cat) и pre($index) выведут примерно следующее: Код (Text): Array ( [1] => Array ( [id] => 1 [cat_id] => 0 [name] => Первая категория ) [2] => Array ( [id] => 2 [cat_id] => 0 [name] => Вторая категория ) ) Array ( [8] => Array ( [id] => 8 [cat_id] => 2 [uid] => 1 [time] => 1414221579 [name] => Любимчик Фортуны [keywords] => [description] => Джон Ло перевернул всю мировую экономику. [text] => Текст статьи ) [2] => Array ( [id] => 2 [cat_id] => 0 [uid] => 4 [time] => 1412332846 [name] => О проекте [keywords] => [description] => [text] => Текст статьи ) [3] => Array ( [id] => 3 [cat_id] => 0 [uid] => 1 [time] => 1412333588 [name] => Контакты [keywords] => [description] => [text] => Текст статьи ) [9] => Array ( [id] => 9 [cat_id] => 0 [uid] => 1 [time] => 1414254128 [name] => Инструкция [keywords] => [description] => [text] => Текст статьи ) ) Получается, что мы любую страницу можем вообще написать без кода. Установить легко, код минимум, ошибки почти исключены так как лишних файлов в файловой системе просто нет. Обновляется вся система заменой одного файла. Все ваши файлы лежат рядом и при обновлении не изменяются.
Напрягает когда в файловой системе находится три тысячи файлов и большая часть из них относится не к измененным и нужным во время работы а к системным, которые сами же разработчики не рекомендуют изменять. В общем это немного удобнее. Использовать или нет каждый решает сам. А с пересборкой как вам?
я правильно понимаю что по каждому пердежу называемому запросом со стороны веб-сервера идет распаковка архива и выполнение хранащегося там кода? то есть никакого шареда, никакого кэша опкода, никаких разграничений прав? зато на каждом запросе сталкиваемся с инсталлятором включенным в архив. во-первых его там не должно быть после установки а во-вторых на кой хер он там сдался? я один раз ставлю на ближайший миллиард запросов. нет? поясните в чем суть вашего произведения искусства Добавлено спустя 2 минуты 18 секунд: и все же портальная система в двух файлах. конфиг-то в пархив не собран. значит лежит рядом. а сути существования файла htaccess на продакшн-хосте я не вижу.
Не правильно. В настройках веб сервера можно установить чтобы архив один раз подгружался в оперативную память и сохранил его там до перезагразки. Вся файловая система занимает 7Мб в оперативе и не обращается за файлами вообще. Не знаю установлена эта настройка сразу же при установке или нужно ставить дополнительно. Визуально определить работает файловая система из архива или из файловой системы не возможно. Скорость работы не меняется.
ну вы это, эйчтиаксес тоже в память компилируйте. не дюже если у вас портал одним архивом постоянно дергать такой же постоянный как и архив файл настроек веб-сервера.
Архив уже расположен весь в оперативной памяти. Быстрее чем работа с оперативной памятью я ничего не знаю. Не запаривался особо оптимизацией. Даже в таком варианте работы получается очень не плохо. Если кому-то производительности будет не хватать, сможет еще и с htaccess заморочится.
Повторю при правильной настройки сервера распаковка происходит один раз при загрузке сайт. Все остальное время работа идет из оперативной памяти. Вот сайт работает по такому принципу. http://gektarkoles.ru/ под копирайтом поставил время работы страницы. 0.092167 с. достаточно приемлемое время со всеми запросами и обращениями к файловой системе.
архив требует распаковки. ты либо принимаешь эту идею, и закладываешь большее потребление процессора в свою схему ради экономии файлов и дискового пространства, либо ты экономишь процессор, используя тысячи файлов и кеширование. Мне кажется в твоём случае вполне можно себе позволить использовать фары, но смысла в этом нет вообще.
Улыбнуло. Экономия используя тысячи файлов? Как и кеширование. Любое дополнительное действие не экономит а расходует. А кеширование как таковое вносит кучу дополнительных багов. Но с ними нужно столкнуться чтобы понять о чем я сейчас. Любое кеширование это баланс между производительностью и оперативностью обновления информации.
логично. при правильной настройке сервера и три тысячи файлов тоже идут из оперативной памяти. но работа с файловой системой продолжает иметь место быть. вы мне плюсы-минусы сравните у упакованного сайта и разложенного в две сотни каталогов. итак?
Обновление в тысячи файлах себе представляете? Тут - замена одного файла. По мне так это похоже на инкапсулирование. Все базовые возможности скрыты от посторонних глаз, в то же время всегда возможна замена любого из компонентов системы простым добавлением файлов в файловую систему. Если файлов тысячи, то кто менял и что менял понять практически не возможно как собственно и что обновлять. У меня есть и такие сайты и такие как говорил использую этот способ относительно недавно и нашел в нем больше плюсов чем минусов. Если сравнивать с тем же классовым подходом представьте если методы класса будут размазаны по десятку или сотне файлов. И от наличия каждого будет зависеть работа всей систем. А при добавлении нужно помнить кто и что правит.
ссд? =) система версий, чувак. просто ни у кого кроме тебя похоже не возникает такого бардака на сервере, чтобы это напрягало.
во-во. а еще можно на видеокарте вычисления делать - там просто рвань какая производительность будет =)
Документация к тому же git занимает не одну сотню страниц а правильное ее использование это пару лет практики. Я при том, что знаком с git уже года три не использую его даже процентов на 15 возможностей. Не думаю что все остальные чем то отличаются от меня. Для меня лично использование одного файла со всеми базовыми файлами легче чем использовать git log для поиска измененных файлов а потом решать блоки при мержах. Но опять же каждой проблеме свое решение. Вся система лежит в гите это никто не отменял. Но заливка сайта на хостинг и разработка удобнее с phar. Гит удобен на больших проектах с большим количеством разработчиков.
mpak ну то есть всё сводится к тому что лично ты не понимаешь назначения технологий и не можешь обосновать почему ты отказываешься от использования одних и навязываешь себе использование других. так?
Никому ничего не навязываю. Для себя нашел решение. После использования решение показалось достаточно удобно чтобы о нем узнали другие. Вот и поделился. Если кому то удобнее все еще разбираться в тысячи файлах - продолжайте. Лично я не буду настаивать на том, чтобы вы что то меняли в своей работе. Гитом пользуюсь давно и успешно. Знаю все его преимущества и недостатки.