Как получать response при выполнении запросов через curl, если CURLOPT_RETURNTRANSFER может быть отключен?

Универсальность враг специализации. Нужно понимать как и каким образом будет работать прослойка.
Тем не менее:
1) используйте всегда CURLOPT_RETURNTRANSFER, если файлы большие - пишите в локальный файл.
2) перехватывайте вывод в браузер, не очень хорошо, да обрабатывать буфер нужно на ходу, если файлы большие

Как в Agile решается проблема, когда на последних спринтах приходит требование, ради которого придется все переделывать?

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

Как в Agile решается проблема, когда на последних спринтах приходит требование, ради которого придется все переделывать?

Добавлю только, что agile помогает в этом случае тем, что вы начинаете перестраивать ваше приложение по итогам спринта, когда получили новые требования, а не через год, когда выпустили окончательный продукт, а он уже никому не нужен.

Как выбрать более правильное решение по коду?

Сергей Ерин, а также, можно поразмыслить, почему метод в модели называется getDropDownData (уже какая-то смесь model и view, а вы ее еще хотели усугубить). Почему модель называется Search, если мы в ней ничего не ищем, а берем все скопом, и вообще она занимается пользователями. Что за подозрительный distinct в запросе, неужели id не уникальны? Почему массив с пользователями называется query? Зачем вообще этот foreach, вроде в yii был специальный метод для этих целей.

Почему выдает ошибку bash: npm: command not found?

Mitch Conner, ну т.е. не bash ошибку пишет, а npm, тогда да. Значит автор лукавит насчёт bash.

Как в crontab ubuntu перезапускать сервис?

А зачем его перезапускать? Пусть работает постоянно.

Где ошибка скрипта?

Случайно закинул в ответы, переношу сюда:

Хотел написать, что должны быть более точные требования, чем "нужного и ненужного".
Но увидев использование shuf (даже не знал, что такое есть), понял, что это какая-то шутка.

Roman Bolshukhin,

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

Шутки здесь нет никакой.

Да я уже посмотрел, что это, Но, эээ... вы пишете код с расчетом, что что-то получится случайно? рандомно?

Как дополнить метод в дочернем классе?

FanatPHP, в ООП про наследование забыть не получится, главное помнить, что это должны быть родственные вещи, и этого достаточно.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

Нет там отличия кода, только настройки. Не понимаю чем нам поможет so_reuseport в пробоеме с лимитом файловых дескрипторов.

Взаимосвязанные сайты?

cheburek_ilon, обычная классическая БД, почему 1.1.1 непонятно, все это делается внешними ключами.
У XDCR преимущества, что не столкнетесь с сложностями master-master СУБД репликации, гибко можете настраивать, чем и как обмениваетесь, но все это потребует написания кода. С одной стороны это не так сложно, но и не так просто - если опыта в разработке мало, то не стоит браться за эту задачу, проще будет взять готовое решение вроде master-master СУБД репликации, но там есть свои сложности и достаточно серьезные, почему многие и внедряют XDCR.
XDCR подразумевает обмен данными между ДЦ через приложения по отдельному каналу, например http. Как правило формируется очередь (в базе или в брокере) и на основе ее формируется пакеты обновления для другого ДЦ. Воркеры берут пакеты из очереди и отправляют в другие ДЦ (1 поток - 1 воркер). Пакет - это не обязательно 1 запись в таблицы, если записи в разных таблицах связаны, то их нужно передавать в одном пакете (это не значит, что связанные по внешним ключам нужно передавать в одном пакете, смотрите по ситуации). Если происходит ошибка в обмене, вся очередь для сбойного ДЦ останавливается до момента устранения ошибки (если поделили очередь на независимые потоки, то можно останавливать только сбойный поток).
При 2-3 ДЦ достаточно простой схемы "все обмениваются со всеми". Одним из важных моментов - это разделение транзакций по потокам, чтобы если транзакция обрабатывается на 1ом ДЦ, то все что с ней связано далее, тоже обрабатывалось на 1ом ДЦ (чтобы апдейты одной и той же записи не прилетели на разные ДЦ). У вас это пользователи, которых вы в любом случае будете привязывать к определенному ДЦ. Не нужно их привязывать навсегда, только в рамках текущей сессии.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

