Все это уже не раз обсуждалось и разжевывалось, зачем еще раз? JS не так сильно отличается от других языков, для которых уже сотни статей было. Да и для js было сотня статей уже.
ps: Мне кажется, Вы нарушаете авторское право, публикуя ссылку пиратскую копию книги Р. Мартина.
Я понимаю, что плевать хотелось, но все же, не нужно так.
Похоже, для начала стоит определить термин «свободная технология», чтобы дальше можно было хоть что-то говорить. А то GNU/Linux тоже можно назвать не свободной технологией.
OpenJDK — распространяется под лицензией GPLv2 (есть нюансы, но большая часть под этой лицензией). С одной стороны это свободная лицензия, с другой — нет.
Java — свободная технология, более того, исходники (OpenJDK) доступны для скачивания.
А вот Oracle JDK — это микс из свободной java и проприетарных разработок Oracle, таких как Mission Control и прочих, для включения которых необходимо прописать флаг: -XX:+UnlockCommercialFeatures, который как бы намекает, что будет использоваться проприетарные фичи, за которые нужно платить.
К тому же Oracle JDK выставляет счет за embedded устройства с java на борту (по большей части — это мобильные и смартфоны, но есть и GPS и многие другие), вот из-за этого то и судились Оракл с Гуглом, в теории, за каждый девайс с Android можно было бы получить минимум по 200$, согласитесь — неплохая такая сумма была бы.
Вброс, что Oracle закручивает гайки я видел, но это на 99% вброс с испорченным телефоном. Какой-то крупной компании выставили счет за то, что она нарушила лицензионное соглашение, а эта компания прикинулась дураком, мол скачалось бесплатно — значит оно бесплатно! А дальше подхватили малообразованные люди или просто хейтеры и начали распространять, будто Oracle будет выставлять счета вообще всем. Бред :)
Вот половина СНГ использует ворованную лицензию Windows уже лет 20 как и ворованные лицензии фотошопов. Но к ним не приходят потому, что с них взять нечего, а если бы это была большая компания с именем и большим оборотом денег — к ним бы пришли за тем, чтобы вернуть украденное.
А что с java не так? Чем Oracle давит конкурентов java | jvm?
Или Вы про Dalvik VM, которая позиционируется как jvm и собирает сливки популярности java, но при этом не является полноценной jvm? Так это путь, по которому когда-то M$ со своей java реализацией шли, java, которая работала бы только в экосистеме windows, а тут java, которая работает только в экосистеме Android.
По-моему, это довольно правильный ход, мешать развиваться продуктам, которые ради маркетинга называют себя jvm. Программы написанные под jvm должны иметь возможность запускаться на любой реализации. И если Oracle будет позволять всем подряд называть себя jvm, то от этой платформы очень быстро ничего не останется. Одни выпустят jvm только под виндовс, другие — только под андроид, и в итоге получим какой-то .NET в плане кросплатформенности.
Это, скорее всего, основная причина столь столь низких показателей связки apache+php.
Тул для нагрузочного тестирования (далее просто Тул) создает множество потоков для эмуляции независимых пользователей. При количестве потоков более 200, большая часть ресурсов идет на обеспечение работы Тула. Планировщик потоков в ОС начинает сходить с ума.
Добавим к этому тот факт, что и у apache, и у php-fpm есть свои пулы потоков, по 1 потоку на каждого клиента. В результате вся нагрузка приходится на планировщик потоков.
В этой ситуации nodejs, у которого всего несколько потоков, будет показывать результаты лучше только потому, что во всей системе стало примерно в 3 раза меньше активных потоков.
И тут дело не в том, что nodejs крутая, тут дело в том, что сам эксперимент не является чистым; работа тестирующего тула вносит большую нелинейную погрешность в обоих случаях.
К тому же сам код для эксперимента был подобран не лучшим образом. В обоих случаях отдается статика, которая вообще никакой нагрузки не несет.
Учитывая эти факты, весь эксперимент замеряет ничто иное как работу планировщика потоков, при этом все потоки гоняются в холостую (ни один поток не выполняет полезной работы).
Тут и без замеров будет ясно, что nodejs будет показывать ошеломительные результаты.
К слову, если взять nginx и через него отдавать эту статику из кеша, результат будет еще лучше, чем у nodejs.
Читая статью у меня сложилось мнение, что Вы пытаетесь показать, что PHP — отстой, а NodeJS — это то, что следует использовать. Особенно учитывая то сравнение, где NodeJs невероятным образом рвет PHP по производительности.
К слову о тесте, у меня есть ощущение, что тестируется какая-то фигня, просто не верится, что разница на столько велика. А описания что делает тест (что замеряет и как с примерами исходников) Вы не предоставили. Просто красивые графики с потолка.
ps: если вы в тесет отдавали статику (что-угодно без CPU вычислений), то тест вообще ни о чем не говорит.
В конкретно этом коде проблем быть не должно, но в целом, это может породить гонку выполнения! (особенно на запросах к серверу) и соответственно вылиться в эпический факап. Но кого это волнует?!
Спасибо за пример кода, это, наверно, первый адекватный пример, который я увидел, где использование async/await действительно упрощает понимание кода.
Обычно приводят тривиальные и глупые примеры, которые даже под разряд callback hell не подходят.
Почему в качестве решения люди предлагают использовать сторонние библиотеки, и даже хотят вводить async/await, которые по факту не решают проблему, а лишь маскируют ее?
Разве не легче просто писать хороший код, который будет сам за себя говорить, что он делает?
fetch(“list_of_urls”, _loadAllFetchedUrls);
function _loadAllFetchedUrls(array_of_urls) {
for(var i=0; array_of_urls.length; i++) {
fetch(array_of_urls[i], _loadProfileImage);
}
}
function _loadProfileImage(profile){
fetch(profile.imageUrl, _showProfileImage);
}
В данном случае все функции будут поддаваться оптимизации со стороны js движка, не будет генерироваться лишний мусор, сам код становится читабельным — имя функции сразу говорит, что будет сделано после загрузки.
Есть недостаток в том, что всю цепочку не видно, но это еще ни разу не было критичной проблемой, при этом любая более-менее хорошая IDE покажет всю цепочку вызовов до конкретного callback'а.
По-моему такой подход решает проблему «callback hell» без каких-либо сторонних библиотек и без нововведений на уровне языка (async/await).
Я, конечно, могу ошибаться и если это так, буду рад услышать в чем именно я ошибся.
Микросервисы — они не про чистоту кода и простоту поддержки, они про автоматизированное/автоматическое горизонтальное масштабирование и повышение доступности (availability) системы.
Микросервисы подымают ошибки на новый уровень — на интеграционный. То, что раньше было проблемой в «монолите» на стыке абстракций, теперь находится на стыке абстракций в двух или более микросервисах, которые могут поддерживаться разными командами (код везде идеальный, а интеграция будет содержать не тривиальную ошибку).
Перед выбором микросервисов стоит четко понимать цели, сложности и возможные последствия этого выбора.
Если нужно сделать что-то хорошее и производительное — это «монолит».
Если нужно сделать что-то сложное, но масштабируемое — это микросервисы.
ps: Судя по прикрепленным изображениям Вы заменили спагетти-код на спагетти-микросервисы.
Так много пафоса, так много красивых слов, а по сути — это просто еще одно бинарное ин-мемори хранилище для метаданных (небольшого объема) с дополнительным функционалом. Зато хайпа будет хоть отбавляй.
И если география в школе не врала, то испаряемая вода образует облака, т.е. месяц безоблачно над океаном просто быть не может.
Да и в целом вы путаете техногенные и природные процессы.
Логично, что тело будет рассеиваться и казалось бы, ничего страшного не будет.
С другой стороны: несколько гектаров океанического дна будет активно подогреваться серверами, что радикально изменит экосистему в регионе ДЦ. Что из этого будет? Черт его знает. Но еще ничего хорошего для природы от вмешательства человека еще не было.
Принципиальной пользы для человечества (в отличии от добычи ископаемых и вырубки лесов) нету, ДЦ можно строить и на суше, а тепловую энергию переиспользовать. А вот на дне океана — это просто для уменьшения затрат и большей прибыли. Не хорошо это.
Мне интересно за что минусы? Мое сообщение было по теме и это не был троллинг.
Датацентры на суше производят огромное количество тепла. Вот только если на суше эту тепловую энергию используют для обогрева и т.д., то в на дне океана вся эта тепловая энергия будет уходить на подогрев океана.
Один небольшой ДЦ без проблем сможет подогреть близлежащие воды на пару градусов.
Тогда странно, почему в заголовке и во всей статье говорится «Tor — не безопасен!», а вот про то, что Firefox — небезопасен, как-то говорится вскользь и только в одном абзаце. И не дают рекомендации отключать js в Firefox.
Не хотят подмочить репутацию Firefox в то время, когда Tor — не жалко?
Другой способ есть и он очень даже элегантный — «Пишите код!».
Пишите код:
1. Начинайте решать какую-то задачу.
2. Напишите дополнение для своей задачи.
3. Приведите сложившуюся архитектуру в порядок.
4. Добавьте еще функционал, который ломает вашу стройную архитектуру.
5. goto 3.
ps: Мне кажется, Вы нарушаете авторское право, публикуя ссылку пиратскую копию книги Р. Мартина.
Я понимаю, что плевать хотелось, но все же, не нужно так.
OpenJDK — распространяется под лицензией GPLv2 (есть нюансы, но большая часть под этой лицензией). С одной стороны это свободная лицензия, с другой — нет.
А вот Oracle JDK — это микс из свободной java и проприетарных разработок Oracle, таких как Mission Control и прочих, для включения которых необходимо прописать флаг: -XX:+UnlockCommercialFeatures, который как бы намекает, что будет использоваться проприетарные фичи, за которые нужно платить.
К тому же Oracle JDK выставляет счет за embedded устройства с java на борту (по большей части — это мобильные и смартфоны, но есть и GPS и многие другие), вот из-за этого то и судились Оракл с Гуглом, в теории, за каждый девайс с Android можно было бы получить минимум по 200$, согласитесь — неплохая такая сумма была бы.
Вброс, что Oracle закручивает гайки я видел, но это на 99% вброс с испорченным телефоном. Какой-то крупной компании выставили счет за то, что она нарушила лицензионное соглашение, а эта компания прикинулась дураком, мол скачалось бесплатно — значит оно бесплатно! А дальше подхватили малообразованные люди или просто хейтеры и начали распространять, будто Oracle будет выставлять счета вообще всем. Бред :)
Вот половина СНГ использует ворованную лицензию Windows уже лет 20 как и ворованные лицензии фотошопов. Но к ним не приходят потому, что с них взять нечего, а если бы это была большая компания с именем и большим оборотом денег — к ним бы пришли за тем, чтобы вернуть украденное.
Или Вы про Dalvik VM, которая позиционируется как jvm и собирает сливки популярности java, но при этом не является полноценной jvm? Так это путь, по которому когда-то M$ со своей java реализацией шли, java, которая работала бы только в экосистеме windows, а тут java, которая работает только в экосистеме Android.
По-моему, это довольно правильный ход, мешать развиваться продуктам, которые ради маркетинга называют себя jvm. Программы написанные под jvm должны иметь возможность запускаться на любой реализации. И если Oracle будет позволять всем подряд называть себя jvm, то от этой платформы очень быстро ничего не останется. Одни выпустят jvm только под виндовс, другие — только под андроид, и в итоге получим какой-то .NET в плане кросплатформенности.
Тул для нагрузочного тестирования (далее просто Тул) создает множество потоков для эмуляции независимых пользователей. При количестве потоков более 200, большая часть ресурсов идет на обеспечение работы Тула. Планировщик потоков в ОС начинает сходить с ума.
Добавим к этому тот факт, что и у apache, и у php-fpm есть свои пулы потоков, по 1 потоку на каждого клиента. В результате вся нагрузка приходится на планировщик потоков.
В этой ситуации nodejs, у которого всего несколько потоков, будет показывать результаты лучше только потому, что во всей системе стало примерно в 3 раза меньше активных потоков.
И тут дело не в том, что nodejs крутая, тут дело в том, что сам эксперимент не является чистым; работа тестирующего тула вносит большую нелинейную погрешность в обоих случаях.
К тому же сам код для эксперимента был подобран не лучшим образом. В обоих случаях отдается статика, которая вообще никакой нагрузки не несет.
Учитывая эти факты, весь эксперимент замеряет ничто иное как работу планировщика потоков, при этом все потоки гоняются в холостую (ни один поток не выполняет полезной работы).
Тут и без замеров будет ясно, что nodejs будет показывать ошеломительные результаты.
К слову, если взять nginx и через него отдавать эту статику из кеша, результат будет еще лучше, чем у nodejs.
К слову о тесте, у меня есть ощущение, что тестируется какая-то фигня, просто не верится, что разница на столько велика. А описания что делает тест (что замеряет и как с примерами исходников) Вы не предоставили. Просто красивые графики с потолка.
ps: если вы в тесет отдавали статику (что-угодно без CPU вычислений), то тест вообще ни о чем не говорит.
Если так, зачем Вы тогда сравнивали PHP и NodeJs?
асинхроннобесконтрольно:— порядок выполнения случайный.
В конкретно этом коде проблем быть не должно, но в целом, это может породить гонку выполнения! (особенно на запросах к серверу) и соответственно вылиться в эпический факап. Но кого это волнует?!
Обычно приводят тривиальные и глупые примеры, которые даже под разряд callback hell не подходят.
Почему в качестве решения люди предлагают использовать сторонние библиотеки, и даже хотят вводить async/await, которые по факту не решают проблему, а лишь маскируют ее?
Разве не легче просто писать хороший код, который будет сам за себя говорить, что он делает?
В данном случае все функции будут поддаваться оптимизации со стороны js движка, не будет генерироваться лишний мусор, сам код становится читабельным — имя функции сразу говорит, что будет сделано после загрузки.
Есть недостаток в том, что всю цепочку не видно, но это еще ни разу не было критичной проблемой, при этом любая более-менее хорошая IDE покажет всю цепочку вызовов до конкретного callback'а.
По-моему такой подход решает проблему «callback hell» без каких-либо сторонних библиотек и без нововведений на уровне языка (async/await).
Я, конечно, могу ошибаться и если это так, буду рад услышать в чем именно я ошибся.
Значит я не правильно трактовал сравнение со спагетти кодом. В моем понимании, запутанный код ≠ чистый код.
Микросервисы подымают ошибки на новый уровень — на интеграционный. То, что раньше было проблемой в «монолите» на стыке абстракций, теперь находится на стыке абстракций в двух или более микросервисах, которые могут поддерживаться разными командами (код везде идеальный, а интеграция будет содержать не тривиальную ошибку).
Перед выбором микросервисов стоит четко понимать цели, сложности и возможные последствия этого выбора.
Если нужно сделать что-то хорошее и производительное — это «монолит».
Если нужно сделать что-то сложное, но масштабируемое — это микросервисы.
ps: Судя по прикрепленным изображениям Вы заменили спагетти-код на спагетти-микросервисы.
Да и в целом вы путаете техногенные и природные процессы.
Логично, что тело будет рассеиваться и казалось бы, ничего страшного не будет.
С другой стороны: несколько гектаров океанического дна будет активно подогреваться серверами, что радикально изменит экосистему в регионе ДЦ. Что из этого будет? Черт его знает. Но еще ничего хорошего для природы от вмешательства человека еще не было.
Принципиальной пользы для человечества (в отличии от добычи ископаемых и вырубки лесов) нету, ДЦ можно строить и на суше, а тепловую энергию переиспользовать. А вот на дне океана — это просто для уменьшения затрат и большей прибыли. Не хорошо это.
Датацентры на суше производят огромное количество тепла. Вот только если на суше эту тепловую энергию используют для обогрева и т.д., то в на дне океана вся эта тепловая энергия будет уходить на подогрев океана.
Один небольшой ДЦ без проблем сможет подогреть близлежащие воды на пару градусов.
или просто: Давайте подогреем океан!
Не хотят подмочить репутацию Firefox в то время, когда Tor — не жалко?
Если это парсер Firefox, то и в браузере Firefox есть проблема? Или на этот счет не известно ничего?