Если уж зашла речь про модули и Backbone — то лучше сразу вслед за Backbone смотреть Bacbone.Marionette — это надстройка над Backbone, которая дает в том числе модульность. Т.е. то, о чем написано в статье, только из коробки и с кучей прочих плюшек.
Есть ссылки на эти самые инструменты, которые позволяют «фильтровать» часть запросов в зависимости от нагрузки? Как эти инструменты вообще понимают насколько нагружен бэкэнд? Было бы интересно почитать.
Вы наверное никогда не были в ситуации, когда нагрузка резко возрастает. Понятно, что можно подготовиться, поставить железо, балансеры, расширить каналы и т.д. Но это подготовка. Иногда бывает так, что есть приложение и на него именно сейчас идет в 10 раз больше пользователей, чем обычно. В этом случае могут «помочь» подобные решения — это легко прикрутить уже под нагрузкой. Понятно, что большинство пользователей все равно увидит ошибку, но не все. Обслуживать 20% запросов гораздо лучше, чем обслуживать 0%.
Я не совсем понял, как все-таки работает toobusy(). Все ясно с callstack — замеряется раз в 500 мс. На основе этих данных можно при всех вызовах toobusy возвращать true. Но тогда получается, что в этом случае очередь может за 500мс рассосаться и при этом продолжить всем отвечать ошибкой. Далее предположим нагрузка есть, сделан новый замер длины очереди. Очередь пустая (но нагрузка до сих пор большая, просто всем отвечаем 503). Функция toobusy начинает всем отвечать false. И отвечает так в течение 500мс. В течение этого времени запросы начинают обрабатываться и все равно сервер ложится…
Я к тому, что по идее надо делать какое-то распределение ответов между замерами. Например, под нагрузкой отвечать toobusy() = false каждому десятому. Но как это сделать?
Пока нам удалось увидеть загрузку в опере при проигрывании трека. Есть загрузка процессора при переходах / движениях мышью, но это нормально т.к. срабатывают различные события и рендерятся элементы. Если в браузере ничего не играет и не происходит, то загрузка не превышает 4%.
Скажите, пожалуйста:
Загрузка постоянная или только при переходах?
В консоли браузера что-то происходит (какие-то запросы / действия)?
Загрузка CPU после обновления страницы исчезает или остается?
Точно наш сайт тормозит (можно посмотреть в диспетчере задач Chrome Инструменты->Диспетчер задач)
Это поможет нам в поиске проблемы.
При выборе композиции из VK мы стараемся найти именно тот трек, который хотел услышать пользователь — не кавер, не ремикс, не концертную запись, а именно оригинал. Для этого мы дополнительно фильтруем результаты поисковой выдачи, сравнивая название трека и исполнителя с нашего сайта с выдачей VK. Далее сверяем длительность трека с длительностью, указанной у нас (взятой с last.fm, deezer, ...). Чем больше отличается наша длительность трека от длительности VK, тем менее релевантным считается трек.
Пока что фильтра / сортировки по качеству звучания нету. Мы планируем внедрить это в будущем.
Вообще глобально любая оптимизация — это повышение скорости работы приложения в ущерб затратам на его дальнейшую поддержку. Чем больше тюнинга, тем хуже код.
Проблема статьи в том, что автор начал оптимизировать приложение слишком рано и начал использовать приемы низкоуровневой оптимизации, которые на сегодняшний день дают небольшой прирост производительности при больших трудозатратах.
Я к тому, что по идее надо делать какое-то распределение ответов между замерами. Например, под нагрузкой отвечать toobusy() = false каждому десятому. Но как это сделать?
Пока нам удалось увидеть загрузку в опере при проигрывании трека. Есть загрузка процессора при переходах / движениях мышью, но это нормально т.к. срабатывают различные события и рендерятся элементы. Если в браузере ничего не играет и не происходит, то загрузка не превышает 4%.
Загрузка постоянная или только при переходах?
В консоли браузера что-то происходит (какие-то запросы / действия)?
Загрузка CPU после обновления страницы исчезает или остается?
Точно наш сайт тормозит (можно посмотреть в диспетчере задач Chrome Инструменты->Диспетчер задач)
Это поможет нам в поиске проблемы.
Пока что фильтра / сортировки по качеству звучания нету. Мы планируем внедрить это в будущем.
Полемика по поводу пары байт скоро перерастет в несколько гигабайт, хранящихся в БД Хабра в виде комментариев )
Проблема статьи в том, что автор начал оптимизировать приложение слишком рано и начал использовать приемы низкоуровневой оптимизации, которые на сегодняшний день дают небольшой прирост производительности при больших трудозатратах.