вы сперва скажите, чего же вы хотите от пыхи, чтобы она перестала быть идиотской:
1) пыха вместо уже оптимизированного решения дала лишь несколько базовых кирпичиков. За это назвать тупым почти любой язык, ведь мало в каком языке есть готовые средства, например, для работы с .ods или .csv, а не базовые «прочитать из файла N байт / строку».
2) встроенные функции языка обязаны быть оптимальными. Сколько там для Го более оптимальных библиотек для работы с JSON? Считать ли Го идиотским языком, за то, что встроенные средства неидеальны?
3) У вас есть адекватные претензии, но я вас, гения, не понял.

Не называл php ни идиотским, ни тупым языком. Речь шла только про реализацию одной функции в языке. А вы все поделили на черное и белое.

Цитату пожалуйста, где я писал, что виноваты все, кроме пыхи. Я писал, что если писать код без оптимизации, то и работать он будет медленнее оптимизированного кода. Да, такое вот капитанство.

Файлы на каждое соединение создаёт не php, а система, сюрприз, а задачи обкладываться костылями из-за корявостей операционки ради «задачи 10 тысяч соединений» у него пока не было.

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

Ну так докажите, что они не страдают от проблем автора вопроса, но при этом не используют reuse_port. Исходники самого Го в студию.
То, что с reuse_port пыха работает не хуже прочих я уже показал. Да, теми самыми тестами.

Расскажите подробнее, что вы "уже показали" в приведенных тестах, я не понимаю, причем здесь: получение данных из базы, подготовка html и производительность в кол-ве ответов в секунду, когда мы говорим совсем о другом, о кол-ве подключений?
Каким образом so_reuseport решит вопрос с ограничением кол-ва файловых дескрипторов на процесс? Ну сможете вы расшарить этот файл на несколько процессов, но лимит ведь никуда не денется, разве нет? Разумеется workerman это использует, т.к. подразумевает запуск нескольких воркеров, но причем здесь обсуждаемый вопрос?
Если вы знаете решение, то напишите ваш правильный вариант и проверьте как он работает. И если там все ок, то разместите здесь в ответах. Но вместо того, чтобы написать 2 строчки и проверить, вы зачем-то теоретезируете об исходниках Go.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

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

Даже если так, то где здесь вранье?
Оптимизировать код это прекрасно, только вот речь про встроенные функции языка, а не код, неужели вы этого не заметили?

Макось оптимизировала, фряха оптимизировала, Go оптимизировал (при этом дал своё API), линукс не стал, пыха не стала, но виновата у вас только пыха. Вы либо тогда уж и ядро линукса говном назовите, либо с пыхи глупые обвинения снимите

Круто, у всех все нормально, но у вас виноваты они все, а не пыха.
Можно и ядро линукс говном назвать, но речь ведь не об этом. Пыха и линукс мягко говоря разные вещи, и ваша попытка их связать вместе смахивает на демагогию. Еще раз, Go, python, нода тоже ведь на линуксах работают.

И да, она без проблем всё вытащит, если правильно ей об этом сказать (думаю найти отличия действий автора вопроса от авторов сервера вы сами сможете).
Выступит не хуже Go если без тяжёлых вычислений.

Куда и что она вытащит? Сокеты в php при workerman как-то иначе начинают работать и не нуждаются в файловых дескрипторах? К чему эти тесты, когда мы совсем о других вещах говорим?

Это забавно, как вы пытаетесь меня убедить, что нерабочее решение лучше, чем рабочее. Так что там с nginx? Судя по вашим заявлениям, вы наверное используете только Apache prefork и "правильно" его настраиваете? Потому как Apache не виноват, что есть лучшее решение, и нужно мучаться с ним, так?

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr,

