SalatProduction: у вас в access log-е все запросы. Вы можете по ним посмотреть сколько запросов непосдерственно к динамической части. То что я вижу - обычные запросы на статику.
error mysql.sock связан с большим количеством подключений непосредственно к базе. Может persistent connection не используется у вас в коде и сервер установил жесткие лимиты... хз...
Grag: идеализированная картина SPA - есть приложение клиент, собственно SPA. Все партиалы и прочее - это шаблны самого SPA. Никакого отношения к Yii и вообще реализации сервера не имеет. Сервер предоставляет REST api сервис который отдает ДАННЫЕ в формате json/xml которые уже приложенька рендрит.
Дальнейшие выкрутасы с отдачей пререндренного контента и т.д. нужны только для оптимизации и просто так это делать не стоит.
fomistoklus: нет конечно, но вопрос то был о соединениях/подключениях.
SalatProduction: это не точный ответ. У вас при загрузке страницы должны загрузиться все ресурсы с этой страницы. Бразуер делает это паралельно, то есть у вас на одну страницу генерится куча запросов. keep-alive позволяет реюзать одно соединение в рамках сессии. То есть на каждый HTTP запрос не устанавливается новое TCP соединение (оно же подключение).
Мне кажется вам просто нужно забить или сменить apache на что-то получше - например nginx.
Когда гость авторизуется с неправильными данными - 422.
Когда нет нужного csrf/api токена при запросе - 422.
Когда в теле запроса невалидный json/xml (то есть распарсить нельзя) - 400
umbertone: у вас две очереди, а не два воркера по сути. resque не справится если у вас воркер на другом сервере. Хотя думаю и тут можно выкрутиться, но если воркеры на нескольких серверах (например для конвертации видио) - то тут уже стоит смотреть в сторону rabbitqm и ему подобных которые гарантируют доставку, надежны и имеют массу вариантов обслуживания и доставки сообщений.
Если у вас сложная логика меседжей, нужна возможность запускать таски по рассписанию, с повторениями и т.д. - то тут лучше взять gearman какой или activemq. Если нужен простой и быстрый pub/sub или очень эффективная шина данных (например между основным приложением и чатиком) - имеет смысл смотреть на zeromq.
Suntechnic: я не считаю что ивент на каждый чих это так уж хорошо. Можно обойтись намного более предсказуемыми штуками. Воутеры, декораторы и т.д. По поводу beforeMethod/afterMethod - попахивает хуками вордпрессов и друпалов. Только декораторы/композиция. Только хардкор. Никаких хуков. Нужно подменить реализацию - создаем декоратор. если хотим - обращаемся к оригинальной функциональности. Нет - оверрайдим ее как хотим. И да, это все можно компилить и кешировать.
У меня в голове пока вертелось две безумные идеи. Для начала хочу отметить что я не хотел бы видеть очередную универсальную CMS которая стремится за счет расширений решить проблемы всех и каждого. В поисках простенькой CMS для маркетологов, что бы те могли ваять себе странички и лэндинги с A/B тестированием более мение вменяемые варианты либо были ужасны внутри либо медленны (приходится прикручивать варниши всякие на продакшен что не каждый себе позволить может да и на стэйджинге и в админке всеравно все не сильно быстро). Не хватало чего-то такого же милого как piecrust/scuplin и т.д. но дружелюбного для маркетологов.
Первая идея довольно банальна. sir-trevor (или все больше скланяюсь к написанию своего редактора взяв за основу например makona-editor который по своей философии самое оно но безможно глючит и не поддерживается) и конструктор страничек. Только маркдаун, файлики и т.д. Разработчик жестко ограничивает контент менеджера определенным набором блоков. Никаких колонк и лэйаутов - если есть специфичные элементы такие - луше сделать блок конфигурабельный (картинка + текст с боку например) чем давать власть народу.
Вторая идея - генерация CMS на основе шаблонов. То есть вывернуть процесс разработки сайтиков наизнанку. Пишем шаблон страницы, какие-то мета-данные или конфигурацию (на базе twig-а делается очень легко) и генерируем структуру данных под эти шаблоны, контроллеры и прочее. Все генерируется. Все оптимизированно под текущее представление. Возможность генерировать миграции (diff) и.д. Никакиз 100500 запросов в базу для статической страницы (привет вордпресс). Но у меня правда нет таких задач потому решил не тратить время на вылизывание концепции. У нее есть свои проблемы кроме того что это банально сложно. Хотя может и не сильно сложно...
Дмитрий Энтелис: мне очень нравится идея деплоймента с docker. Это удобно, не нужно париться на счет окружения, даунтайма почти нет (как переключение симлинков только переключаем мы хосты, то есть просто все новые запросы пойдут уже на новый контейнер). Так как это LXC то оверхэд минимален, база данных в отдельном контейнере и шарится между контейнерами приложенек... И с откатом все просто - просто переключаемся на предыдущий контейнер. И провиженинг на CI сервере мгновенный.
Дмитрий Энтелис: ну как бы да, при деплоее через git придется коммитить вендоры. Не суть собственно. Просто рекомендованный подход их в игнор ложить. У меня на старых проектах вендоры закомичены только по одной простой причине, когда вся эта канитель с composer только начиналась люди массово любили удалять/переименовывать пакеты.
А как после git fetch миграции накатить? Я может чего не знаю, поделитесь. При git fetch до мерджа/ребейза у нас же нету новых миграций. нет? Можете раскрыть это по подробнее?
и да, CI никакого отношения к деплою не имеет. Ну мол... CI это CI, он таски выполняет. У вас может быть таск деплоймента, но какое это имеет отношение непосредственно к загрузке билда на сервер?
Леонид Корсаков: да, это происходит на этапе сборки приложения, как и прогон тестов. Результат этого дела - билд. Но сделать git pull на серваке уже не выйдет. В итоге нам нужен еще один таск в CI сервере который запускает капифони всякие или чего еще там вы можете использовать и заливает архив на сервак и запускает миграции и т.д. У меня вот дистрибьюция проекта идет в deb архивчиках с пост-инстал скриптами который ставится через ansible с предварительным провиженингом сервера. Но правда откат на предыдущую версию я пока не предусматриваю к сожалению.
cybervito21: D не быстрее C, он чуть медленнее. Так же зависит от кривизны рук, можно за счет GC наломать дров. Но в целом есть кучи вещей особенно в плане работы со строками и массивами которые в D будут работать быстрее только изза того что нет лишних перевыделений памяти. Но это не значит что на Си написать так же не получится.
Словом... зависит от реализации.
Меня тоже расстраивает что D не популярен. Пролема в том что за ним не стоят гиганты вроде гугла или мозилы. Только последние пару лет фэйсбук начал спонсировать разработку.
