Pull to refresh

Comments 19

интересная штука, хоть и от фейсбука
Мне, напротив, нравится поход Фэйсбука к собственной инфраструктуре и разработке вообще.
А чем вас смущает, что фреймворк от «от фейсбука»?
У меня весь этот маркетинг вызывает ассоциацию с показом мод: «фреймворк от фейсбука» и «библиотека от твиттера» звучат примерно так же, как «сумка от версаче» и «сорочка от армани». Что же это значит по сути?
— Этот код написан инженерами (чаще всего одним-двумя) данной компании. Ок.
— Код используется внутри компании в 0-10 местах (скорее всего около 2), значит, он в принципе как-то работает в 0-5 конкретных сценариях использования. Тоже не впечатляет, потому что странно публиковать вообще неработающий код.
— Есть шанс чуть выше среднего, что код кто-то ревьюил, потому что это больше распространено в крупных конторах. (Как минимум, со слов спикеров от этих контор на конференциях. У меня лично очень маленькая выборка, и она скорее опровергает этот тезис.)
В результатах указано среднее значение по результатам 10 тестов

Читал описание и на английском, и всё равно не понял, что это за значение. Печаль-беда.
Запустили на сервере определенное количество потоков. Запустили на каждый поток по 2 клиента, которые в течении 60 секунд дёргали сервер GET-запросами. Получили какое-то количество обработанных запросов. Повторили всё вышеуказанное 10 раз и усреднили результат.
Если это количество запросов за минуту — то очень мало. Серьезно, на одном потоке менее 1000 rps?
Судя по всему — это количество запросов в секунду, которое может обработать сервер при заданном количестве потоков.
Похоже на правду. К сожалению, из текста это не очень ясно. Между прочим, с 8 потоками это почти 2 гигабита пропускной способности.
Это всё ведь локально на одной машине гонялось.
Да, для таких программ на простых задачах легко упереться в сеть. Интересно, как ведут себя балансировка и прочие вкусности — но про них как-то не очень много деталей.
Тоже присматриваюсь к этому фреймворку. Интересно было бы «пощупать» его в работе.
Автор, вы пробовали что-нибудь на нем делать? Поделитесь своими впечатлениями.
Нет пока, я смотрел на него поскольку мне в своём продукте нужен HTTP/2, но он у них пока не закончен. Но я буду за ним следить.
И все же — значения в минуту или в секунду? Еще, насколько я понял, асинхр. движек у вас folly, построен на libevent. С чем связан такой выбор?
Учитывая то, что как минимум работал (а может и по сей день работает) с Facebook такой гуру С++ как Andrei Alexandrescu, то мне был бы этот код реально интересен. А учитывая то, что он очень интенсивно работает над новыми стандартами С++, то этот код может оказаться прекрасным примером применения всего самого «вкусного» из С++. Спасибо за публикацию!
Ну Алексадреску давно уже подался в D, и в развитии C++ участвует уже довольно слабо.
Выглядит странно по началу. Но если подумать, смысл есть. Они получают параметр по ссылке, а не по указателю. Был бы указатель, после удаления записали бы nullptr в него и дальше с nullptr сравнивали бы. А так если что-то сломалось вроде как надо помнить что объект уже удалили. Ну и чтобы около каждого места с деструктором не ставить установку дополнительного флага «объект уничтожен», можно это автоматизировать через такого вот заботливого родителя. Который сообщит куда следует, что умер уже.
Хотя мне кажется лучше указатели копировать на объекты, чем так извращаться. Наверняка у них была веская причина или какой-то вид багов, от которых они таким образом спасались.
Нет, я понимаю зачем это можно было бы использовать, но они в примере, вроде, предлагают его использовать с асинхронными вызовами. Может я неправильно их понял и там всего лишь обработка асинхронных событий, но если там действительно асинхронные вызовы то от возможных гонок такие проверки не спасут.
Да, действительно странно. Т.к. для асинхронного кода эти классы явно еще не готовы. Ни синхронизации, ни атомарного флага не видно.
Sign up to leave a comment.