Джава-архитекторы убивают маленьких девочек
без джавы.а новая система на java?
а новая система на java?Честно говоря, подтверждений найти не удалось, но у меня нет сомнений. Во-первых, потрачено 100 лимонов - не на похапе же их попилили. Во-вторых, такое говно трудно на чем-то кроме джавы написать.
а новая система на java?Глянул вакансии этой конторы: .NET, C#, плюсы, Windows, вот это всё.
Глянул вакансии этой конторы: .NET, C#, плюсы, Windows, вот это всё.Где смотрел вакансии?
Глянул вакансии этой конторы: .NET, C#, плюсы, Windows, вот это всё.Логично, на джваве не получилось же, теперь срочно ищут других.
У меня не ищется:
вот это всё.http://jobs.climber.com/jobs/industry/USA/JAVA-Developer/208...
JAVA Developer
...
for the next generation web version of our Record Management System (RMS) product suite for the Public Safety industry.
Record Management Systemпоходу дела, оно http://www.intergraph.com/learnmore/sgi/public-safety/police...
Глянул вакансии этой конторы: .NET, C#, плюсы, Windows, вот это всё.Немного не в тему, но по-моему всё дело в том, что кто-то делал сортировки не через SQL.
сраная сшайка катится в сраное говно
пора авлить...
пора авлить...
Глянул вакансии этой конторы: .NET, C#, плюсы, Windows, вот это всё.Ожидаемо. Джавовщина бы пыхтела пердела, но как-то работала бы. А вот простои это признак гениального кода на с++ и бусте, который падает каждые 10 минут.
Азиятов не жалко.
Ожидаемо. Джавовщина бы пыхтела пердела, но как-то работала бы. А вот простои это признак гениального кода на с++ и бусте, который падает каждые 10 минут.Нет, на c++ и бусте сервер бы состоял из процесса-мастера и процессов-воркеров, которые если и падают, то перезапускаются и работают дальше. Джава - большой монолитный кусок, который падает сразу насмерть.
Нет, на c++ и бусте сервер бы состоял из процесса-мастера и процессов-воркеров, которые если и падают, то перезапускаются и работают дальше. Джава - большой монолитный кусок, который падает сразу насмерть.
И только почти все компании почему-то делают распределённые отказоустойчивые приложения на Java...
А эти красавцы использовали BizTalk, как сами признались:
http://www.intergraph.com/assets/pdf/Article1.pdf
а почему на яве нельзя написать мастеров и воркеров?
И только почти все компании почему-то делают распределённые отказоустойчивые приложения на Java...Потому что в свое время IBM взял свое миддлваре, приделал к нему сбоку джаву и забрендировал как JavaEE. Вместо джавы там мог быть похапе или вообще что угодно.
На чистой джаве никто не пишет приложения, которые должны работать 24 на 7 без остановки. Могут быть stateless фронтенды , подключенные к лоад балансеру, но не более.
а почему на яве нельзя написать мастеров и воркеров?Не получится. Минимальное Java приложение, типа сайта, требует десятков мегабайт библиотек, активно генерит байткод и т. д, в результате жрет много памяти. Я работал над приложением, которое требовало полгига под permgen. Умножь это на 20 воркеров, и результат будет печален.
а почему на яве нельзя написать мастеров и воркеров?если воркер - отдельная жвм, то оно очень долго раскочегаривается, ну ещё и память нужно выделять с запасом, и вся она будет использоваться
Oh, shi... Ты воркеров собрался поднимать как отдельные jvm-ки?
если в одной жвм, то оно и упадёт всё сразу
Вместо джавы там мог быть похапе или вообще что угодно.чувак, вместо java там не мог быть похапе, потому что похапе и многопоточность вместе выглядят так: http://govnokod.ru/4096
Ну, тогда с бустом тоже ведь беда. Если на каждый воркер выделать по виртуалкей (на одной машине нельзя, ось упадёт же то тоже 20 запустить не получится.
Если на каждый воркер выделать по виртуалкей (на одной машине нельзя, ось упадёт жеобычно прикладной код пишут менее квалифицированные люди и тестируют меньше (хуяк-хуяк и в продакшн поэтому ось падает редко, как и железо ломается редко, а падает всё вследствие багов прикладного кода или же ошибки оператора
Намёк был на то, что JVM как бы не падает из-за падения одного worker-а.
Намёк был на то, что JVM как бы не падает из-за падения одного worker-а.сама по себе она конечно не упадёт, но память же общая у всех тредов? а так я вкурсе, что воркеры эти - стандартный паттерн
вот и получается, что джава-поделка если падает, то серьёзно
Офигеть, вы тут продолжаете спорить про джаву, хотя несколькими постами выше было сказано, что там использовалось поделие от микрософт!
Не понимаю, при чём тут "общая память", как это связано с падением и почему мешает делать и перезапускать worker-ы?
Не понимаю, при чём тут "общая память", как это связано с падением и почему мешает делать и перезапускать worker-ы?ну типа в объектно-ориентированном коде всё интересное закодировано в состоянии объектов
падает что-то из-за того, что это состояние оказалось непредусмотренным разработчиком
поэтому если упал один тред, то по той же причине может упасть другой
конечно, если воркеры не модифицируют глобальные объекты, то один никогда не унесёт за собой остальное
а также, если писать программы без ошибок, то падать они вообще не будут
Намёк был на то, что JVM как бы не падает из-за падения одного worker-а.У тебя worker насрет в кучу, и все, привет, OutOfMemory. Это может по миллиону причин произойти:
1)Утечка памяти. В джава приложении будет какой-нибудь спринг, бины с singleton скоупом (замаскированные глобальные переменные в общем допустить утечку просто.
2)Чтобы сгенерить отчет, будет высасываться полбазы в сессию хибернейта.
3)Парсинг гигантского xml домом.
PHP живет на шаред говнохостингах, о чем тут говорить.
Если речь об использовании "тяжёлых библиотек", то глобального состояния как правило нет.
Если глобальное состояние нужно, то оно нужно и для отдельных процессов, так что они все так же посыпятся из-за неверного содержимого мемкеша.
Если глобальное состояние нужно, то оно нужно и для отдельных процессов, так что они все так же посыпятся из-за неверного содержимого мемкеша.
У тебя worker насрет в кучу, и все, привет, OutOfMemory.Как страшно жить, это на Си обычно не проверяют результат malloc; для серверных решений на Java это может быть вполне штатной ситуацией.
1)Утечка памяти. В джава приложении будет какой-нибудь спринг, бины с singleton скоупом (замаскированные глобальные переменные в общем допустить утечку просто.А на Си++ сложно что ли?
2)Чтобы сгенерить отчет, будет высасываться полбазы в сессию хибернейта.Язык не спасает от решений с неправильной алгоритмической сложностью и с неправильной сложностью по памяти.
чувак, вместо java там не мог быть похапе, потому что похапе и многопоточность вместе выглядят так: http://govnokod.ru/4096В JavaEE воркеры не работают над общими объектами, все состояние живет в памяти/очереди сообщений, многопоточность там не нужна.
Edit: s#памяти/очереди сообщений#базе/очереди сообщений#
Если речь об использовании "тяжёлых библиотек", то глобального состояния как правило нет.ну обычно кроме библиотек, разработчики дописывают ещё что-то
сама по себе библиотека, наверное, не упадёт (хотя я не спец в джаве, может там конечно из-за этого падает что-то)
а в той модели памяти, которое в джаве, глобальное состояние создать просто - типа операция new и ссылки всем раздать
ничего проще в джаве вроде нет, поэтому, я так мыслю, разработчики так и сделают
если архитектура изначально подразумевает раздельные процессы, то создать глобальный объект тяжелее, и разработчик без этого обойдётся, если есть способ попроще
Как страшно жить, это на Си обычно не проверяют результат malloc; для серверных решений на Java это может быть вполне штатной ситуацией.ну вот исключение придёт не тому, кто вызвал утечку, а тому, кому не повезло
а в той модели памяти, которое в джаве, глобальное состояние создать просто - типа операция new и ссылки всем раздатьТы определись: глобальное состояние нужно или нет? Если нужно, то ничего сложного нет и в залезании в memcache, код для этого не сложнее вызова new.
если архитектура изначально подразумевает раздельные процессы, то создать глобальный объект тяжелее, и разработчик без этого обойдётся, если есть способ попрощеУ тебя какое-то противоречие: глобальный объект проще, но создать его сложнее, и разработчик сделает попроще.
ну вот исключение придёт не тому, кто вызвал утечку, а тому, кому не повезлоИ в чём проблема-то? Многопроцессная архитектура точно так же может выжрать память у ОС, при чём это намного легче сделать, т.к. многие вещи делаются "попроще", как ты упоминал. Так что мы вполне можем поиметь "маленький кэш" в каждом процессе.
я в реальности не испытывал, но теоретическое построение: 4 ява машине на сервере, между ними раскиданы тысячи акторов - кажется довольно устойчивым к случайному убийству исчерпанием памяти: если одна из машин ляжет, остальные три примут себе акторов покойной, пока она не воскреснет. Ну и на большее количество серверов скалируется замечательно
Многопроцессная архитектура точно так же может выжрать память у ОС,есть ограничения на используемую каждым процессом память
есть ограничения на используемую каждым процессом памятьТо есть они будут часто падать, перезапускаться и заново разогревать своё глобальное состояние.
То есть они будут часто падать, перезапускаться и заново разогревать своё глобальное состояние.В оракле и постгресе куча состояния, но все работает.
В оракле и постгресе куча состояния, но все работает.И что? В Java проекте тоже может быть "куча состояния", и всё будет работать.
> На чистой джаве никто не пишет приложения,
> которые должны работать 24 на 7 без остановки.
Разубеждать бессмысленно, я так понимаю.
---
"Narrowness of experience leads to narrowness of imagination."
> которые должны работать 24 на 7 без остановки.
Разубеждать бессмысленно, я так понимаю.
---
"Narrowness of experience leads to narrowness of imagination."
Разубеждать бессмысленно, я так понимаю.Приведи пример.
Например, основной оптимизатор из Cisco WAAS.
---
...Я работаю...
---
...Я работаю...
И что? В Java проекте тоже может быть "куча состояния", и всё будет работать.Ты не можешь убить постгрес кривой хранимой процедурой, или апач кривым пхп скриптом. Адский похапе говнокод работает на шаред говнохостингах без всяких проблем.
Джава сервера падают по OutOfMemory только так, я не понимаю о чем тут спорить.
> Джава сервера падают по OutOfMemory только так
Гон.
---
...Я работаю...
Гон.
---
...Я работаю...
Например, основной оптимизатор из Cisco WAAS.Спасибо за отличный пример
http://www.cisco.com/en/US/docs/app_ntwk_services/waas/waas/...
Software Version 4.1.5g Resolved Caveats
The following caveats were resolved in software version 4.1.5g.
Java heap OutOfMemory errors were observed in WAE rarely under stress
Ты не можешь убить постгрес кривой хранимой процедурой, или апач кривым пхп скриптом.Щито? БД по-твоему обладает какими-то магическими бесконечными ресурсами?
Джава сервера падают по OutOfMemory только так, я не понимаю о чем тут спорить.
Щито? Если ты имел дело только с каким-то криворуким поделием, и оно случайно оказалось на Java, это проблемы именно криворукого поделия, а не Java.
Видишь ли, из-за того, что там ява, а не плюсы, оно выкарабкивается
из таких положений, что плюсовикам такого и не снилось. И это при том,
что код долгое время "правили" индусы, что оставляет неизгладимый отпечаток.
---
...Я работаю...
из таких положений, что плюсовикам такого и не снилось. И это при том,
что код долгое время "правили" индусы, что оставляет неизгладимый отпечаток.
---
...Я работаю...
Щито? БД по-твоему обладает какими-то магическими бесконечными ресурсами?Когда завершается транзакция, то все ресурсы освобождаются, и мусора не остается. Это тебе гарантирует СУБД. В джаве тебе никто не гарантирует, что после работы сервлета у тебя не утекла память.
Щито? Если ты имел дело только с каким-то криворуким поделием, и оно случайно оказалось на Java, это проблемы именно криворукого поделия, а не Java.Аргумент типа "ты быдлокодер, у меня все работает".
Да, я быдлокодер, но PHP у меня по OOM не падает, а джава падает. Если твоя точка зрения в том что джава - для элиты, которая всегда пишет идеальный код, то я с тобой согласен.
Когда завершается транзакция, то все ресурсы освобождаются, и мусора не остается. Это тебе гарантирует СУБД. В джаве тебе никто не гарантирует, что после работы сервлета у тебя не утекла память.Щито? В СУБД тебе тоже никто ничего не гарантирует, и чем дальше ты от простейших SQL запросов, тем хуже.
Да, я быдлокодер, но PHP у меня по OOM не падает, а джава падает. Если твоя точка зрения в том что джава - для элиты, которая всегда пишет идеальный код, то я с тобой согласен.Так это у тебя падает Java? И отсюда ты сделал вывод, что она плохая?
Щито? БД по-твоему обладает какими-то магическими бесконечными ресурсами?Если у тебя упала транзакция от исчерпания ресурсов бд, то у тебя проблема локализована в этой транзакции, и тебе надо только посмотреть, что она делала. В джаве память медленно течет, пока ты не получаешь стогигабайтный хип дамп, с которым ты ничего не можешь сделать.
Если у тебя упала транзакция от исчерпания ресурсов бд, то у тебя проблема локализована в этой транзакции, и тебе надо только посмотреть, что она делала.Щито? Ты хочешь сказать, что ресурсы потребляет только одна транзакция в один момент времени?
В джаве память медленно течет, пока ты не получаешь стогигабайтный хип дамп, с которым ты ничего не можешь сделать.
Щито? В СУБД тебе тоже никто ничего не гарантирует, и чем дальше ты от простейших SQL запросов, тем хуже.Приведи пример, что после завершения транзакции в СУБД остается утекшая память.
Насколько я знаю, в постгресе при начале транзакции выделяется регион памяти, и дальше все аллокации идут внутри региона. При завершении транзакции регион освобождается целиком.
Так это у тебя падает Java? И отсюда ты сделал вывод, что она плохая?
Именно так. Если бы она не падала, то я бы не сделал вывод, что она плохая.
Точнее, я попал на проект, в котором была довольно большая кодовая база на джаве. Сетап был такой: постгрес мастер, постгрес слейв, четыре машины с джавой, подключенных к лоад балансеру. Постгрес работал как часы, каждая машина с джавой падала по OutOfMemory регулярно.
Я работал над приложением, которое требовало полгига под permgen. Умножь это на 20 воркеров, и результат будет печален.10 гиг получил, это что много? У нас старые сервера стоят, там от 64 до 256. И это хлам какой-то, нормальные сервера сейчас с террабайтом идут.
Именно так. Если бы она не падала, то я бы не сделал вывод, что она плохая.Это какая-то детская однобокая логика.
Щито? Ты хочешь сказать, что ресурсы потребляет только одна транзакция в один момент времени?
В джаве память медленно течет, в постгресе каждая транзакция по завершении полностью чистит за собой память. Что непонятно?
Что за бредятина? Щито?Я имею в виду параметр -XX:+HeapDumpOnOutOfMemoryError. Удивлен, что ты про него в первый раз слышишь.
В джаве память медленно течет, в постгресе каждая транзакция по завершении полностью чистит за собой память. Что непонятно?Не понятно, почему "В джаве память медленно течет" и откуда у постгреса бесконечные магические ресурсы.
Не понятно, почему "В джаве память медленно течет"Ты меня удивляешь. В интернете тысячи туториалов по поиску утечек в джава приложениях, например
http://docwiki.cisco.com/wiki/How_to_analyze_heap_dumps
(кстати, забавно, что туториал размещен на сайте cisco, который, как тут утверждали, делает супернадежные джава приложения).
Есть целый подвид джава-архитекторов - консультанты по тюнингу GC и поиску утечек. Память течет, gc начинает подолгу ковыряться в накопленном мусоре. Приглашается джава-архитектор, якобы знающий волшебную комбинацию ключиков JVM, которая все исправит.
но PHP у меня по OOM не падает, а джава падаетЭто такой тонкий троллинг что ли? В ПХП нет разделяемой памяти, как следствие там сложнее её отожрать, но это вовсе не означает, что ты тем самым избавился от всех проблем.
На чистой джаве никто не пишет приложения, которые должны работать 24 на 7 без остановки. Могут быть stateless фронтенды , подключенные к лоад балансеру, но не более.
на Java EE сейчас только говносайты пишут (ну и используют иногда в нормальных проектах понемножку). Чистая Java сейчас достаточно сильно востребована на highload и low latency проектах
Ты меня удивляешь. В интернете тысячи туториалов по поиску утечек в джава приложениях, напримерИ при чём тут Java? В интернете тысячи туториалов по поиску утечек ресурсов везде и во всём, и СУБД не является исключением.
В джаве память медленно течет, в постгресе каждая транзакция по завершении полностью чистит за собой память. Что непонятно?В джаве память не течёт. Вообще не течёт за исключением парочки багов в JVM, которые были давным давно. GC освобождает те ресурсы, которые ты не используешь. То, что увеличивается память в винде - это не следствие того, что течёт, а просто стратегия по оптимальному её использованию, которая используется в Java. Да, Java не отдаёт по умолчанию память системе, но для сервиса это допустимое поведение. (и взамен ты получаешь бенефит в виде не фрагментированной памяти). Свалить Java по OOM можно, но только забивая безконтрольно очереди, не волнуясь о размерах массивов и глобально храня данные, которые не нужны, т.е. так, как и в любом другом языке. Для примера в С достаточно забыть очистить память после выделения для объекта в горячем методе или фрагментировать память и выделить большой массив.
Ты не можешь убить постгрес кривой хранимой процедурой, или апач кривым пхп скриптом
o'rly
Ты не можешь убить постгрес кривой хранимой процедурой, или апач кривым пхп скриптом.кстати вот у меня противоположная проблема
надо убить апачевского воркера из пхп-скрипта, пока не получается
пробовал так:
apache_child_terminate;
и
posix_kill(getmypid SIGTERM);
оба вызова ничего не делают, ну про первый написано на php.net, что оно не работает
У нас старые сервера стоят, там от 64 до 256. И это хлам какой-то, нормальные сервера сейчас с террабайтом идут.прям таки земные байты?
ну не у всех есть безлимитные источники денег, чтоб сервер с 64Г называть хламом
Если нужно, то ничего сложного нет и в залезании в memcache, код для этого не сложнее вызова new.не было опыта с memcache, сейчас посмотрел примерчики
охуеть
как его можно сравнивать с глобальным объектом?
куча различий
1) синтаксис другой (то есть разработчик понимает, что использует сущность другого типа, а не родной объект языка)
2) насколько я понял, в глобальном пространстве живут не объекты, а глупые данные (объекты надо сериализовывать или типа того - а это означает, что нельзя просто вызвать метод по ссылке, который испортит хз что в объектах, с которыми работает другой поток)
3) вообще не гарантируется сохранность того, что туда положили!один - а это значит, что всегда известно, что делать, если достали из кеша что-то не то - то же самое, как если бы ничего не достали - даже не очень интеллектуальному кодеру будет лучше понятно, что делать в странных ситуациях, так как они уже должны быть заложены в архитектуру
У тебя какое-то противоречие: глобальный объект проще, но создать его сложнее, и разработчик сделает попроще.разработчики будут выбирать наиболее простые схемы реализации текущих подзадач из доступных
в модели с единым пространством объектов все объекты по сути глобальные, нужно лишь передать ссылочку кому надо
в модели с различными процессами организация доступа к глобальным данным связан с дополнительными сложностями и ограничениями, и создание именно некоего глобального объекта ничуть не проще альтернатив, типа посылки сообщений, или работы с внешней базой данных
поэтому следует ожидать, что в джава-программах глобальные объекты будут использоваться там, где они не очень нужны, просто потому что это легче всего - что влечёт за собой менее предсказуемое влияние ошибок в одном потоке выполнения на все остальные
попробуй к процессу strace-м подключиться и посмотреть - дергается ли kill
а то может оно через preload подменено - можно тогда попробовать вытащить "настоящую" из соответствующей либы
а то может оно через preload подменено - можно тогда попробовать вытащить "настоящую" из соответствующей либы
на самом деле оказалось, что константа SIGTERM не определена - заменил на 15
на Java EE сейчас только говносайты пишут (ну и используют иногда в нормальных проектах понемножку).По финансовым отчетам IBM, продажи вебсферы демонстрируют стабильный рост:
http://www.ibm.com/annualreport/2012/bin/assets/2012_ibm_ann...
WebSphere revenue increased 7.8 percent (10 percent adjusted
for currency) in 2012, with strong performance throughout the year,
and gained share. Revenue performance included strong growth in
the core offerings of commerce and application servers. Commerce
revenue increased 14 percent (15 percent adjusted for currency) and
application server products increased 6 percent (8 percent adjusted
for currency).
Чистая Java сейчас достаточно сильно востребована на highload и low latency проектахНе мог бы ты привести примеры таких проектов?
Не мог бы ты привести примеры таких проектов?Все медиа сервисы Яндекса: фотки, видео, музыка.
как его можно сравнивать с глобальным объектом?Я выбрал это для примера.
в модели с различными процессами организация доступа к глобальным данным связан с дополнительными сложностями и ограничениями, и создание именно некоего глобального объекта ничуть не проще альтернатив, типа посылки сообщений, или работы с внешней базой данных
Это всё не повышает стабильность проекта. Убить что-то так, чтобы не работала вся система, можно одинаково что в многопоточной, что в многопроцессной архитектуре. Да, убийство глобального объекта и убийство строчки в нужной таблице БД абсолютно равновероятны.
я, кстати, видел 64х гигабайтный хипдамп в исполнение erlang. Хотя казалось бы, поискать более устойчивую среду
Не мог бы ты привести примеры таких проектов?Я знаю один немецкий инвестиционный банк, занимающий 15% мирового рынка валюты. Большая часть стоящих за этим систем, от клиентского API до мат. моделей, написана на Java SE.
ну не у всех есть безлимитные источники денег, чтоб сервер с 64Г называть хламомДавно говорю, джава - это солидный язык для солидных девелОперов.
Не мог бы ты привести примеры таких проектов?трейдинговые системы А, Б, В, Г, которые я видел своими глазами, но о которых не могу рассказывать
; часть систем mail.ru и одноклассников; на hh.ru распределённая умеющая деградировать система на смеси python и Java и т.д.. Проекты с веб сферой же - обычно жутьда, вебсфера - это громоздкая и неповоротливая вещь, к которой, как я слышал, тяготеют РЖД и Сбер
да, вебсфера - это громоздкая и неповоротливая вещь, к которой, как я слышал, тяготеют РЖД и СберИ ещё куча банков из top 100.
> Если ты имел дело только с каким-то криворуким поделием, и оно
> случайно оказалось на Java, это проблемы именно криворукого поделия,
> а не Java.
Я думаю, что переубеждать бесполезно, так как если у человека
нет соответствующего опыта, ему будет трудно поверить, что яве,
умирающей от OutOfMemory, соответствует не "бессмертное" ПО,
а плюсовое поделие, падающее от SIGSEGV значительно раньше.
Дополнительно отмечу, заранее, что я не утверждаю, что на плюсах
нельзя написать лучше. Можно. Но в условиях поголовного индусячества,
включая таковое и у русских программистов, лучше пусть будет ява,
чем кривые кресты.
---
...Я работаю...
> случайно оказалось на Java, это проблемы именно криворукого поделия,
> а не Java.
Я думаю, что переубеждать бесполезно, так как если у человека
нет соответствующего опыта, ему будет трудно поверить, что яве,
умирающей от OutOfMemory, соответствует не "бессмертное" ПО,
а плюсовое поделие, падающее от SIGSEGV значительно раньше.
Дополнительно отмечу, заранее, что я не утверждаю, что на плюсах
нельзя написать лучше. Можно. Но в условиях поголовного индусячества,
включая таковое и у русских программистов, лучше пусть будет ява,
чем кривые кресты.
---
...Я работаю...
> Когда завершается транзакция, то все ресурсы освобождаются,
> и мусора не остается. Это тебе гарантирует СУБД.
А когда транзакция не завершается, то и ресурсы не освобождаются.
Привет! Этого тебе СУБД не гарантирует, даже постгрес.
---
"Narrowness of experience leads to narrowness of imagination."
> и мусора не остается. Это тебе гарантирует СУБД.
А когда транзакция не завершается, то и ресурсы не освобождаются.
Привет! Этого тебе СУБД не гарантирует, даже постгрес.
---
"Narrowness of experience leads to narrowness of imagination."
> кстати, забавно, что туториал размещен на сайте cisco, который,
> как тут утверждали, делает супернадежные джава приложения
Всякие боинги и шанели покупают, не говоря и о более серьёзных
клиентах, производящих оружие, а не какие-то пукалки, чтобы
хомячки могли фотки друг другу посылать. Но не суть.
Дело в том, что если у тебя требуется оптимизировать протокол
передачи данных с довольно сложным состоянием, то тебе понадобится
хранить его пристёгнутым к глобальной переменной. Как ты собираешься
выползать из последствий, я не понимаю. Я представляю, как можно
гарантировать срок жизни объекта, но это всё равно нетривиально,
даже если выбранный тобой язык программирования предоставляет
для этого какие-то средства. Это точно не меняется при замене
явы на питон (ха-ха) или, тем более, на плюсы.
---
"Narrowness of experience leads to narrowness of imagination."
> как тут утверждали, делает супернадежные джава приложения
Всякие боинги и шанели покупают, не говоря и о более серьёзных
клиентах, производящих оружие, а не какие-то пукалки, чтобы
хомячки могли фотки друг другу посылать. Но не суть.
Дело в том, что если у тебя требуется оптимизировать протокол
передачи данных с довольно сложным состоянием, то тебе понадобится
хранить его пристёгнутым к глобальной переменной. Как ты собираешься
выползать из последствий, я не понимаю. Я представляю, как можно
гарантировать срок жизни объекта, но это всё равно нетривиально,
даже если выбранный тобой язык программирования предоставляет
для этого какие-то средства. Это точно не меняется при замене
явы на питон (ха-ха) или, тем более, на плюсы.
---
"Narrowness of experience leads to narrowness of imagination."
Всякие боинги и шанели покупают, не говоря и о более серьёзныхОружие - это распил госбюджета, а работает оно или нет, никто не проверяет (к счастью).
клиентах, производящих оружие, а не какие-то пукалки, чтобы
хомячки могли фотки друг другу посылать.
А вот если сайт для хомячков на полчаса приляжет, визг по всему Интернету.
> работает оно или нет, никто не проверяет (к счастью).
Расскажи про это в соседнем разделе. (С.-А.С.Ш. проверяют.)
---
...Я работаю...
Расскажи про это в соседнем разделе. (С.-А.С.Ш. проверяют.)
---
...Я работаю...
(С.-А.С.Ш. проверяют.)но такого хорошо наблюдаемого фитбека как "визг по всему Интернету" нет.
С.-А.С.Ш. проверяюту них оружия по бумагам хватает убить всех человеков много раз, а они им гоняют тыщу-другую оборванцев по пустыням
с хомячками наоборот: строили сайт, рассчитывая на тысячу, а их прибежало миллион
Ну вот, братцы, мы и пришли к тому, что не только в Роиссе пилят.
трейдинговые системы А, Б, В, Г, которые я видел своими глазами, но о которых не могу рассказыватьЭто для бирж? Насколько мне известно, биржы не работают круглыми сутками. Я даже где-то читал про трейдинговый софт на яве, в котором вообще выключен GC, и памяти хватает на один рабочий день. Таким образом, мой исходный тезис не опровергнут, напомню его:
На чистой джаве никто не пишет приложения, которые должны работать 24 на 7 без остановки. Могут быть stateless фронтенды , подключенные к лоад балансеру, но не более.
часть систем mail.ru и одноклассников
Там джава - именно фронтенд, который делает запрос к базе и генерит хтмл. С этой задачей и пхп отлично справляется.
Кстати, ты в этом треде использовал для описания софта на яве термины
распределённые
отказоустойчивые
highload
low latency
Bullshit bingo!
На чистой джаве никто не пишет приложения, которые должны работать 24 на 7 без остановки.Можешь дать определение такого приложения? Если я раскатываю апдейт по узлам и поочередно завершаю/запускаю мои java-процессы, при этом сервис не прерывается и клиенты этого не замечают, это по твоей терминологии 24 на 7 или нет?
Это для бирж? Насколько мне известно, биржы не работают круглыми сутками. Я даже где-то читал про трейдинговый софт на яве, в котором вообще выключен GC, и памяти хватает на один рабочий день. Таким образом, мой исходный тезис не опровергнут, напомню его:не, я над диcраптором не работал :-).
Я работал над трейдинговыми системами, которые работают 24/7 и перегружаются раз в 2 месяца на релиз и над транспортами, которые перегружаются ещё реже. OOM не было ни разу, паузы gc на пол секунды в день, когда перерыв торгов.
Забей, тут цитата из подписи КОНТРЫ очень в тему была бы:
Narrowness of experience leads to lack of imagination.(или что-то похожее)
В ответ на:Я тут оставлю видео с семинара, куда приходил товарищ из одноклассников рассказывает про то, как они у себя работают с джавой.
часть систем mail.ru и одноклассников
Там джава - именно фронтенд, который делает запрос к базе и генерит хтмл. С этой задачей и пхп отлично справляется.
Кстати, ты в этом треде использовал для описания софта на яве термины
Я работал над трейдинговыми системами, которые работают 24/7 и перегружаются раз в 2 месяца на релиз и над транспортами, которые перегружаются ещё реже. OOM не было ни разу, паузы gc на пол секунды в день, когда перерыв торгов.Спасибо за информацию. Значит, я был не прав.
Я тут оставлю видео с семинара, куда приходил товарищ из одноклассников рассказывает про то, как они у себя работают с джавой.А можно пояснить для нуба, вот рунетовский сайт 5000 серверов, а stackoverflow вроде всего 2 сервера
И что характерно, те и другие используют MS SQL Server в качестве РСУБД. Не иначе как все ява портит.
Не надо было ОК выбрасывать первую версию на ASP .NET, тоже бы наверное на паре pizza boxes до сих пор крутились.
Не надо было ОК выбрасывать первую версию на ASP .NET, тоже бы наверное на паре pizza boxes до сих пор крутились.
конечно, нужно больше инфы, но начало презентации очень смахивает на классику:
Соблазны модели распределенных объектов
Два-три раза в год мне доводится участвовать в одном и том же "шоу". Архитектор очередной объектно-ориентированной системы (допустим, приложения для обработки каких-то заказов) с гордостью выставляет на общее обозрение план распределения объектов (вполне возможно, что эскиз может выглядеть так, как показано на рис. 7.1): каждый программный компонент размещается в отдельном узле системы.
"Зачем все это?" — спрашиваю я.
"Производительность, вестимо, — отвечает архитектор, глядя на меня со слабо скры¬ваемым превосходством. — Мы можем запустить каждый компонент на обработку в сво¬ем собственном блоке. Если мощности блока не хватит, мы запросто добавим еще пароч¬ку, чтобы сбалансировать нагрузку". Теперь он уже и не пытается утаить самолюбования вперемешку с удивлением по поводу того, что я вообще посмел открыть рот.
Между тем передо мной возникает любопытная дилемма: заявить парню все сразу и выставить за дверь либо не торопясь показать ему дорогу к светлому будущему. По¬следнее во всех смыслах выгоднее, но гораздо хлопотнее, поскольку архитектор обычно слишком пленен собственными иллюзиями и вряд ли легко с ними расстанется.
Эта книга (хотелось бы надеяться) поможет вам понять изъяны подобной распреде¬ленной архитектуры. Многие поставщики инструментальных средств программирования не устают твердить: основное достоинство технологий распределения объектов заключается именно в том, что вы можете взять "пригоршню" объектов и разбросать их по узлам сети как вашей душе угодно, а фирменное промежуточное программное обеспечение сделает прозрачными все взаимосвязи. Свойство прозрачности позволяет объектам вызывать друг друга внутри одного процесса, между процессами на одной машине или на разных машинах, не заботясь о местонахождении "собеседников".
Безусловно, все это просто замечательно, но... Хотя многие стороны жизни распреде¬ленных объектов действительно приобретают искомую прозрачность, это явно не отно¬сится к аспектам производительности. Наш герой-архитектор осуществил распределение объектов, как ему казалось, исходя из соображений производительности, но на самом де¬ле выбор подобной структуры наверняка снизит эффективность системы и существенно усложнит процессы ее разработки и практического внедрения.
http://translate.google.com/translate?hl=en&sl=ru&u=...
Не надо путать классическую ситуацию архитектурного астронавта, который последние 5 лет только квадратики рисовал и поэтому первым делом все распределяет по машинам ("сложение мы будем делать на четных узлах, а вычитание на нечетных" с ситуацией, когда данные перестают влезать на один узел, например, и действительно нужно резать обработку запроса на части (а значит нужно собирать результат с нескольких узлов, а значит нужен какой-то remoting). В ОК - вторая ситуация.
Да, но несколько смущает количество этого ремоутинга у них. Он в начале говорит типа у нас получился огромный оверхед на ремоутинге. Типа, если мы оверхед уменьшим, получим ощутимый выигрыш. А меня интересует, почему ремоутинга так много? Есть подозрение, распределение данных по узлам и количество запросов сильно не оптимально, отсюда и получают столько ремоутинга, а потом его героически фиксят. Лечат не то.
Фаулер не ограничивается одним узлом, он дает общее правило — количество ремоутинга надо уменьшать.
с ситуацией, когда данные перестают влезать на один узел,
Фаулер не ограничивается одним узлом, он дает общее правило — количество ремоутинга надо уменьшать.
Оставить комментарий
luna89
В колл-центре 911 Нью-Йорка внедрили новый софт за $100 000 000. Теперь все ужасно тормозит и, когда система уходит в астрал, операторы записывают данные на бумажку. Теперь они работают по 80 часов в день, потому что не успевают быстро забивать данные.
Операторы умоляют мэра Блумберга вернуть старую систему, без джавы.
Иногда звонки вообще не доходят, и в таких случаях умирают люди.
[1]http://www.nydailynews.com/new-york/emails-show-officials-knew-911-system-flaws-article-1.1387685
[2]http://www.firefighterclosecalls.com/news/fullstory/newsid/191850
[3]http://www.nydailynews.com/new-york/nyc-911-operators-call-city-forced-ot-article-1.1393409