Ну хотя бы при том, что ведет проект OpenBSD, и OpenSSH заодно.
Многие забывают, что людей, способных эффективно вести OpenSource-разработку такого сложного проекта, как операционная система, да еще и с уклоном в безопасность и «непробиваемость», гораздо меньше, чем тех, у кого есть свободные 20 тысяч баксов.
Он не кривой. Просто появился раньше, чем спека Promices/A+(*), поэтому реализует стандарт не совсем верно. Но менять реализацию никто не будет, т.к. уже полно кода написано с учетом старого API.
Нет, там компиляция проходит в несколько этапов: вначале генерируется неоптимизированный код, а затем по ходу его выполнения собирается информация о частоте вызова методов и фактических типах параметров и переменных. По этим данным собирается оптимизированный код. Если в какой-то момент встречается какой-то новый тип, то приходится возвращаться к первоначальному варианту кода, но данные продолжают собираться, чтобы подготовить новый оптимизированный вариант. В сложных случаях — в частности в NodeJS этой бедой страдает EventEmitter — виртуальная машина вынуждена оптимизировать и деоптимизировать одни и те же функции снова и снова.
Вы ж понимаете, что это громкие слова. По пунктам:
PayPal: переводят сайт на NodeJS с Java. Процессинг платежей так и остается на смеси Java и C++, и планов по миграции на что-то другое для этих задач нет. Цель миграции для сайта — иметь возможность быстро менять наполнение, проводить A/B тесты для конверсий и т.д. Т.е. сугубо маркетинговые задачи. С той же легкостью они могли мигрировать на Django или Rails — им просто нужен был инструмент, позволяющий работать с фаннелом в очень сжатые сроки. Ну и сами понимаете, сайт для них — это не узкое место в плане производительности.
Walmart и LinkedIn: Node.js используется как прокси для мобильных сервисов. Весь тяжелый процессинг так же остается на стороне Java. Поэтому неудивительно, что на Black Friday в волмарте Нод вел себя спокойно — он также не был узким местом.
Групону до перехода хватало производительности Рельсов. Тот факт, что Node.js им подошел, меня нисколько не удивляет. Кроме того, при переходе ребята сильно переработали архитектуру всего сервиса, и основной выигрыш в производительности поличили именно от этого, а не от скорости v8.
Trello — небольшой проект. Называть хайлоадом все, что смотрит в интернет, я бы не стал.
ql.io мертв уже больше года. Но даже когда он еще жил, он был «research»-проектом и никогда не процессил больших объемов данных. В инфраструктуре Ebay он не используется. Ближайший аналог — YQL — крутится на JVM+Rhino, и там нагрузки действительно колоссальные.
> Что для вас хайлоад? Сотня млн. запросов в день, норм? А несколько сотен?
Хайлоад не начинается с какой-то четкой границы. И не зависит только от запросов в секунду. Например, допустим, у нас есть сервис, в котором нет сетевых эффектов: у каждого пользователя свой набор данных и никто не запрашивает чужие данные: т.е. нет никакого обмена сообщениями, общих документов, одновременного редактирования и т.п. Один железный бокс в такой системе обслуживает 50 пользователей с комфортным запасом по производительности. У нас 5 миллионов пользователей, и для них мы подняли 100 тысяч таких боксов, пошардили данные и настроили лоад-балансер и автозамену падающих узлов. Если их станет в два раза больше, мы просто поднимем в 2 раза больше боксов, и за исключением выросших затрат на хостинг, к никаким другим последствиям это не приведет. Хайлоад ли это?
А вот если есть сетевые эффекты, то рост пользовательской базы в 2 раза может легко привести к тому, что какие-то части системы не смогут работать без значительной переработки. Вот именно такие «узкие места» в производительности в моем понимании — хайлоад. В Фейсбуке это рассылки уведомлений, сообщений, обновление новостных лент. А вот система загрузки фотографий явно скейлится линейно с ростом нагрузки, и хайлоадом при всем количестве железа может быть названа только с натяжкой.
Во всех вышеперечисленных примерах Node.js, хоть и является частью большой системы, но не оказывается узким местом в плане роста инфраструктуры, поэтому заслуги платформы в успехе данных проектов практически нет. На месте Node.js мог оказаться Питон, Руби, PHP или Perl, и ничего бы кардинально не поменялось.
И да, Нод я люблю и на нем работаю. В нашем проекте есть части на Node.JS, Erlang, Java, Python, и несмотря на миллионы пользователей и большую нагрузку, я не могу назвать части, написанные на NodeJS, хайлоадом. Узкие места сейчас для нас покрывают Erlang и Java — там хайлоад есть. Показательно, что именно из-за них мне приходится иногда просыпаться по ночам. Из-за Node.js я не просыпаюсь не потому, что он супер-надежный, а потому, что он не находится на критическом пути.
В этих компаниях та же ситуация, и я уверен, что пока Эран и его друзья смотрели на равные графики нодовских процесссов, ребятам из отделов бекенд-сервисов Волмарта пришлось изрядно попотеть.
Единственный хайлоад-проект на Ноде, о котором мне известно — это Voxer.
Node.js — не хайлоад-решение и никогда так не позиционировался. Он «быстрый» в смысле «быстрее, чем аналогичные решения на других скриптовых языках — Python, Ruby, Perl, PHP», а не в смысле «быстрее всех». Члены команды разработки Node.js даже никогда не обсуждают его скорость в сравнении с Go, Rust, C++ и другими компилируемыми языками. Не сравнивают они его и с высокопроизводительными VM типа Java или .NET: у тех в запасе почти 2 десятка лет работы над производительностью. Сегодняшний V8 по уровню развития как раз сравним с JVM примерно десятилетней давности.
В вашем конкретном случае в дополнение к собственно работе с HTTP ему еще приходится запускать виртуальную машину, заниматься сборкой мусора и JIT-компилировать код и т.д. Поэтому сравнивать его с Nginx или libevent вообще не имеет смысла. Вы же не сравниваете скорость болида Формулы 1 и тролейбуса, правда?
Статья хорошая, но будьте осторожны. Turnitin и другие компании не только поделили этот рынок, но еще и здорово покрыли его патентами на манер того, как это происходит в индустрии медиакодирования. Из-за этого выйти на него начинающему проекту очень сложно.
Вопрос в том, что заинжектить код в процесс браузера практически невозможно. Для этого есть две возможности: JS и плагины. Плагины и так в отдельном процессе-песочнице уже много лет. А с JS-ом все очень сложно. Базовая идея: подобрать такой код на JavaScript, чтобы при JIT-компиляции результирующий машинный код делал то, что хочется атакующему. Задача эта сложная, и живых примеров подобных атак даже в «лабораторных» условиях еще не создано.
Не понимаю, за что минусуют. Не обязательно делать пароли в виде «Az4H%8L;0» Человеку гораздо проще использовать слова в сочетании с белибердой: «Get Humb1e Elephant 52&» — пароль куда как сильнее из-за того, что:
1. отдельные сегменты не являются простыми словами и простым перебором из серии «соедини три слова из словаря» тут ничего не добиться
2. Общая длинна пароля куда больше сокровенных 8-12 символов, о которых нас просят сайты, поэтому посимвольно его тоже не подберешь
3. Пароль куда как проще запомнить.
В связи с этим выражаю свое «Фи!» всем сайтам, которые не разрешают пробелы в паролях и какого-то фига ограничивают их по длинне.
Странно, а зачем вы разрабатываете инструмент для исчезающего рынка? Без реферальных данных он работать не сможет, а реферальные данные Гугл начал скрывать 2 года назад. Тогда это было делом добровольным (руками нужно было вбивать encrypted.google.com), но постепенно становится принудительным. И ясно было с самого начала, что остальные поисковики последуют за Гуглом.
Что вы будете делать, скажем, через полгода, когда «эксперимент» Яндекса завершится успешно для «приватности», и процент визитов с реферальными данными от поисковиков снизится до 0,001?
— Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
— Плагины и так давно запускаются в отдельных процессах.
— Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
— Тормоза тоже убрали в рамках проекта «Snappy»
Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
Забавно, как разные языки программирования наступают на одни и те же грабли. Году в 2011 была шумиха из-за такой же проблемы в JVM. Шуму было действительно много: мало того, что новость несколько дней висела в топе ХаккерНьюс, так про нее написали всякие издания вроде ZDNet, The Register, InfoWorld и т.п. И если б я был одним из коммитеров Ruby, Python или другого языка программирования, я бы проверил, а не подвержен ли мой рантайм этой проблеме.
Но по всей видимости, проблема не супер острая. В багтреккере JVM багрепорт висел несколько лет, и никто не чесался его фиксить. Видимо, подобрать правильный эксплойт, чтобы получить от дыры какой-то толк, довольно сложно.
contentEditable — очень распространенная штука. Его поведение по умолчанию — да, не кроссплатформенное, — но его можно «причесать».
Twitter и Google+, например, использует contentEditable для поля новых постов. В Outlook.com поле ввода текста письма — тоже contentEditable. В Gmail тоже так было. Первые версии Google Docs и других онлайн-редакторов были или остаются на contentEditable. Куча платформ для блогов и CMS тоже его используют.
Как раз на прошлых выходных пользовался MutationSummary в рамках хаккатона. Хорошая вещь, но разочарований больше, чем радостей. На видео один из разработчиков показывает DOM-зеркало: на одной странице поисходят изменения, а в другой они полностью повторяются. На практике взять код «как есть» не удалось, т.к. он предполагает, что доступ к оригиналу возможен через DOM API — либо это фреймы на одной странице, либо как в примере — связь через расширение браузера. Мы же хотели «достучаться» до странице на другом устройстве, и к сожалению, так «зеркало» не работает.
А настраивать mutation summary руками оказалось тоже неприятно. Если у вас простой случай — например, текст внутри элемента меняется или меняются атрибуты — то все замечательно. Мы же работали с rich-текстом через contentEditable, и там простое изменение часто влечет к появлению 5--6 «мутаций» одновременно.
В итоге остались баги, которые поправить вовремя не удалось. И как следствие, низкие оценки :(
Вы переоцениваете уровень людей, занимающихся разработкой. Да, есть ассы своего дела, есть люди с инженерным подходом к делу, которые подумают и про билд, и про разные версии нативных компонентов. Но есть и те, кто открыл Гугл, накопипастил текста с разных блогов и форумов, кое-как добился того, что приложение работает на его телефоне и отправил это все в Google Play.
Я тут недавно ради интереса решил попробовать покодить под iOS. И вот что я вам скажу: 90% ответов гугла на запросы по теме — это посты многостаночников-самоучек. Т.е. парень берется за любую работу: нужно визитку сверстать? — пожалуйста, нужен сайтик на Джумле — вот вам, нужен макет в фотошопе сделать? — тоже могу, и SEO, и рекламу, и в твиттере пиарить он умеет. И вот такой дизайнер-верстальщик решил, что PHP и Ruby on Rails — вчерашний день, а сегодня он будет делать приложения для Айфона или для Гэлэкси. У него что-то получилось, и он сразу себе это в блог. И качуют эти посты по всему инету.
Есть документация от Apple — глубокая, но неудобная. Есть StackOverflow с ответами 2хгодичной давности, большинство из которых уже неактуальны. Ну и куча мусора в интернете.
И это странно, ведь этому посвящена целая глава в документации.
Такие люди не станут ее читать, пока сами не столкнутся с такой проблемой.
не слишком сложная задача написать соответствующие билд-скрипты самому.
Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.
Я об этом не знал. Думаю, многие разработчики тоже не знают. Для большинства проблема звучит так: есть код на Java и C++ и на выходе нужно получить .apk для загрузки в Google Play. Если бы инструменты по умолчанию собирали пачку .apk-файлов для разных платформ, то проблема не стояла бы так остро.
Многие забывают, что людей, способных эффективно вести OpenSource-разработку такого сложного проекта, как операционная система, да еще и с уклоном в безопасность и «непробиваемость», гораздо меньше, чем тех, у кого есть свободные 20 тысяч баксов.
* $.Deffered реализует Promices/A
1. Платные аккаунты?
2. Собираем лайки -> на основе лайков рекомендации «You may also like...» -> Promoted likes / Просто реклама?
3. Банально доступ к хранилищу всех заинтересованных (те же рекламные сети и поисковики) за деньги?
На первой стратегии много не заработать, а из-за высокой вероятности стратегий 2 и 3 не хочется пользоваться сервисом.
Таки Jit-компиляция есть, сборка мусора есть. Т.е. оверхед есть.
PayPal: переводят сайт на NodeJS с Java. Процессинг платежей так и остается на смеси Java и C++, и планов по миграции на что-то другое для этих задач нет. Цель миграции для сайта — иметь возможность быстро менять наполнение, проводить A/B тесты для конверсий и т.д. Т.е. сугубо маркетинговые задачи. С той же легкостью они могли мигрировать на Django или Rails — им просто нужен был инструмент, позволяющий работать с фаннелом в очень сжатые сроки. Ну и сами понимаете, сайт для них — это не узкое место в плане производительности.
Walmart и LinkedIn: Node.js используется как прокси для мобильных сервисов. Весь тяжелый процессинг так же остается на стороне Java. Поэтому неудивительно, что на Black Friday в волмарте Нод вел себя спокойно — он также не был узким местом.
Групону до перехода хватало производительности Рельсов. Тот факт, что Node.js им подошел, меня нисколько не удивляет. Кроме того, при переходе ребята сильно переработали архитектуру всего сервиса, и основной выигрыш в производительности поличили именно от этого, а не от скорости v8.
Trello — небольшой проект. Называть хайлоадом все, что смотрит в интернет, я бы не стал.
ql.io мертв уже больше года. Но даже когда он еще жил, он был «research»-проектом и никогда не процессил больших объемов данных. В инфраструктуре Ebay он не используется. Ближайший аналог — YQL — крутится на JVM+Rhino, и там нагрузки действительно колоссальные.
> Что для вас хайлоад? Сотня млн. запросов в день, норм? А несколько сотен?
Хайлоад не начинается с какой-то четкой границы. И не зависит только от запросов в секунду. Например, допустим, у нас есть сервис, в котором нет сетевых эффектов: у каждого пользователя свой набор данных и никто не запрашивает чужие данные: т.е. нет никакого обмена сообщениями, общих документов, одновременного редактирования и т.п. Один железный бокс в такой системе обслуживает 50 пользователей с комфортным запасом по производительности. У нас 5 миллионов пользователей, и для них мы подняли 100 тысяч таких боксов, пошардили данные и настроили лоад-балансер и автозамену падающих узлов. Если их станет в два раза больше, мы просто поднимем в 2 раза больше боксов, и за исключением выросших затрат на хостинг, к никаким другим последствиям это не приведет. Хайлоад ли это?
А вот если есть сетевые эффекты, то рост пользовательской базы в 2 раза может легко привести к тому, что какие-то части системы не смогут работать без значительной переработки. Вот именно такие «узкие места» в производительности в моем понимании — хайлоад. В Фейсбуке это рассылки уведомлений, сообщений, обновление новостных лент. А вот система загрузки фотографий явно скейлится линейно с ростом нагрузки, и хайлоадом при всем количестве железа может быть названа только с натяжкой.
Во всех вышеперечисленных примерах Node.js, хоть и является частью большой системы, но не оказывается узким местом в плане роста инфраструктуры, поэтому заслуги платформы в успехе данных проектов практически нет. На месте Node.js мог оказаться Питон, Руби, PHP или Perl, и ничего бы кардинально не поменялось.
И да, Нод я люблю и на нем работаю. В нашем проекте есть части на Node.JS, Erlang, Java, Python, и несмотря на миллионы пользователей и большую нагрузку, я не могу назвать части, написанные на NodeJS, хайлоадом. Узкие места сейчас для нас покрывают Erlang и Java — там хайлоад есть. Показательно, что именно из-за них мне приходится иногда просыпаться по ночам. Из-за Node.js я не просыпаюсь не потому, что он супер-надежный, а потому, что он не находится на критическом пути.
В этих компаниях та же ситуация, и я уверен, что пока Эран и его друзья смотрели на равные графики нодовских процесссов, ребятам из отделов бекенд-сервисов Волмарта пришлось изрядно попотеть.
Единственный хайлоад-проект на Ноде, о котором мне известно — это Voxer.
В вашем конкретном случае в дополнение к собственно работе с HTTP ему еще приходится запускать виртуальную машину, заниматься сборкой мусора и JIT-компилировать код и т.д. Поэтому сравнивать его с Nginx или libevent вообще не имеет смысла. Вы же не сравниваете скорость болида Формулы 1 и тролейбуса, правда?
1. отдельные сегменты не являются простыми словами и простым перебором из серии «соедини три слова из словаря» тут ничего не добиться
2. Общая длинна пароля куда больше сокровенных 8-12 символов, о которых нас просят сайты, поэтому посимвольно его тоже не подберешь
3. Пароль куда как проще запомнить.
В связи с этим выражаю свое «Фи!» всем сайтам, которые не разрешают пробелы в паролях и какого-то фига ограничивают их по длинне.
Что вы будете делать, скажем, через полгода, когда «эксперимент» Яндекса завершится успешно для «приватности», и процент визитов с реферальными данными от поисковиков снизится до 0,001?
— Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
— Плагины и так давно запускаются в отдельных процессах.
— Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
— Тормоза тоже убрали в рамках проекта «Snappy»
Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
Но по всей видимости, проблема не супер острая. В багтреккере JVM багрепорт висел несколько лет, и никто не чесался его фиксить. Видимо, подобрать правильный эксплойт, чтобы получить от дыры какой-то толк, довольно сложно.
В любом случае, обновиться надо.
Twitter и Google+, например, использует contentEditable для поля новых постов. В Outlook.com поле ввода текста письма — тоже contentEditable. В Gmail тоже так было. Первые версии Google Docs и других онлайн-редакторов были или остаются на contentEditable. Куча платформ для блогов и CMS тоже его используют.
Так что вы его наверняка встречали.
А настраивать mutation summary руками оказалось тоже неприятно. Если у вас простой случай — например, текст внутри элемента меняется или меняются атрибуты — то все замечательно. Мы же работали с rich-текстом через contentEditable, и там простое изменение часто влечет к появлению 5--6 «мутаций» одновременно.
В итоге остались баги, которые поправить вовремя не удалось. И как следствие, низкие оценки :(
Я тут недавно ради интереса решил попробовать покодить под iOS. И вот что я вам скажу: 90% ответов гугла на запросы по теме — это посты многостаночников-самоучек. Т.е. парень берется за любую работу: нужно визитку сверстать? — пожалуйста, нужен сайтик на Джумле — вот вам, нужен макет в фотошопе сделать? — тоже могу, и SEO, и рекламу, и в твиттере пиарить он умеет. И вот такой дизайнер-верстальщик решил, что PHP и Ruby on Rails — вчерашний день, а сегодня он будет делать приложения для Айфона или для Гэлэкси. У него что-то получилось, и он сразу себе это в блог. И качуют эти посты по всему инету.
Есть документация от Apple — глубокая, но неудобная. Есть StackOverflow с ответами 2хгодичной давности, большинство из которых уже неактуальны. Ну и куча мусора в интернете.
Такие люди не станут ее читать, пока сами не столкнутся с такой проблемой.
Для них это сложно. Вот если бы это делал инструмент, они перестали бы быть источником такой проблемы.