Системы самопроверки

Question

У меня была идея, которую я обдумывал с некоторыми коллегами. Никто из нас не знал, существует ли он в настоящее время.

Основная предпосылка заключается в том, чтобы иметь систему, которая имеет 100% времени безотказной работы, но может стать более эффективной динамически.

Вот сценарий:

* Таким образом, мы быстро хэшируем систему указанный набор интерфейсов, он имеет нулевых оптимизаций, но мы уверен, что это на 100% стабильно хотя (сомнительно, но ради этот сценарий, пожалуйста, играйте вместе)

* Затем мы профиль оригинальные классы, и начать замены программы для узкие места.

* Оригинал и замена инициируются одновременно и синхронизируется.

* Оригиналу разрешено работать до завершения: если замена не завершено, вето системы в качестве замены для оригинал.

* Замена всегда должна возвращать то же значение, что и оригинал, для указанное количество раз, и для конкретный диапазон значений, прежде чем это принят в качестве замены для оригинал.

* Если исключение происходит после принятия замены, система автоматически пробует ту же операцию с классом, который был заменен это.

Вы видели подобную концепцию на практике? Критика Пожалуйста ...

Ниже приведены комментарии, написанные после первого вопроса относительно Сообщения:

* Система демонстрирует дарвиновский подход к эволюции системы.

* Оригинал и замена будут работать параллельно, а не последовательно.

* Гоночные условия являются неотъемлемой проблемой для многопоточных приложений, и я признать их.

Answer 1

Я считаю эту идею интересной теоретической дискуссией, но не очень практичной по следующим причинам:

1. Чтобы убедиться, что новая версия кода работает хорошо, вам необходимо иметь превосходные автоматические тесты, что является целью, которую очень трудно достичь, и которую многие компании не могут разработать. Вы можете приступить к внедрению системы только после проведения таких автоматических тестов.
2. Весь смысл этой системы в настройке производительности, то есть - конкретная версия кода заменяется версией, которая превосходит его по производительности. Для большинства приложений сегодня производительность имеет второстепенное значение. Это означает, что общая производительность большинства приложений является адекватной - просто подумайте об этом, вы, вероятно, редко жалуетесь на то, что «это приложение мучительно медленное», вместо этого вы обычно жалуетесь на отсутствие конкретной функции, проблемы со стабильностью, проблемы пользовательского интерфейса и т. Д. Даже если вы жалуетесь на медлительность, это обычно общая медлительность вашей системы, а не только конкретных приложений (конечно, есть исключения).
3. Для приложений или модулей, где производительность является большой проблемой, способ их улучшения обычно заключается в выявлении узких мест, написании новой версии и тестировании, в первую очередь, независимо от системы, с использованием некоторого сравнительного анализа. Конечно, может понадобиться сравнительный анализ новой версии всего приложения, но в целом я думаю, что этот процесс будет проходить очень небольшое количество раз (следуя правилу 20% -80%). Выполнение этого процесса «вручную» в этих случаях, вероятно, проще и экономичнее, чем описанная система.
4. Что происходит, когда вы добавляете функции, исправляете ошибки, не связанные с производительностью и т. Д.? Вы не получаете никакой выгоды от системы.
5. Запуск двух версий вместе для сравнения их производительности имеет гораздо больше проблем, чем вы думаете - не только у вас могут быть условия гонки, но если входные данные не являются подходящим тестом, вы можете получить неправильный результат (например, если вы получить множество небольших пакетов данных, и это составляет 90% времени, когда на вход поступают большие пакеты данных). Более того, это может быть просто невозможно (например, если реальный код изменяет данные, вы не можете запускать их вместе).

Единственная «среда», где это звучит полезно и фактически «обязательно», - это «генетическая» система, которая сама генерирует новые версии кода, но это совсем другая история и не очень широко применима ...

Answer 2

Я думаю, что Inversion of Control Container, такой как OSGi или Spring, может сделать большую часть того, о чем вы говорите. (динамическая загрузка по имени)

Вы могли бы строить поверх их вещей. Затем внедрите свой код в

1. разделить рабочие единицы на отдельные модули / классы (шаблон стратегии) ​​
2. идентифицировать каждый модуль по уникальному имени и связать с ним возможность
3. когда запрашивается модуль, он запрашивается по возможности, и случайным образом используется один из модулей с такой возможностью.
4. сохранить статистику производительности (получить системный тик до и после выполнения и сохранить результат)
5. если возникает исключение, пометьте этот модуль как неиспользуемый и зарегистрируйте исключение.

Если модули выполняют свою работу путем передачи сообщений, вы можете сохранить сообщение до успешного завершения операции и повторить его с другим модулем в случае возникновения исключения.

Answer 3

Видел ли я похожую концепцию на практике? Но я все равно предложу подход.

Похоже, что большинство ваших целей будет достигнуто некой системой управления суперисточниками, которая может быть реализована с помощью CruiseControl .

CruiseControl может запускать юнит-тесты для проверки правильности новой версии.

Вам нужно написать плагин CruiseControl , который будет выполнять новую версию вашей системы в сравнении с рядом существующих тестов, чтобы гарантировать, что новая версия будет улучшением.

Если цикл сборки CruiseControl пройдет, новая версия будет принята. Такой процесс потребовал бы значительных усилий для реализации, но я думаю, что это осуществимо. Модульные тесты и бенчмаркинг должен быть довольно приятным.

Answer 4

Система, которая запускает тесты производительности во время работы, будет работать медленнее, чем система, которая этого не делает. Если цель состоит в том, чтобы оптимизировать скорость, почему бы вам не провести сравнительный анализ и не импортировать самые быстрые процедуры, если они доказали, что они быстрее?

И ваша идея запуска подпрограмм одновременно может ввести условия гонки .

Кроме того, если целью является обеспечение 100% безотказной работы, вы не захотите вводить непроверенные процедуры, поскольку они могут генерировать неуловимые исключения.

Возможно, ваши идеи имеют смысл в качестве инструмента для сравнительного анализа, а не операционной системы?

Answer 5

Для идей дизайна для систем высокой доступности, проверьте Erlang.

Answer 6

Я не думаю, что код научится быть лучше сам по себе. Тем не менее, некоторые параметры времени выполнения могут легко настраиваться на оптимальные значения, но это будет обычное программирование, верно?

Об изменениях «на лету» я поделился этим удивлением и собираюсь строить его поверх Lua или аналогичного динамического языка. Можно иметь части, которые загружаются, и, если они заменяются, загружаются повторно. В этом нет и ракетостроения. Если «старый код» все еще работает, он в полном порядке, так как в отличие от DLL, файл необходим только при чтении, а не при выполнении кода, который пришел оттуда.

Полезность? Naa ...