Pull to refresh
13
0
Виталий Аминев @Makeomatic

Пользователь

Send message

Подождите, а как вы измеряли скорость? Почему здесь не учитыватся тот факт что нода однопоточная (не учитываем либюв и "асинхронность"). У нас есть ивент-луп и чем эффективнее ваш код — тем меньше вы его едите.


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


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


Несколько сумбурный коммент, но важно понимать что мейн тред он один и вся "псевдо" асинхронщина (к примеру параллельное выполнение синхронных функций через промис.алл, только замедлит работу)

попробуйте засунуть 70гб данных в редис на машине со 100 гб и потом сделайте BGSAVE, может быть, память забивается по какой-то другой причине, поправьте меня если это так, но по моему опыту цпу на форке 100% (понятно — надо это все пожать) и память тоже забивается абсолютно вся, потом адские свопы на диск… в общем страх

Данные потерять очень легко. Чтобы вашей машине с редисом не было плохо — убедитесь что на железке есть хотя бы 2 ядра — на мейн тред и форк под рдб или aof rewrite, а так же половина свободной памяти (иначе негде будет делать слепок данных для рерайта или снепшота) — не будет проблем с латенси. Помимо этого можно сменить конфигурацию персистности на append only file с синком раз в секунду и снэпшот ночью когда нагрузки нет. Тогда вероятность потерять данные значительно ниже.

  1. канонично в node.js использовать process.hrtime() для измерения относительных промежутков времени — функция значительно точнее.

    const start = process.hrtime();
    // do op
    const end = process.hrtime(start);
    console.info("Время исполнения (hr): %ds %dms", end[0], end[1]/1000000);

  2. var a внутри цикла for — постоянное переобъявление переменной, используйте let если нужно ограничить scope, или объявите до цикла

  3. штудируем https://github.com/petkaantonov/bluebird/wiki/Optimization-killers касательно оптимизаций — многие вопросы отпадут сами собой
1. В эластике схема несколько другая. Есть индекс -> фиксированное количество шардов -> далее либо автоматом распределяется эластиком, либо опять же «автоматом», но с использованием routing key. У нас проблема в том, что нет 10 профилей для каждой соц сети, а есть 1 большой профиль со всеми сетями. Все «условно-уникальные» идентификаторы — это массивы таких идентификаторов. Поэтому для рутинга так ничего и не было придумано. Зато можно кешировать выборки по данным соц сетям внутри nested документов, что в свою очередь тоже повышает скорость индексирования

2. Много разных кластеров или 1 — это не принципиально. По сути в эластике индекс, шард, сегмент и так далее — это самостоятельные Lucene индексы.
Сейчас мы обрабатываем ~ 50 соц сетей. Профиль — это агрегированные данные по конкретному человеку исходя из наших алгоритмов.
3. Маппинг, который мы используем занимает порядка 300 строчек, типы разнятся, и включают в себя nested объекты, в них есть просто термины, даты, комбинации всего перечисленного.
Роутинг — отличная вещь, когда есть хотя бы 1 признак, по которому можно из-вне создать уникальный ключ для группы документов. К примеру у вас есть база пользователей и логично что все, что относится к этому пользователю должно быть на 1 шарде — производительность растет экспоненциально, ведь мы не опрашиваем 400 шардов как в нашем случае, а всего 1.

При всех плюсах рутинга в нашем случае очень сложно выделить какой-то один признак (много емейлов, много телефонов, много социальных сеток — а профиль 1)
1. www.elasticsearch.org/overview/marvel/
2. Всего 18 мастер нод, на каждой ~ 100 гб RAM. 30% -> Java Heap (для всяких кешей фильтров, сортировок и тп), 70% -> OS, RAM забивается под 90%, из-за того что при использовании mmapfs данные с диска кешируются именно туда, за счет этого сильно растет производительность
3. уточните вопрос
4. 10к документов балком ~ 90 мс. Но это все равно что пальцем в небо — все зависит от размера документа, анализаторов и тп вещей.


Примерно так это все выглядит в разрезе ноды, так что нет — не мучает

Information

Rating
Does not participate
Location
Канада
Registered
Activity