• Brubeck — быстрый, statsd-совместимый агрегатор метрик от GitHub
    0
    Сейчас никак, мы только планируем это делать. Сейчас у нас персентили считает каждый сервер сам по себе, что не совсем удобно, когда хочется посмотреть общую картину. Тут есть несколько вариантов:
    1. Проксировать «персентильные» метрики конвенционально по имени (скажем, если есть суффикс «histogram»)
    2. На уровне конфига statsd/аналога перечислять список метрик (возможно, со звездочками) которые пойдут на центральную считалку. Тут Heka выглядит более удобным инструментом для таких дел. Поскольку помимо метрик если еще и логи, которые тоже нужно доставлять, а с Хекой их еще можно сразу превращать и в метрики за компанию.
    3. В логике приложения я бы этого не делал. У нас несколько десятков сервисов на разных языках, работают над ними разные команды. Данную логику лучше инкапсулировать на уровне платформы и протокола, чтобы минимизировать риск что-то сделать не так. Суффикс «histogram» кажется приемлемым компромиссом.
  • Brubeck — быстрый, statsd-совместимый агрегатор метрик от GitHub
    0
    А вообще, не совсем понятно, зачем агрегировать метрики со всех серверов на одном бедном statsd/brubeck/whatever? Мы держим statsd на каждом сервере, агрегируем на месте и складываем оттуда напрямую в графит. Проблем с произвотидельностью statsd не было, даже на балансерах, где проскакивает 2600 метрик в секунду. Не 4.3 миллиона, конечно, но у нас столько и не будет никогда с одного сервера.
    Один общий statsd/аналог следует держать рядышком для подсчета гистограм/персентилей, ибо их нужно агрегировать в одном месте. «Гистограммные» метрики — это около 5% от всех наших метрик, что пишем. Так что, statsd там тоже хватит.
  • Brubeck — быстрый, statsd-совместимый агрегатор метрик от GitHub
    0
    Есть еще Heka hekad.readthedocs.org/en/v0.9.2 — не знаю, на сколько производительный, но он еще и logstash заменяет.
  • Печальное состояние сисадмина в эпоху контейнеров
    +2
    Таким образом, для того, чтобы обновить ВСЕ приложения, запущенные на одном base image, вам нужно всего лишь перезапустить контейнеры

    Нет, перезапустить контейнеры будет не достаточно. Потому что слои ссылаются на уникальные идентификаторы образов, которые имеют мало общего с «тэгами», которые мы используем в «FROM».
    Чтобы обновить базовый образ для 10 работающих контейнеров, следует пересобрать образы для каждого из них (docker build), затем удалить все и создать заново. Потому что нельзя сделать restart контейнера, подменив ему идентификатор образа.
    И это не баг, а фича «immutable infrastructure», гарантирующая неизменяемость базового слоя контейнера в процессе его жизни. Конечно, можно зайти через «nsenter» или «docker exec -ti bash» или «ssh» или, боже упаси, напрямую в файловую систему верхнего слоя контейнера на хостовой машине, но это будет не «by design».
    С другой стороны, необходимость пересоздавать контейнеры для обновлений образа это большая боль, сводящая на нет такие красивые концепции, как "--volumes-from" и "--link".
    В итоге, лобая система, используящая Докер более-мение серьезно, обрастает кучей костылей тут и там.

    По поводу цивфовых подписей, Докеры же сделали это в 1.6 и Registry 2.0.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    Осознал. Теперь понятно, почему геттеры настоятельно рекомендуется делать максимально быстрыми и свободными от побочных эффектов.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    А почему в данном случае symbolsLength() вызывается по два раза при каждом вводе символа?
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    Вот здесь об этом автор говорит: www.youtube.com/watch?v=ZhfUv0spHCY#t=1871s

    Но если у меня в scope массив и я сделаю в него push, я же изменю массив в прототипе, и вся магия развалится.

    Не развалится, если эксплицитно объявить этот массив в текущем $scope, что и подразумевается.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    Конечно, jsfiddle.net/m3Z8r/1/

    К моему удивлению, Angular ведет себя в данном случае довольно непредсказуемо:

    — при переключении на template1 он вызывает функцию symbolsLength() дважды
    — при переключении на template1 — единожды (а нужно, чтоб вообще не вызывал)

    Но если установить изначальное значение templateName в 'template2' — тогда не вызовет symbolsLength() ни разу, что правильно.

    Я сам знаком с Angular не больше недели, и мне интересно, почему так получается. Думаю, задам вопрос на stackoverflow. Видимо, на то есть свои причины, но xdenser все-таки прав касательно отсутствия объективных преимуществ обоих подходов.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    1. Насчет POJO — это не совсем верно, поскольку в контроллер нам подсовывают клон объекта с предыдущей итерации.

    Не клон, а наследник, имеющий родительский scope в качестве prototype.

    Дело в том, что POJO — это то, что мы объявляем в этом scope (который подсунули). Scope — это, по сути, контейнер: jsfiddle.net/W3aMj/

    $scope.model — это объект, который мы создали сами, с ним мы и работаем.

    И кстати эти контроллеры в глобальном пространстве имен выглядят подозрительно. Надеюсь, их можно спрятать.

    Да, меня это тоже сначала обескуражило, а потом оказалось, что можно по-нормальному. Все равно удивляюсь, почему в документации примеры с глобальными переменными. Наверное, чтоб продемонстрировать, как все просто :) jsfiddle.net/ayJqy/1/

    Насчет того что множественное обновление массива вызывает обновление UI на каждой итерации… Что в Angular на этот счет?

    Дык он на следующем тике все обновит, делая «dirty check». В этом же и фишка. В текущем тике можно менять хоть 1000 раз — ни чего не произойдет.
    Как такое сделать в Knockout кстати?

    В общем я думаю подход Angular vs Knockout это тема скорее для холивара. Потому что объективных преимуществ нет ни у того ни у другого.

    Для меня объективное преимущество Angular — отсутствие недостатотков Knockout. Недостатков такого масштаба у Angular пока не вижу. Наверное, это единственная причина, по которой я продолжаю этот разговор :)

    А вообще действительно, давайте закругляться. Если у вас есть вопросы касательно того, как устроен Angular, постараюсь на них ответить.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    > И с Knockout можно избежать каши, просто рецепта нет.
    Возможно, но есть пара нюансов.

    > То же относится и к AngularJS — вам дают готовый рецепт структурирования
    Это, пожалуй, самый главный плюс для меня.
  • Оптимизация knockoutjs при динамическом добавлении и удалении темплейтов
    0
    Сначала был в восторге от Backbone. Потом от Knockout. Потом от Knockback. С развитием приложений и усложнением интерфейсов я начал сталкиваться с сюрпризами и ограничениями, которые приходилось решать набором всяческих самописных костылей. Иногда конечно оказывалось, что я протупил и проблема решалась просто заменой computed на fn(), но все равно в итоге почему-то получалась каша. Работающая, но каша.

    Недавно наткнулся на эту статью и решил попробовать AngularJS. Ребята, так это же совсем другое дело. Порог вхождения, конечно, выше — нужно сначала въехать в ряд сомнительных на первый взгляд понятий и принципов — но в итоге получается нечто более структурированное, стабильное, «бескостыльное».

    Если не знакомы, советую поиграться, как минимум, для осведомленности :)
  • Старый ридер вернулся
    0
    Молодцы! Социальный RSS-ридер — интересная и нетривиальная задача.

    Два года назад мы с коллегой делали Eventr, но спустя год мы переключились на разработку другого проекта, после чего перестали поддерживать «старика», поскольку это оказалось довольно дорого и нерентабельно.

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

    Неблагодарное это дело. Тут нужно либо море бабла, либо океан энтузиазма — чего вам и желаю! :)
  • Tactoom. Как насчет мидл-блоггинга?
    0
    Попробуйте зайти прямо на регистрацию tactoom.com/register
  • Tactoom. Как насчет мидл-блоггинга?
    0
    Где пишет?
  • Tactoom. Как насчет мидл-блоггинга?
    0
    Гениально и просто! Сделал.
  • Tactoom. Как насчет мидл-блоггинга?
    –2
    Забавно вы интерпретировали :)
    Таким образом фильтруется поток людей с хабра, дабы не было хабраэффекта и люди могли спокойно пользоваться сервисом.
  • Z-music.ru — обновленный поиск музыки
    0
    А, понял, музыка-то из вконтакта :)
  • Z-music.ru — обновленный поиск музыки
    +1
    Ребятушки,

    Зашел на z-music.ru, ввел имя своего любимого исполнителя «Debussy», увидел треки, автором которых он не является z-music.ru/search/?q=debussy
    Например, трек под названием «Claude Debussy — My Love» — это вообще саундрек Амели (Yann Tiersen).

    Что-то у вас там напуталось.
  • node-sync — псевдо-синхронное программирование на nodejs с использованием fibers
    0
    Представьте себе, что вам нужно последовательно прочитать три разных файла, вместо одного. Тогда в последнем случае, вы сделаете:

    Sync(function(){
        
        readFileByLinesSync('text1', function(data) {
            //...
        });
        
        readFileByLinesSync('text2', function(data) {
            //...
        });
        
        readFileByLinesSync('text3', function(data) {
            //...
        });
    
        // do somehting else..
        
    })
    


    А без sync тут будут макароны.

    Кстати, придумал более изящный способ реализации синхронного readFileByLines:

    function readFileByLinesSync(path, fn) {
        
        var input = fs.createReadStream(path);
        var remaining = '';
    
        input.on('data', function(data) {
            remaining += data;
    
            var index = remaining.indexOf('\n');
            while (index > -1) {
                fn(remaining.substring(0, index)); // process line
                remaining = remaining.substring(index + 1);
                index = remaining.indexOf('\n');
            }
        });
        
        // Yield here
        input.once.sync(input, 'end');
        
        // process last line
        if (remaining.length > 0) {
            fn(remaining);
        }
        
    }.async(); // <-- important
    


    Но если серьезно, ваша реализация построчного чтения файла будет глючить с большими строками — нужен буффер. Вот, пример: blog.jaeckel.com/2010/03/i-tried-to-find-example-on-using-node.html
  • node-sync — псевдо-синхронное программирование на nodejs с использованием fibers
    0
    (случайно отправил)
    «синхронная» реализация readFileByLinesAsync:

    function readFileByLinesSync(path, fn) {
        
        var future = new Sync.Future();
        var input = fs.createReadStream(path);
        var remaining = '';
    
        input.on('data', function(data) {
    
            remaining += data;
    
            var index = remaining.indexOf('\n');
            while (index > -1) {
                var line = remaining.substring(0, index);
                remaining = remaining.substring(index + 1);
                fn(line);
                index = remaining.indexOf('\n');
            }
        });
    
        input.on('end', function() {
            if (remaining.length > 0) {
                fn(remaining);
            }
            // End
            future();
        });
        
        future.yield();
        
    }.async(); // <-- important
    
    
    //----------------
    // My sync code
    var Sync = require('sync');
    
    Sync(function(){
        
        // This will block until all lines will be passed
        readFileByLinesSync('text', function(data) {
            //add data to mysql if data.type = foo
            //...
        });
        
        // do something else..
        
    })
    
  • node-sync — псевдо-синхронное программирование на nodejs с использованием fibers
    0
    Я бы в данном случае воспользовался Futures API. При этом, саму реализацию построчного чтения файла оставил бы асинхронным.

    function readFileByLinesAsync(path, callback) {
        
        var input = fs.createReadStream(path);
        var remaining = '';
    
        input.on('data', function(data) {
    
            remaining += data;
    
            var index = remaining.indexOf('\n');
            while (index > -1) {
                var line = remaining.substring(0, index);
                remaining = remaining.substring(index + 1);
                callback(line);
                index = remaining.indexOf('\n');
            }
        });
    
        input.on('end', function() {
            if (remaining.length > 0) {
                callback(remaining);
            }
            // End
            callback(null);
        });
    }
    
    //----------------
    // My sync code
    var Sync = require('sync');
    
    Sync(function(){
        // My sync code
        var future = new Sync.Future();
        
        readFileByLinesAsync('text', function(data) {
            // resume
            if (data === null) return future();
            
            //add data to mysql if data.type = foo
            //...
        });
        
        // wait until we read all lines
        future.yield();
        
        // do something else..
        
    })
    


    (почему-то комментарии автоматически сдвигаются вправо..)

    Ну а если очень хочется «синхронную» реализацию readFileByLinesAsync, тогда:

    function readFileByLinesSync(path, fn) {

    var future = new Sync.Future();
    var input = fs.createReadStream(path);
    var remaining = '';

    input.on('data', function(data) {

    remaining += data;

    var index = remaining.indexOf('\n');
    while (index > -1) {
    var line = remaining.substring(0, index);
    remaining = remaining.substring(index + 1);
    fn(line);
    index = remaining.indexOf('\n');
    }
    });

    input.on('end', function() {
    if (remaining.length > 0) {
    fn(remaining);
    }
    // End
    future();
    });

    future.yield();

    }.async(); // < — important

    //----------------
    // My sync code
    var Sync = require('sync');

    Sync(function(){

    // This will block until all lines will be passed
    readFileByLinesSync('text', function(data) {
    //add data to mysql if data.type = foo
    //…
    });

    // do something else…

    })
  • node-sync — псевдо-синхронное программирование на nodejs с использованием fibers
    0
    Напишите пример того, что вам нужно на callbacks — а я переведу на sync.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    По умолчанию с реплики вообще читать нельзя. Только если принудительно указать slaveOk=1.
    А Mongodelay вообще просто в списке серверов нет (для клиента).
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    Поклацайте вот этот доклад spf13.com/post/mongodb-e-commerce-and-transactions
    Там все сказано по поводу целостности и атомарных операций в mongo.

    Денормализации много, на каждое денормализованное значение есть функция пересчета/починки.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    Я тоже особо не сильно мерял, почему именно он тормозит. Интуитивно — это все их StateMachine.
    Созбать объект/провалидировать/сохранить — ок. Но выбрать 100 объектов, каждый из которых содержит вложенные коллекции — лучше делать на mongodb-native.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    2x.

    > Если у вас не взлетела вторая, значит, не стоит переходить на нее?
    Было бы время, я бы вообще выбросил mongoose из стэка.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    > Кстати, сходу вопрос, а вот не пожалели что связались с нодой? Стоило ли потраченное время полученной отдачи?
    Не жалею. Но и не скажу, что особо рад.

    > Кстати, а чего связались со статикой на ноде против того же nginx, это хоть как-то оправдано?
    Статику отдает nginx. На node написаны скрипты, которые ее собирают.

    > < 0ms это сколько
    0.9 ms
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +1
    Хотелось попробовать «сырую и спорную технологию».
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    new Date
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    Во второй статье собираюсь об этом написать.
    Ключевой момент — «волшебность» mongoose, а именно его StateMachine.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    Не имею однозначного ответа на этот вопрос. Исторически так сложилось.
    Когда-то были на амазоне, потом оказалось, что Rackspace дешевле и саппорт лучше + OpenStack открытая и знакомая платформа. Сейчас CDN как-то странно лагает, может переберемся обратно на Amazon.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    0
    Mongodelay это специальная фича, позволяющая принудительно держать slave в 4-х часах.
    С него чтение не происходит — это бэкап.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +1
    10-15 часов в сутки
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +1
    Точно. Сделаю завтра comet.tactoom.com:80
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +1
    Это там, где «секрет»
    Mongodb journaling, Mongodelay 4h, redis slave + snapshots.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +4
    Нас двое, но Давид — дизайнер, он не программист.
    Я сам написал этот проект за 8 месяцев.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +4
    Я работал с MemcacheQ, Amazon SQS, Active MQ… Все они неплохие. Но зачем добавлять еще одну технологию в стэк, если Redis справляется с этой задачей просто идеально?
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +2
    Раньше было так, дайте-ка вспомню, почему…

    Потому что записи приходят через ajax в виде html, и нужно проассоциировать json данные с каждой конкретной записью. Через атрибут оказалось удобнее.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +5
    > кто добился чего-то на Ноде и может немного позволить расслабится
    Они гипер-вальяжные.

    > P.S. А не много ли 300мс в среднем при такой масштабной подготовке?
    Есть минимум, ниже которого отклик не может быть быстрее физически, как не масштабируй. 300ms — это золотая середина. И это не много.

    Поиск, например, 10-50ms.
  • Tactoom.com изнутри — социальная блог-платформа на NodeJS/NoSQL
    +1
    > Простите, а какая нагрузка на ваш проект в целом? (сколько примерно пользователей, сколько уников в день)
    ~2к хостов в день
    ~300-500 человек онлайн

    > Тот же вопрос по-другому: нужна ли вся эта чехарда с масштабированием и т.п.
    А вы попробуйте без «чехарды» поднять такой проект и держать хотя бы 100 онлайн :)