Kir ---

В принципе php-cgi это не FastCGI. А вы тут в Nginx пытаетесь использовать php-fpm. Если вы там запускаете на 127.0.0.1:9000 именно php-cgi как standaloune сервер, то естественно что оно ложиться. Оно такие нагрузки не держит, оно лишь для быстрого запуска дев-стенда.

Если все же у вас php-fpm, тогда может падать по причине слишком большого объема потребляемой ОЗУ.

Работал с PHP давно, может уже мои знания устарели.

Делаем запрос на специальный URL в которой указан csrf токен, получаем токен для разового коннекта по websocket.
Формируем url для websocket с этим токеном в пути и подключаемся.

Транспйлер это выдуманный термин человеком в википедии. А потом его начали использовать не образованные люди из мира JS

А в чем вопрос то? Ты сам почти все написал и не понятно, что такое "сложение селектов".

+ Замени на нормальный код получения значения из select

var index = parseInt(document.getElementById('table2').value) - 1;
var listQwe = [qwe1, qwe2, qwe3, qwe4];
var value = listQwe[index][0];
sum += value;

Ха ха ха. Нет не можете свой. Только те что поддерживают браузер.

UPD
Станислав Почепко, это все очень сложно, но можете почитать кучу статей по настройке push api, например https://medium.com/web-standards/реализуем-пуш-уве... где вы наткнетесь на понятие VAPID Key.

VAPID Key - это ключ, где зашифрована информация о вашем сервисе доставки сообщений.
И многие рекомендуют использовать https://firebase.google.com/docs/cloud-messaging/ (либо можно использовать Amazon SNS https://aws.amazon.com/ru/sns/faqs/)
А уж этот сервис сам пойдет во все точки отправки сообщений для каждого устройства и отправит ваше сообщение.
Ведь каждое конечное устройство или браузер жестко подписан на эти самые точки получения push уведомлений.

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

Если в папке нет __init__.py то это не пакет.
Грубо говоря, __init__.py нужен для того что бы можно было загружать именно пакет и модель работы пакетов функционировала.

import package1
from package1.sub_package1 import *

Вы уже джуниор. Вам до мидла нужно расти. Джуниор язык знают весьма посредственно

Может потому что у вас справа блок в виде списка фотоальбома домов и сверху список "статей", а на самом деле это ссылки на рекламные сайты?
За такое нужно руки отрывать. И правильно что понизили вас в выдаче.

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

Для того что бы начать разрабатывать архитектуру, нужно сначала понять что это и понимать(а не знать) определение. 99% программистов не знают этого и пытаются из себя строить архитекторов.
ГОСТ Р 57100-2016 оно же https://en.wikipedia.org/wiki/ISO/IEC_42010
В Яндексе ищется просто. Почитайте и осмыслите.

После этого поймите SOLID. Это будет трудно и тяжело, особенно в свете того, что половина статей от людей, которые сами SOLID не понимают.
Почти у каждого принципа SOLID есть четкий критерий, осванный на свойствах кода, а не на предположениях программиста о области применения.
Например принцип единой ответственности говорит о том, что у каждого класса состояние описывается набором свойств, которые всегда изменяются вместе. Если они могут быть изменены по отдельности, то это две разные ответственности.
Но свойство не является частью состоянием, если не используется в методах класса для вычислений или в выражениях. А например, просто всегда возвращаются.

Не Ruby. Он мёртв.

Вот смотрю на горе советчиков и понимаю, что они сами далеко не ушли. Начинать изучать ООП нужно с ответов на вопросы:
Для чего его придумали?
Какие цели преследует и какие задачи решает?
Какие инструменты есть для решения этих задач?

Все остальное следствие. Как придёт понимание, вы поймёте в какую сторону копать. А то вам тут насоветовали паттернов. И их глупое изучение благополучно убьёт кучу вашего времени почти без толку.

Все что выше написали булщит.
Глубокое понимание JS, это умение написать функции наследования через прототипы не по памяти, а потому что понимаешь как это делается.
+ Теперь ещё понимание символов.

Если хочется уйти на бесплатное решение, то просто берите PostgreSQL.
У NoSQL решений с доступностью проблема. У некоторых с актуальностью. В MongoDB, например, при успешной транзакции вы будете некоторое время получать старые данные.
А если укажете флаг, что вам такое поведение не нужно, то будут проблемы с доступностью на чтение.

При чём тут php не понятно, но ошибка где то в скрипте, который говорит что у переменной пытаются посмотреть поле с именем "php". А эта переменная имеет значение undefined (т.е. не определено значение)

Потому что браузер на сайт2 не передаются cookie от сайт1.
Иначе это было бы катастрофой безопасности.

Кросс-доменная авторизация делается через стороннний сервис авторизации. Либо через авторизацию на домене верхнего уровня.
Например сайт2.домен.рф и сайт1.домен.рф авторизуются через домен.рф, который делает редирект на нужный сайт