Ещё раз, вы либо искренне заблуждаетесь, либо нагло врёте. Функции использованные автором, как и множество других, являются простейшими прослойками над вызовом системных функций и в других языках будет ровно то же самое, если открыть несколько тысяч сокетов и удерживать их. Это механика юниксов в целом.
Отсутствие «таких» проблем в «других языках», а точнее в одном лишь Go, означает лишь то, что он втихую использует один системный сокет для получения данных от нескольких клиентов. Точно так же, как это делает nginx.

Вру в чем? Ну возьмите не Go, а python, и будет тоже самое (но не тоже самое что в php). tcp-сокеты и unix-сокеты вещи разные, если вы привяжете один к другому, это, конечно, весело, но на фиг не нужно для конкретной задачи. И еще раз, можно сколь угодно говорить, что все дураки, а php истинно верный, и развлекаться с проблемами, либо принять, что правильное решение то, которое работает, а не наоборот.
И пример с nginx в этом плане очень хорош - хочется обрабатывать 10 запросов, а не 10 000 - берем Апач с кошерным разделением. Либо берем nginx и работаем с хорошей производительностью. И вот же незадача, Апач принял, что это верное решение и тоже стал так делать.

Увеличить лимит соединений tcp для websocket?

OneTwoThreeFourFive,

После перезагрузки настройки файловых дескрипторов сбрасывались до стандартных 1024

Нужно указывать в настройках, а не один раз сменить.

каким-то образом подключается 1050 и немного больше

все зависит от кол-ва разрешенных файловых дескрипторов на процесс и кол-ва файлов уже используемых вашим скриптом.

Я могу лишь подсказать, что есть такая проблема, сам с ней сталкивался, хотя и давно. Но когда ограничение чуть больше 1000, то это скорее всего оно и есть. Здесь уже 2 человека покапав в этом направлении смогли решить. Когда я с этим сталкивался, вроде бы php писал конкретную ошибку, что не хватает файловых дескрипторов. Нужно смотреть, где конкретно спотыкается, смотрите логи.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, в 3ий раз, проблема только в php, в других языках ее нет. Если подразумеваете, что остальные языки обложились костылями, то нет - создавать файл на каждый коннект, это, конечно, очень похоже на unix way, но всегда нужно исходить из целесообразности. Если вам кажется что вы идете unix путем и при этом отстрелили себе ноги - вероятно вы делаете чтото не так, и не надо пинять на операционку.

Увеличить лимит соединений tcp для websocket?

OneTwoThreeFourFive, там antobra писал, что нужно еще перенастроить sysctl для highload, только увеличения лимита на файловые дескрипторы недостаточно. Это делали?

Увеличить лимит соединений tcp для websocket?

Как раз решали подобную проблему здесь https://qna.habr.com/q/1092856?e=12152650, связанную с "особенностями" php.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

antobra, отлично, спасибо что отписались о решении.
Надо будет посмотреть, как в этом плане работает MacOS.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, а зачем мне документация nginx? Когда как я уже писал, проблема только в php, и поэтому это идиотское решение. Отправьте читать документацию разработчиков других языков, в которых нет подобных проблем. Второе, nginx реализуя http работает мягко говоря совсем иначе, чем постоянные коннекты в сокетах. И если там, каждое соединение - это работа здесь и сейчас, то из 2000 сокетов большинство скорее всего будут простаивать в произвольный момент времени.

Деградация передачи данных через php stream_socket_server и неблокируемый режим?

batyrmastyr, то что в Unix все - это файл, это да. Но совсем не обязательно каждый отдельный коннект прогонять в отдельном файле. Тем более, очевидно, что для сокетов может потребоваться не 100 соединений, а гораздо больше. И в каком-нибудь python или go, это учли и сделали нормальное решение, а в php приходится манипулировать с лимитами файловых дескрипторов. Поэтому я бы не назвал это удачным решением, раз есть решения лучше.
У автора macos, а не Ubuntu.