Pull to refresh
0
0
Send message

А Вас не смущает, что сам фреймворк это, по сути, иерархия модулей и Ваша реализация всего лишь попытка объединить два базовых модуля? На мой взгляд это не велосипед, а введение в заблуждение новичков. Для сквозной доступности реализуйте модели в common/models/ для шаблонов используйте темы.


Чтобы добавить ещё один сайт без чуда на свитчах достаточно сделать копию одного из базовых модулей с переименованием директории, например frontend -> api и добавить в файл common/config/bootstrap.php строчку:


Yii::setAlias('@api', dirname(dirname(__DIR__)) . '/api');

Так же сделать копию environments/frontend/ -> environments/api/ и во всех файлах environments/api/ заменить frontend на api. В файле environments/index.php в массиве сделать копию узлов frontend в Production и Development для api. Далее в корне проекта запускаете файл php ./init.php и не нужно никаких велосипедов. Причём это никак не усложняет всю логику и добавлять Вы можете сколько угодно базовых модулей (сайтов).


Хотите чтобы была единая директория для upload? Добавьте алиасы в common/config/bootstrap.php:


Yii::setAlias('@uploads', dirname(dirname(__DIR__)) . '/uploads');
Yii::setAlias('@webUploads', '/uploads');

И используйте его при обращении к файлам
Просто нужно изучать инструменты с которыми работаешь, а не сочинять "кривого монстра" на пустом месте

Время в основном уходит на работу с БД.
В общем я переписал на работу через __call. Во времени выигрыш не большой, т.е. сейчас импорт занимает 7 часов ± 15 минут. (до "трамплина" уходило 8 часов ± 15 минут) 12% неплохо смотрится, но всё-равно маловато. Так что переписываю на XmlReader. Даже если время импорта останется в тех же пределах, хотя бы на оперативке выиграю. На текущий момент SimpleXML при загрузке файла съедает 3 Гб.

не случайно не на винде
Да, это ещё одно слабое звено, работа с БД не такая быстрая как хотелось бы. Но это уже головная боль админа. Мне нужно выжать максимум из PHP
В этом файле все данные нужные. И Вы забываете о неограниченной вложенности и уйму всевозможных условий. Прежде чем осуждать чужое решение, не зная ТЗ, подумайте дважды.
На PHP7 уже перешёл, а вот с рекурсивными __call… Пока слабо представляю как это реализовать у себя
Читаю с помощью SimpleXML. Файл размером порядка 300+ Мб.

В данном контексте статьи, для меня достаточно познавательно было, как же мне ускорить импорт данных из XML.
У меня реализован универсальный класс импорта данных с рекурсивным вызовом метода, который разбирает XML блоки не ограниченной вложенности. На текущий момент, импорт самого большого файла занимает порядка 18 часов. Если применить реализацию разворачивания рекурсии из статьи, то время импорта существенно сократится. По крайней мере я на это очень надеюсь, так как все возможные оптимизации были реализованы (до оптимизации время импорта достигало 32-х часов)
У меня было реализовано так, по некому группирующему параметру из источника данных создавалась задача, в отдельной таблице. Далее, при чтении из источника, полученная строка сразу же удалялась. Одновременно может работать любое количество потоков без пересечения. Я делал это на Redis, там своя специфика работы на сокетах и как такового persistent connection просто не существует. В MySQL таких проблем нет.
Если не удалять записи, а устанавливать некий параметр, аля bot_id, то всё равно нужно как-то чистить обработанные записи, чтобы не перегружать таблицу.
Скажем так, у меня была такая задача, реализована на PCNTL, суть заключалась в том, что регулярно поступает достаточно большой набор ссылок на картинки для каталога товаров из импорта и требуется произвести конвертацию в формат сайта. Деление на задачи производится по домену и у каждого запускается свой пул потоков в соответствии с настройками. В рамках нагрузки на систему, каждый поток незначительный, но требуется обработать максимум в кратчайшие сроки. На мой взгляд дешевле и быстрее такое сделать на PHP, чем на Си.

Если использовать расширение pthreads + PCNTL, то можно сократить количество процессов и выиграть в производительности

Information

Rating
Does not participate
Registered
Activity