Алексей Сундуков

Очень похоже, что сработал супервизор Erlang/OTP. См.: http://www.erlang.org/doc/design_principles/sup_princ.html (что очевидно, как мне кажется).
Вопрос в том, почему он сработал. Могу предположить, что память закончилась или попортилась.
Crash-дампы не сохранились? (они обычно в пишутся в директорию, куда ведутся логи).
Вообще, конечно, мало информации: erlang.log надо смотреть полностью + ejabberd.log за несколько минут до того, как началось отключение клиентов.

99% времени уйдёт на скачивание контента (5000000 страниц это не хухры мухры). Тут хоть на бейсике писать можно. Ну, конечно, C++ будет быстрее, но в абсолютных величинах, по итогам выполнения этой задачи, это вряд ли будет заметно.

не нужно писать http или https http://www.paulirish.com/2010/the-protocol-relative-url/

Если так важна многопоточность, то почему был выбран PHP? Я так понимаю, что блокирование хоста зависит от настроек веб-сервера и вы просто занимаете все выделенные child-процессы. Может помочь увеличение их количества.

На хабре таких вопросов не было...

Ни чем это не грозит. Как правило в приложении используются фреймворк или библиотеки, которые предоставляют безопасный доступ к суперглобальным массивам — фильтруют/экранируют/приводят данные к нужному типу. Если вы этим не пользуетесь, то обращайтесь к входящим данным самостоятельно, но никогда не доверяйте им.

Думаю, Netbeans начал ругаться не "внезапно", а после того, как вы что-то изменили в настройках.

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

Я бы взял джуниора, если бы он взял на себя рутинные операции и делал их качественно (то есть, нужны внимательность и усидчивость). Взамен я бы учил его тому, что знаю, отвечал бы на вопросы и давал задачи на развитие.
То есть, мы занимаемся вместе 2 часа, а потом джуниор самостоятельно копытит ещё 4 часа (или 24, пока не сделает). В результате у меня экономия времени, у джуниора экспа.
Но это если джуниор будет делать всё как положено. Если начнутся «не хочу / не буду / да ладно, и так сойдёт», если придётся за ним переделывать — в сад.

Использую в зависимости от ситуации, когда работа с одним объектом ORM, удобно и наглядно. Сложные запросы или запросы ORM съедающие много оперативной памяти или иных ресурсов в чистом виде.

Сферический вопрос в вакууме, причём без возможности уточнения, поскольку «проект был».
«медленные запросы» — насколько медленные?
«сайт с посещаемостью» — с какой посещаемостью?
«потому что запросы на поиск» — так может, это поиск вынести отдельно на Сфинкс?

То есть, выяснить, что там — кривая настройка сервера mysql, кивые таблицы или кривые запросы — не представляется возможным.
Но вопрос, как всегда, формируется в самом общем виде — «где тот волшебный гвоздь, по которому 1 раз ударить — и всё сразу залетает?»

Ну ок. В самом общем виде оптимизация запросов (неважно — частых или нечастых) заключается в оптимизации запросов.
Оптимизированный запрос выполняется (допустим) 0.001 секунды. То есть, БД может обслужить 60 тысяч одновременно сидящих пользователей.

Берем EXPLAIN и смотрим. Если он говорит, что с запросом все окей, просматриваем ровно столько записей, сколько нужно — 5-10, но все равно запрос исполняется медленно (насколько конкретно медленно — в секундах?) то смотрим, SHOW ENGINE [engine] STATUS. Там уже надо опять же смотреть по месту, решать, чего серверу не хватает.

После того, как мы убедились, что все меры по оптимизации SQL приняты, то только тогда занимаемся кэшированием, заменой полл на пуш и т.д.

То есть, действуем как программист — а именно, разбираемся с конкретной проблемой, и ищем решение конкретно для неё.
А не придумываем от балды заплатку для лечения симптома, оставляя болезнь развиваться и дальше.

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

Если индикатор новых событий общий для всех пользователей (например какой-нибудь глобальный feed на сайте), то разумным будет кэшировать результат в памяти используя memcached или redis.

Давайте по порядку.
У вас есть посещаемый ресурс, где пользователям должны в режиме реального времени приходить уведомления о чем-то. Ну мол например о непрочитанных сообщениях. Для этого я так понимаю вы ежеминутно опрашиваете сервер, и оттуда и появляются кучи одинаковых запросов. Поидее если mySQL настроен нормально, то все эти запросы он будет пытаться кешировать сам. У вас точно есть проблемы с производительностью БД в этом ключе?

С другой стороны, самый оптимальный способ решить эту задачу: WebSockets/long pooling. Реализовать простенький сервер на каком node.js + scocket.io. Как шину данных поставить какой rabbitmq или чего подобное. В случае сообщений, при отправлении сообщения другому пользователю, в очередь отправляется сообщение. Оно принимается push-сервером и, если у нас есть соединение с нужным пользователем, отправляем ему уведомление. При таком подходе мы имеем: данные уходят с минимальными задержками. Уменьшается нагрузка на сервер за счет уменьшения количества запросов (push сервер просто держит соединение и работает только с небольшим количеством за раз). Ну и последнее — масштабируемость за счет rabbitmq: из основного приложения всего лишь отправляются в очередь небольшие сообщения. А то как оно паралелит сообщения и их обработка вынесены в rabbitmq. Меньшая связанность систем. Да и готовых реализации хватает.

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

Любой SAX парсер подойдет.

Ищите по запросу SAX-парсер. На ум приходит Xerces, expat, но много всяких.

1. Почему в постсоветском айти прижились в основном рекрутёры, а hr фактически нет. Разослали предложение, взяли человека и забыли о нём, пока он не приходит с заявлением на увольнение. Никаких проработанных постоянных мероприятий по удержанию, адаптации, развитии специлиста у большинства компаний нет.
2. Когда начнут нормально оформлять предложение о работе, а не писать про печеньки. Не ужели так сложно прикрепить документ на 2-3 листа с подробным описанием вакансии, описанием компании, проекта, контактные данные, схему попадания в офис для собеседования и главное — примерную ЗАРПЛАТУ. Мне в месяц приходят десятки вакансий, но все оформлены в виде короткого текста в абзац, ясное дело, что их приходится игнорировать, так как оценить и сравнить невозможно.

Нет, сначало нужно написать какую-то херню, намекнуть, что php-г.но и php'шники талпайопы, а потом рассказывать, что «я не хотел никого оскорбить», «я здесь вообще не о php»…

В очередной раз вижу здесь фразы «при изучении Node.js не приходится изучать заодно новый язык», «заниматься лучше чем-то одним».
Да какого чёрта? Изучать нужно всё, и питон, и руби, и ноду, и китайский язык для кучи. Просто чтобы понимать, что те парадигмы, которые используете не являются единственными возможными.
Даже если после этого на PHP останетесь, то окажется, что на нём начали писать намного лучше.
Я, например, после знакомства с ООП-языками стал на Си на порядок лучше писать, хотя там, казалось бы, никаких синтаксических конструкций для этого нет.
А когда разберётесь сами, тогда и сможете выбать на чём специализироваться. Намного лучше, чем это вам поможет этот тред.

Ничего нового не скажу, но почему бы просто не взглянуть на примеры на RoR и Django и выбрать то что больше нравится?

C++14 имеет достаточно фич, что бы забыть о C++

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