Практическая работа №13 Развертывание реализации паттерна Ambassador и сервиса memcache для организации шардированного кэша

Задания для выполнения практической работы.

1. 
   Проверить, являются ли все цифры данного натурального числа различными.
   
2. 
   Дано натуральное число. Можно ли его представить в виде произведения трех последовательных целых чисел.
   
3. 
   Даны два натуральных числа. Выяснить, являются ли они взаимно простыми. Натуральные числа называются взаимно простыми, если наибольший общий делитель этих чисел равен 1.
   
4. 
   Дробь задана двумя натуральными числами - числителем и знаменателем. Выяснить, является ли эта дробь несократимой.
   
5. 
   Проверить, является ли данное натуральное число простым.
   

Практическая работа №17

Выбор подходящего количества терминальных узлов.

Цель работы: Изучение выбора подходящего количества терминальных узлов.
Теоретическая часть.
Может показаться, что в рамках паттерна Scatter/Gather всегда имеет смысл реплицировать вычисления на как можно большее количество узлов. Распараллеливая вычисления, вы сокращаете время обработки конкретного запроса. Увеличение степени распараллеливания несет с собой дополнительные расходы, поэтому для достижения максимальной производительности в распределенной системе чрезвычайно важно правильно выбрать количество терминальных узлов.
Чтобы понять, почему так происходит, следует рассмотреть две вещи. Во-первых, обработка каждого конкретного запроса подразумевает определенные накладные расходы. Требуется время на анализ запроса, на его пересылку по сети и т. д. В общем случае накладные расходы на обработку запроса операционной системой постоянны и сравнительно невелики по отношению ко времени обработки запроса в пользовательском режиме. Соответственно, при оценке производительности реализации паттерна Scatter/Gather ими, как правило, можно пренебречь.

Важно, однако, понимать, что объем накладных расходов в реализации паттерна Scatter/Gather растет с увеличением количества терминальных узлов. Поэтому, несмотря на их небольшой объем, с ростом степени распараллеливания расходы на них со временем могут превысить расходы на реализацию бизнес-логики приложения. А это значит, что рост производительности за счет распараллеливания носит асимптотический характер.

Помимо того что добавление терминальных узлов может и не ускорить обработку запросов, Scatter/Gather-системы также подвержены «эффекту отстающего». Чтобы понять причину этого, важно помнить, что в Scatter/Gather-системе корневой узел сможет отправить ответ конечному пользователю не ранее, чем дождется ответа от всех терминальных узлов. Поскольку необходимо получить данные от всех узлов, общее время обработки запроса определяется временем обработки запроса самым медленным узлом. Попытаемся понять, как это влияет на производительность, и рассмотрим сервис, в котором 99-й процентиль задержки составляет 2 секунды. Это значит, что в среднем один из 100 запросов будет обработан с задержкой 2 секунды и более. Иными словами, обработка запроса займет 2 секунды и более с вероятностью 1 %. На первый взгляд, это совершенно приемлемо, так как только один из 100 запросов будет обрабатываться медленно.
Посмотрим, что произойдет, если распределить запросы на пять терминальных узлов. Вероятность того, что обработка запроса одним из терминальных узлов займет 2 секунды и более, равна 5 % (0,99 × 0,99 × 0,99 × 0,99 × 0,99 = 0,95). А это значит, что 99-й процентиль задержки единичного запроса становится 95-м процентилем задержки всей Scatter/Gather-системы. Дальше — хуже: если распределить нагрузку на 100 терминальных узлов, то общая средняя задержка обработки почти наверняка составит 2 секунды.

«Эффект отстающего» влияет и на доступность системы. Если запрос распределяется на 100 терминальных узлов, а вероятность отказа любого из узлов равна 1 %, то почти наверняка ни один из запросов пользователей не будет успешно обработан.

1 2 3 4 5 6 7 8 9

dependencies { implementation 'androidx.appcompat:appcompat:1.2.0' implementation 'com.google.android.material:material:1.2.1' implementation 'androidx.constraintlayout:constraintlayout:2.0.4' testImplementation 'junit:junit:4.+' androidTestImplementation 'androidx.test.ext:junit:1.1.2' androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0' }

В ее начало добавим строку

1	implementation "androidx.fragment:fragment:1.2.5"

То есть в моем случае получится

1 2 3 4 5 6 7 8 9 10 11

dependencies { implementation "androidx.fragment:fragment:1.2.5" implementation 'androidx.appcompat:appcompat:1.2.0' implementation 'com.google.android.material:material:1.2.1' implementation 'androidx.constraintlayout:constraintlayout:2.0.4' testImplementation 'junit:junit:4.+' androidTestImplementation 'androidx.test.ext:junit:1.1.2' androidTestImplementation 'androidx.test.espresso:espresso-core:3.3.0' }

И затем нажмем на появившуюся ссылку Sync Now.

Фактически фрагмент - это обычный класс Java, который наследуется от класса Fragment. Однако как и класс Activity, фрагмент может использовать xml-файлы layout для определения графического интерфейса. И таким образом, мы можем добавить по отдельности класс Java, который представляет фрагмент, и файл xml для хранения в нем разметки интерфейса, который будет использовать фрагмент.
Класс фрагмента должен наследоваться от класса Fragment.
Чтобы указать, что фрагмент будет использовать определенный xml-файл layout, идентификатор ресурса layout передается в вызов конструктора родительского класса (то есть класса Fragment).
Весь проект будет выглядеть следующим образом: