Сергей Протько

Ну начнем с того что вариант с репликами и виртуалками это откровенный бред и пустая трата ресурсов, ладно бы шардили, тогда можно было бы при правильном подходе распаралелить map-reduce (в теории). Да и виртуалки не нужны, можно же просто на разных портах несколько инстансов поднять.

А вообще тема довольно изъезженная. В частности CPU грузить банально нечем, все упирается в IO.

https://groups.google.com/forum/#!topic/mongodb-us...

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

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

$taskManager = new TaskManager(); // вынести инстанцирование во вне а еще лучше использовать DI
// таск есть таск, имеет он при себе родителя или нет
// по сути у нас обычное дерево
$parentTask = new Task();
$subTask = new Task($parentTask);
$subSubTask = new Task($subTask);
// вся логика по сохранию тасков инкапсулируется в менеджер тасков
$taskManager->addTask($parentTask);
$taskManager->addTask($subTask);
$taskManager->addTask($subSubTask);

Если используете Doctrine в качестве ORM, то в менеджере вы должны делать только persist записи. flush в идеале должен быть только один (коммит транзакции), и желательно его делать в каком-нибудь так же даже не в контроллере, а сделать глобальный обработчик, мол если у нас не возникло ошибок во время обработки http запроса - делаем flush. Таким образом мы никогда не забудим закоммитить изменения в базу.

заменяет '\x' на '%'.... внезапно. Причем тольо первый встреченный символ.

ну начнем с того что лучше так вообще не делать, геттеры/сеттеры так же надо либо выносить в прототип либо использовать defineGetter/setter.

А не работает потому что у вас внутри геттеров и сеттеров не тот контекст. То есть вы должны либо использовать у замыкания метод bind и привязать их к вашему объекту, либо указывать ссылку на this в конструкторе (не очень хорошо).

Пройдемся по пунктам:
1) WebSockets
2) Все что касается авторизации не относится конкретно к задаче чатика. Можно конечно замарачиваться, и выносить функционал авторизации в отдельный демон или поток и общаться через Pub/Sub (например ZeroMQ). По сути главное что бы во время верификации пользователя мы могли обрабатывать другие соединения
3) Если вы хотите p2p доставку сообщений с WebRTC, то сервер вам нужен будет только для авторизации и аунтефикации клиентов, ну и что бы клиенты могли найти собеседников. В этом плане серверная часть упрощается и снижаются требования по нагрузкам, но усложняется клиентская часть.
4) К сожалению вы не можете отправлять бродкастом сообщения, так как используется TCP. Можно конечно организовать что-то типа очереди, но я не вижу причин для выйгрыша в производительности. Тут больше вопрос архитектуры и каким образом вы синхронизируете списки пользователей.
5) Ну... тут не вижу проблемы. Если вы хотите иметь один сервер для всех виджетов, то просто добавить поддержку CORS и токены для запросов (в заголовках) что бы разграничивать по доменам.
6) А что именно вам надо хранить в базе? Сообщения у вас на сервере, как вы сказали, не хранятся... Пользователи - любой вариант, тот же MySQL (а лучше PostgreSQL, для которого есть возможность использовать асинхронные запросы в базу, что бы было интереснее). Текущих пользователей и прочее можно хранить в Reddis и т.д. Главное что бы хранилище было быстрым.

Вообще задумка интересная, вариантов реализации масса. Это можно спокойно и на PHP написать, есть ReactPHP + Ratchet для организации сети пользователей, а для доставки сообщений вы и так хотите использовать WebRTC. Просто на сервере в супервизор надо поставить парочку демонов (по одному на ядро) и сверху поставить nginx, который будет балансировщиком и проксей. Учитывая что вы нехило можете за счет WebRTC и каких-нибудь архитектурных трюков уменьшить итоговую нагрузку на сервер, проблем с производительностью быть не должно. Так же для ReactPHP было бы неплохо поставить libev/libeven, словом там по документации можно пройтись и почитать что да как.

Update:
отстал я от жизни, как раз таки UDP можно использовать в браузерах (во всяком случае в последних билдах хрома), в частности для передачи информации между браузерами (а не аудио и видио) можно использовать datachannels. Так что тут все упирается в то, как доставлять сообщения между клиентами. Остальное уже зависит от того, как вы все же решите все делать.

Да, для владения jQuery еще стоит знать замыкания и скоупы (каррирование например запилить), event bubbling и как вообще работают ивенты в JS и что можно с ними делать, естественно основные штуки типа циклы/условия, желательно иметь представление о массивах и уметь с ними работать, понимать разницу между массивом и хэш объектом, основные типы и т.д. Так же стоит посмотреть на понимание работы с асинхронным кодом (колбэки, промисы).