Александр Мелеховец

Что делать?

Сменить обслуживающего администратора/программиста.

Все зависит от контекста высказывания (задачи разные бывают). Бросаться в крайности это глупо (только ситхи все возводят в абсолют (с) Оби)

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

p.s. уточните о чем был проект или скиньте ссылку, любопытно посмотреть на безумца или понять его хотя бы.

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

Есть Ассемблер.
Но если он есть, на нем все возможно, и в добавок он соображает быстрее того же C++, то почему еще существуют другие решения в мире софтовой разработки?

Традиции, привычки и необходимость поддерживать существующие проекты не в счет. Мне интересно, почему новые проекты пишутся не всегда на ассемблере?

Раз, Два, Три ... Пятьсот...

Вы в гугл заходили?

Тут не в настройках, а в коде запросов скорее всего проблема. Профилировать нужно и смотреть что к чему.
Можно взять Blackfire как достаточно продвинутый.

Выше правильно заметили, что нужно больше практиковаться. Так теория не будет лежать сухим грузом, а будет лучше запоминаться ассоциируясь с уже выполненными задачами. Попробуйте совместить книги с несложными задачками из какого-либо онлайн курса, благо их сейчас довольно много. Например Сodecademy или Сodeschool

Делегирование - это шаблон проектирования, и реализовать его можно на большинстве современных языков программирования. Пример для Python есть в вики, никаких дополнительных ключевых слов для реализации делегатов в питоне не требуется, т.к. любой метод можно передать в качестве параметра куда угодно. Так же можно помещать методы в структуры данных, вот пример:

def say_hello(name):
    print 'Hello,', name

def say_goodbye(name):
    print 'Bye,', name

phrases = {
    'hello': say_hello,
    'bye': say_goodbye,
}

def say(what, name):
    phrases[what](name)

say('hello', 'Ivan')
say('bye', 'Oleg')

В Go этот паттерн реализуется тоже очень лаконично.

У вас намешан php код и html.

<?php while ($row = mysql_fetch_assoc($result)): ?>
    <h1><?= $row['title'] ?></h1>
    <p><?= $row['text'] ?><p>
    <p>Дата публикации: <?= $row['date'] ?></p><p><?= $row['time'] ?></p>
    <p>Автор: <?= $row['author'] ?>
<?php endwhile ?>

я сам знаю то что ошибка в чем

В золотой фонд.

Но аналогичный запрос UPDATE выполняется недопустимо долго (286.0228 сек.)
UPDATE `test` SET `lock` = 123456 WHERE `lock` = 0 ORDER BY `time` LIMIT 1000

Может быть потому что по lock есть индекс и это время получается из-за его перестроения?

Пусть выбирает ваш системный администратор тот дистрибутив который ему удобней.
Вам, как ничего не понимающему, должно быть пофигу.

Если не доверяете програмисту - делайте сайт сами.
Если у него есть какие-то хитрожопые мысли - он в любом случае сможет навредить.

Давать рут доступ опредленно нужно, либо сами будете ставить и настраивать весь софт.

Общее для всех mysql:
Проверить какой запрос отрабатывает система если replace то плохо если update или insert on duplicate key update - то ок.
Если в action_history есть индексы кроме примари кей то их скорее всего стоит убрать т.к. вероятно запросы ( сортировки или агрегации) по этим полям будут приводить в любом случае к фулскану и индекс не будет иметь смысла, а при апдейте перестройка будет постоянно всё класть.

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

В общем и целом, поразмышлять что INSERT DELAYED VALUES (1,2,3),(..,..,..),(N,N,N) для записи всех действий будет работать заметно веселее особенно без индексов и в одном потоке, а после некоторых шаманств с агрегацией по крону ещё не будет деградировать от распухания. Что можно про крону парсить access.log (понимать что он не рилтайм), в этом случае будет одна пачка апдейтов допустим раз в минуту и user_id будет заапдейчен только один раз, это будет пожалуй самой простой реализацией задачи упорядочивания и фильтрации потока апдейтов к mysql. Парсинг лога можно заменить на RabbitMQ, или написать своего демона который будет висеть на соке и рулить.

Но смотрите если у вас задача в стиле показать последние 10 пользователей сделавших, что то, то это решается сильно иначе.