[prog.flame] И снова gandjustas! :) На это раз про оптимизацию программ и кластеры

Впервые за довольно долгое время заглянул в RSDN-овский форум "Философия программирования". Оказывается, народ еще активно срется на тему C++ vs Managed (JVM, .NET + все остальное). Надо же, ничего не меняется :) Попробовал почитать. Вначале было забавно, немного поностальгировал. Но быстро надоело, появилась досада на бессмысленно убиваемое время. Но тут в списке авторов ответов промелькнуло имя gandjustas... С надеждой щелкнул на первое сообщение начатой им ветки обсуждения и не разочаровался, gandjustas все еще торт!

Кластер нужен как минимум для отказоустойчивости. Надежность в серверных приложениях нужна гораздо больше оптимальности. Дешевле добавить память, диск, процессор, чем оптимизировать программу. Для примера представь что серверу для работы на всю компанию нужно 16гб оперативки. Есть всего восемь. Вариант — оптимизировать приложение, два месяца работы, два месяца исправления багов, при ЗП в 100к — 400к + упущенная выгода + административные расходы. Добавить 8гб памяти — 5к + день работы.

Когда-то, давным-давно, меня просветили, что есть два типа масштабирования приложений:

• вертикальное, когда повышение производительности приложения достигается путем обновления железа: добавление памяти, установка более мощного процессора, более быстрых жестких дисков и т.д.;
• горизонтальное, когда повышение производительности приложение достигается путем добавления новых машин в кластер, на котором развернуто приложение *.

Так вот складывается впечатление, что тов.gandjustas занимается обслуживанием уже написанных кем-то приложений, для которых главным (а может и единственным) способом увеличения производительности является вертикальное масштабирование. И что к разработке действительно масштабируемых серверных приложений он не имеет отношения.

Ну или я уже совсем отстал от жизни и прозевал как момент появления волшебной серебряной пули -- будь то языка, фреймворка или среды разработки, которая волшебным образом обеспечивает масштабирование приложения, да еще и с автоматическим обеспечением отказоустойчивости. А потом пропустил еще и все рекламные материалы и ажиотаж вокруг этого чудесного средства.

Прошу простить мне мой сарказм, но я себе слабо представляю, как можно решать проблемы масштабирования, не занимаясь на этапе проектирования приложения вопросами разделения работы между вычислительными ресурсами и контролем их загруженности. Да и вопросы отказоустойчивости, в зависимости от предметной области, могут требовать выбора тех или иных подходов на самых ранних этапах проектирования, как, например, обеспечение отказоустойчивости платежного приложения, выполняющего списание финансовых средств. И тут уже расчеты будут совсем другие, нежели "5k RUR + день работы" **.

BTW, high performance cluster вовсе не обязательно дает хоть какую-то отказоустойчивость (см. HPC хотя бы в Wikipedia). А high availability cluster вовсе не обязан обеспечивать высокую производительность (см. HA cluster там же). Но это уже совсем-совсем другая тема для разговора, в которой и я сам не чувствую себя достаточно компетентным.

---

* В принципе, для некластерных (например, десктопных) приложений так же может быть возможно горизонтальное масштабирование посредством замены процессора, если новый процессор имеет больше вычислительных ядер и приложение умеет эти ядра загружать, разделяя свою работу между ними. Это относится не только процессору, но и к другим типам ресурсов: жестким дискам, сетевым картам, подключенным к машине внешним устройствам (вроде GSM-модемов, PC/SC-ридеров, HSM-модулей и пр.) Т.е. в более широком смысле горизонтальное масштабирование для приложения -- это умение приложения разделять свою работу между всеми поступающими в его распоряжение ресурсами и, за счет этого, возможность увеличения производительности приложения за счет предоставления ему дополнительных ресурсов.

** Хотя эффективные менеджеры могут все.