Это продвигается как решение проблем сложных приложений, когда сложно понять что и где меняется. Я сейчас делаю проект в такой архитектуре для расширения кругозора. Сейчас вокруг этого подхода очень много эйфории. Правы-ли апологеты подхода покажет время.
Любой UI — это функция текущего состояния, разве нет?
С большой натяжкой. В реакте это более строго. Любой реакт компонент содержит два метода: setState и render. Сам компонент и является той функцией состояния.
В других фреймворках возможно двунаправленное движение состояния: компоненты меняют модель. В реакте движение данных из компонента в модель исключено.
Согласен. По наблюдениям на PhoneGap основные тормоза не от JavaScript, а от медленной отрисовки браузером. В профайлере практически не видно js, одна отрисовка. Тормоза от JavaScript есть только на старте, если js очень много. У нас его уже несколько мегабайт и на Андроид его загрузка занимает несколько секунд.
Соответственно сравнивать просто с системой виртуализации не совсем корректно.
Соглашусь, что написал не строго. Могу предложить сравнить производительность на своей машине. Приведу пример: у меня есть MacBook Pro с 16 Гб памяти. На нем стоит Mac OS и Windows 10 в отдельном разделе. Загружаемся в Windows, производим сборку проекта приложения в IDE, перезагружаемся под мак, стартуем Windows через Parallels, повторяем эксперимент. Сравниваем результаты.
Проверим как работает гипервизор на Windows. Запускаем виртуальную машину через Hyper-V и повторяем эксперимент. Если ваш компьютер не поддерживает Hyper-V, можно заглянуть на Azure и сравнить ихнюю виртуалку с таким же компьютером. Банальный пример: взять старый компьютер с 1-ядерным процессором и 4Гб памяти и сравнить с базовой виртуалкой на Azure с теми же характеристиками. На Azure разница заметна даже по времени старта приложения Server Manager, а разница во времени установки программ кратная.
Все эти эксперименты ненаучные, но позволяют с потребительской точки зрения оценить на сколько виртуалка медленнее.
Также в стоимость следует включить: систему резервирование на случай выхода из строя сервера, резервирование каналов связи и многое другое
Прошу прощения, что был не точен. Я предлагаю взять в аренду 4 железных сервера: два под базу данных, два под сервер приложения. При этом резервирование каналов входит в стоимость, а резервом на случай отказа сервера является его пара.
Предлагаю сравнить стоимость владения классическими и виртуальными серверами. Например, возьмем HP Blade 2xXeon 2Ghz, 8Gb RAM. Стоимость такого сервера примерно 5000 рублей в месяц. Аналогичный виртуальный сервер стоит 5900 рублей. Стоимсть комплекта 4 железных серверов на 1 месяц: 20 тысяч против 24 тысяч за виртуальные сервера. Стоимость бекапа не включена, стоимость трафика включена.
Виртуальные сервера выигрывают по скорости начала работы и удобству настройки. Что-то пошло не так, снёс виртуалку и создал новую. Это занимает считанные минуты. Но по эффективности "операций на рубль" они проигрывают традиционным серверам. Просто потому, что на железном сервере все ресурсы ваши на 100%, а на виртуальном сервере вы их делите с соседями, а часть ресурсов тратится на работу системы виртуализации. Это касается и процессора и дисковой подсистемы.
Поставщики виртуальных серверов заявляют, что их продукт позволяет подстраивать траты под нагрузку. Если у вас много трафика, вы наращиваете мощность, если мало, откатываетесь на базовый план. При этом некоторые провайдеры (например, DO) лукавят. Они дают возможность увеличивать размер виртуалки, но уменьшить её размер не возможно. Если вам больше не нужна большая виртуалка, вы должны создать новую маленьку и перенести данные на неё. Действительная возможность изменять размер виртуальных машин в обе стороны есть только у AWS, Azure и Jelastic. Если у вас она тоже есть, поправьте меня, пожалуйста.
В ваших рассчитах та-же ошибка, что и в статье Джонатана Куми: не учитывается оверхед виртуализации. С одной стороны приложение на виртуальном сервере работает медленнее. С другой стороны хостеру необходимо выделять ресурсы на более дорогую систему хранения данных, чтобы виртуальные машины клиентов быстрее очнулись при падении железа. Все это включается в стоимость и фактическая стоимость операции вычисления и операции ввода-вывода намного выше, чем на железе взятом в аренду. Получается дешевле арендовать 4 живых сервера, чем 4 виртуальных той же производительности (именно производительности, а не заявленных параметров).
Я думаю, что отчасти поэтому набирает популярность докер: он даёт возможность изолировано запускать приложения на своих серверах.
Я уже пробовал решить проблему через Риту, которая вас представляет на RSDN. Она помогла получить первый ответ. Дальше опять тишина. Когда уже приперло, решил задачу иначе, не через Пейонир.
Ваша проблема не в том, что мало функционала, а в том, что у вас перестала работать служба поддержки. Возникла проблема и я не могу её решить: первого ответа ждал месяц. Уточнил. Прошло полгода — ответа нет. Писал несколько раз, в том числе в личку вашему представителю. «Да, да завтра ответим» — никакого ответа. Я бы пользовался вами, но не получается.
Алексей, спасибо за ответ. Хотелось бы, чтобы вы также прокомментировали недостатки тестов на производительность, которые указали Роман и Алексей (zBit)
Денис, спасибо за комментарий. Можете дать ссылку на описание алгоритмов масок или просто название этого класса алгоритмов? Они почему-то совсем мимо меня прошли.
Может измениться. Например, из-за особенностей запуска тестов организаторам и, выиграли те, кто имел все объявления методом внутри функции filter. Сыграло роль как сработал компилятор и рантайм v8. Между 4.2 и 5.0 он может сильно различаться.
Второе письмо об оценке производительности:
After looking at your performance testing code I have to say it is
flawed so much that the final rankings do not make any sense at all.
Particularly this code is the culprit:
vm.runInContext(id + '.res = ' + expr + '(' + id + '.messages, ' + id +
'.rules)',
Attached is my original submission that originally ranked quite badly
(27th place). As you can see, I did not change my algorithm one bit, all
I have done is simply moved all the function declarations inside the
exported filter function. If you run your original test.js benchmark,
you will see that in this form, my code now performs 5 times faster and
easily beats the original top performers!
Please, please, please, consider rerunning the original submissions
using a direct invocation of modules' filter functions:
require('./app.js').filter(messages, rules)
instead of using runInContext, as it is in no way correlated with the
real world performance of submitted algorithms.
Один из участников конкурса не имеет доступа к хабру и попросил меня опубликовать его письмо организаторам. В кратце: код проверки решения сам содержит ошибки. Привожу его письмо целиком.
First of all, let me congratulate you on the contest, it was extremely
well organized. This is the first time I have participated in a
programming challenge or used NodeJS, but even so I can see the level of
effort and experience that went into organizing the event.
At the same time, after reviewing your testing code, I would like to
point out that the correctness tests you have used are a bit naive. As a
result, the competition rankings as it stands now are incorrect.
I did not check all the submissions, but after looking at several of the
top performers, I was able to quickly find out that the following two do
not pass correctness tests corresponding to the contest rules:
4. fb5813a09c0f95242cb
6. Petr Shalkov
I think it is fair to expect many more submissions to have incorrectly
implemented algorithms. So, understanding that an incorrect algorithm
can perform much faster that a properly working one, I would ask you to
reevaluate the final rankings. For your convenience I am attaching the
correctness test suite I have used myself (the tests assume that the
module being tested is located in an 'app.js' file). These are the tests
that can be found at 'https://github.com/ToPal/HolaTests' along with my
own modifications.
I would also like to thank you for giving all of us the opportunity to
participate in this event, and push many of us to finally get or hands
wet with NodeJS. A big thank you!
> В первом столбце показано количество посетителей, во втором – количество загрузок, в третьем – процент загрузок от общего числа посетителей. Наглядно видно, что с незначительным отрывом побеждает вариант В.
Это продвигается как решение проблем сложных приложений, когда сложно понять что и где меняется. Я сейчас делаю проект в такой архитектуре для расширения кругозора. Сейчас вокруг этого подхода очень много эйфории. Правы-ли апологеты подхода покажет время.
С большой натяжкой. В реакте это более строго. Любой реакт компонент содержит два метода: setState и render. Сам компонент и является той функцией состояния.
В других фреймворках возможно двунаправленное движение состояния: компоненты меняют модель. В реакте движение данных из компонента в модель исключено.
Согласен. По наблюдениям на PhoneGap основные тормоза не от JavaScript, а от медленной отрисовки браузером. В профайлере практически не видно js, одна отрисовка. Тормоза от JavaScript есть только на старте, если js очень много. У нас его уже несколько мегабайт и на Андроид его загрузка занимает несколько секунд.
Соглашусь, что написал не строго. Могу предложить сравнить производительность на своей машине. Приведу пример: у меня есть MacBook Pro с 16 Гб памяти. На нем стоит Mac OS и Windows 10 в отдельном разделе. Загружаемся в Windows, производим сборку проекта приложения в IDE, перезагружаемся под мак, стартуем Windows через Parallels, повторяем эксперимент. Сравниваем результаты.
Проверим как работает гипервизор на Windows. Запускаем виртуальную машину через Hyper-V и повторяем эксперимент. Если ваш компьютер не поддерживает Hyper-V, можно заглянуть на Azure и сравнить ихнюю виртуалку с таким же компьютером. Банальный пример: взять старый компьютер с 1-ядерным процессором и 4Гб памяти и сравнить с базовой виртуалкой на Azure с теми же характеристиками. На Azure разница заметна даже по времени старта приложения Server Manager, а разница во времени установки программ кратная.
Все эти эксперименты ненаучные, но позволяют с потребительской точки зрения оценить на сколько виртуалка медленнее.
Прошу прощения, что был не точен. Я предлагаю взять в аренду 4 железных сервера: два под базу данных, два под сервер приложения. При этом резервирование каналов входит в стоимость, а резервом на случай отказа сервера является его пара.
Предлагаю сравнить стоимость владения классическими и виртуальными серверами. Например, возьмем HP Blade 2xXeon 2Ghz, 8Gb RAM. Стоимость такого сервера примерно 5000 рублей в месяц. Аналогичный виртуальный сервер стоит 5900 рублей. Стоимсть комплекта 4 железных серверов на 1 месяц: 20 тысяч против 24 тысяч за виртуальные сервера. Стоимость бекапа не включена, стоимость трафика включена.
Виртуальные сервера выигрывают по скорости начала работы и удобству настройки. Что-то пошло не так, снёс виртуалку и создал новую. Это занимает считанные минуты. Но по эффективности "операций на рубль" они проигрывают традиционным серверам. Просто потому, что на железном сервере все ресурсы ваши на 100%, а на виртуальном сервере вы их делите с соседями, а часть ресурсов тратится на работу системы виртуализации. Это касается и процессора и дисковой подсистемы.
Поставщики виртуальных серверов заявляют, что их продукт позволяет подстраивать траты под нагрузку. Если у вас много трафика, вы наращиваете мощность, если мало, откатываетесь на базовый план. При этом некоторые провайдеры (например, DO) лукавят. Они дают возможность увеличивать размер виртуалки, но уменьшить её размер не возможно. Если вам больше не нужна большая виртуалка, вы должны создать новую маленьку и перенести данные на неё. Действительная возможность изменять размер виртуальных машин в обе стороны есть только у AWS, Azure и Jelastic. Если у вас она тоже есть, поправьте меня, пожалуйста.
Я думаю, что отчасти поэтому набирает популярность докер: он даёт возможность изолировано запускать приложения на своих серверах.
After looking at your performance testing code I have to say it is
flawed so much that the final rankings do not make any sense at all.
Particularly this code is the culprit:
vm.runInContext(id + '.res = ' + expr + '(' + id + '.messages, ' + id +
'.rules)',
Attached is my original submission that originally ranked quite badly
(27th place). As you can see, I did not change my algorithm one bit, all
I have done is simply moved all the function declarations inside the
exported filter function. If you run your original test.js benchmark,
you will see that in this form, my code now performs 5 times faster and
easily beats the original top performers!
Please, please, please, consider rerunning the original submissions
using a direct invocation of modules' filter functions:
require('./app.js').filter(messages, rules)
instead of using runInContext, as it is in no way correlated with the
real world performance of submitted algorithms.
Thanks,
Roman Pletnev
First of all, let me congratulate you on the contest, it was extremely
well organized. This is the first time I have participated in a
programming challenge or used NodeJS, but even so I can see the level of
effort and experience that went into organizing the event.
At the same time, after reviewing your testing code, I would like to
point out that the correctness tests you have used are a bit naive. As a
result, the competition rankings as it stands now are incorrect.
I did not check all the submissions, but after looking at several of the
top performers, I was able to quickly find out that the following two do
not pass correctness tests corresponding to the contest rules:
4. fb5813a09c0f95242cb
6. Petr Shalkov
I think it is fair to expect many more submissions to have incorrectly
implemented algorithms. So, understanding that an incorrect algorithm
can perform much faster that a properly working one, I would ask you to
reevaluate the final rankings. For your convenience I am attaching the
correctness test suite I have used myself (the tests assume that the
module being tested is located in an 'app.js' file). These are the tests
that can be found at 'https://github.com/ToPal/HolaTests' along with my
own modifications.
I would also like to thank you for giving all of us the opportunity to
participate in this event, and push many of us to finally get or hands
wet with NodeJS. A big thank you!
Thanks,
Roman Pletnev
Результат А/Б статистически незначим. Вторая страница может быть на 20% хуже, чем оригинал.
www.thumbtack.com/labs/abba/#Control=67%2C522&Variation=66%2C474&abba%3AintervalConfidenceLevel=0.95&abba%3AuseMultipleTestCorrection=true
Разработчики сидят на Ubuntu, пишут на Java в Eclipse: https://developer.salesforce.com/blogs/engineering/2014/07/open-source-at-salesforce-com.html
Работает все это на серверах с Linux.
Без открытого ПО, Salesforce был-бы совсем другой.