Сейчас напишу немного высокомерно, но опыт позволяет. Уже почти 20 лет в разработке и около 15 в веб.
Надо понимать, что почти все кто используют многочисленные Фреймворки не понимают что такое ООП. А уж тем более, что такое SOLID и т.д.
И поэтому, что бы они не писали, в конце-концов превращается в какашку с костылями.
Да, потом героически проект переписывается с учётом изменений (или ещё чаще умирает) Но, он по прежнему остаётся абсолютно не расширяемым и не поддерживаемым.

И вот мы возвращаемся к Фреймворкам.
Нужно брать тот Фреймворк, который писали с учётом определённых парадигм и принципов. Так как этих вот парадигм, достаточно описанных и изученных не так много (на самом деле их 2.5 штуки), то можно сразу ориентироваться на ООП + MVC(или MVP или MVVM) + SOLID
Если Фреймворк что-то из этого нарушает, то он по умолчанию не может вам дать возможность написать хорошее, расширяемое приложение. А хороший Фреймворк, даже начинающим программистам должен прививать правильные подходы к разработке. Что-бы хочешь, не хочешь, а hello world уже не превращался в ад.

Сразу оговорюсь, что я давно "забил" на Фреймворки. Есть один идеальный — это Pyramid. А оцениваю любой продукт по документации. Там сразу видны все огрехи и косяки. Буду писать и параллельно смотреть в доки.

Larvel
Первое что я вижу в этом Фреймворке, что большая часть работы каркасных компонентов завязана на статических вызовах. На этом можно уже, даже и остановиться. ООП, по большому счёту тут нет. Суть ООП в использовании объектов. Тут же класс выступает в качестве пространства имён функций.
Раз нет ООП, то и нет всей теории и принципов связанных с ним.
А раз под этим Фреймворком не заложено никакой теории, то в 99% случаев можно сказать, что на нём что-то правильно, написать невозможно.

Если взглянуть глубже, то открывается ещё больше ада:
ActiveRecord.
Плох по умолчанию. С ним очень тяжело контроллировать целостность данных. Вам нужно придумать слой абстракции, где вы будете транзакционно записывать все данные вне бизнес логики. Фреймворк вам тут не поможет. Он предложит это делать в экшене (контроллере). И тут вы столкнётесь, что при написании чего-то сложнее чем бложик, вы будете терять целостность. Ибо бизнес логика и работа БД будет в одном методе. Отладка будет усложняться, ошибок плодиться и т.д.
И не зависит это от программистов. Шаблон сам по себе провоцирует ошибаться.
Далеко за примерами ходить не нужно, уже треш.

Чем больше примеров я смотрю, тем больше не понимаю, как все это дело расширять. Как вставлять прозрачно через весь проект свои собственные аспекстные решения. Например RBAC. Или, если нужно, логику работы приложения отделить от БД и когда нужно, подставлять необходимую реализацию.
Или сделать работу всех экшенов в рамках клиента, но производить авторизацию по пользователю(сотруднику)

Все это предлагается зашивать прям в контроллерах, с помощью protected или private методов.
Повеситься. Сложность приложения зашкалит.

Symfony
Только при выходе 2 версии я работал с этим чудом. Разработчики писали его под хапйом dependency injection. Мало того, что они взяли не самую хорошую стратегию для реализации всего костяка фреймворка, так ещё и сделали её не правильно.
Они написали универсальный DI Container и кладут в него все что угодно, используя в качестве идентификатора строчку.
Строчку, М**Ь ЕЁ! Не интерфейс — строчку!
И знаете чем это аукнется? А тем, что при разработке своего приложения или очередного бандла, вам будет говорить, что в контейнере лежит что-то не то и вы подохните в конфигурационных настройках. А все потому что, подход: ВСЁ через DIC — строго навязывается.
Расширение этого чуда, тоже причинит вам массу головной боли. Ведь, зачастую, вы будете работать с классами, которые ждут не интерфейс, а что-то из контейнера с ключём "я_твой_дом_шатал".

Проблема с внедрением аспектов сквозь весь фреймворк, никуда не пропадает. Но тут по другой причине. Сложность платформенных компонентов зашкаливает. Все пишется с завязкой на конкретную реализацию, но получают все по строчке из DIC.
Потому что это центральная концепция. Другой нет.

Но, по правде говоря, слепить что-то годное возможность есть.
Если взять микро ядро symfony, прикрутить Doctrine, то получится что-то годное.
Но встаёт вопрос. А зачем вообще symfony, если можно взять doctrine и написать все остальное свое?
И тут вы окажетесь правы — незачем.

Ситуация с Symfony в enterprise очень схожа с ситуацией с Django. Повидал уже с десяток проектов, где последнюю брали для больших приложений. В итоге от Django оставались рожки да ножки. Всю её переписывали.
Спрашивается — и зачем? Просто потратили кучу времени.

Так что, если нужен суровый enterprise. Что бы писать что-то большое, с возможностью расширения — берите Pyramid и переходите на python.
Ничего, даже близко с пирамидкой, по возможностью расширения, даже близко не лежало.