Информатика и выч. техника \ Системное программное обеспечение

Разработка клиент-серверного приложения. Алгоритм круговой интерполяции. Реализация алгоритма интерполяции в виде клиент-серверного приложения, страница 5

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


Интерполяция занимает совсем незначительное время, клиентам даже не нужно ждать в очереди. Хотя разница во времени запуска клиентов всего несколько миллисекунд.

            3.2. Исследование сетевого варианта.

Исследование сетевого варианта приложения с помощью системного профайлинга имеет некоторые сложности поскольку из одной IDE нельзя синхронно запустить профайлинг одновременно на двух целевых системах.

Поэтому эксперимент был поставлен следующим образом:

·  Для сервера и клиента Kernel Trace запускались отдельно.

·  По логу сервера анализировалось время выполнения интерполяции;

·  По логу клиента анализировалось время реакции;

·  Время затрачиваемое на обмен между клиентом и сервером оценивалось по разнице между временем реакции и временем, затрачиваемым на интерполяцию.

В программе клиента были выделен участок с передачей сообщения серверу, чтобы потом можно было легко найти его на Timeline-диаграмме.

usleep(50000);

if (MsgSend( connect_id, &msgSend, sizeof(msgSend), &msgReply, sizeof(msgReply) ) != -1) {

usleep(50000);

cout << "Send is OK!" << endl;

}

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

Timeline-диаграммы клиента и сервера.



           

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

Интерполяция второй дуги.

Timeline-диаграмма и Trace Log клиента.



Timeline-диаграмма и Trace Log сервера.



Временные характеристики:

Выполнение интерполяции

1.350 ms

Время реакции.

Время между вызовами MsgSendEnter() и MsgSendExit()

8.196 ms

Интерполяции третей дуги.

Timeline-диаграмма и Trace Log клиента.



Timeline-диаграмма и Trace Log сервера.



Временные характеристики:

Выполнение интерполяции

1.533 ms

Время реакции.

Время между вызовами MsgSendEnter() и MsgSendExit()

10.313 ms

Если сравнивать сетевой вариант с локальным, то по логу видно, что при сетевом варианте передачи сообщений используется специальный менеджер io-pkt-v4-hc.

Сервер переходит в состояние Vstopped и ожидает ответа от процесса 98319. Если посмотреть, что это за процесс с помощью pidin -p  98319, то результат будет -  io-pkt-v4-hc.

После начала отправки ответа клиенту, сервер сам довольно длительное время ожидает ответа от сетевого  менеджера io-pkt-v4-hc и находиться в Reply-блокированном состоянии, на Timeline-диаграммах сервера этому соответствует длинная синяя полоса.

Разница во времени реакции между локальным и сетевым вариантом получается следующая — при сетевом варианте приложения время реакции в 7-8 раз больше, чем в локальном.

            4. Исследование приложения с помощью прикладного профайлинга.

Прикладной профайлинг (Application Profiling) в IDE Momentics есть нескольких типов.

1.  Sampling and Call Count instrumentation profiling — статистический профайлинг.

·  с определенным интервалом делаются снимки состояния программы и по этой выборке строиться отчет сколько времени выполняются определенные участки кода;

·  можно построить иерархический граф вызовов функций с подсчетом количества вызовов каждой функции (Call Count). Для этого исполняемый файл должен быть собран с опцией -p (и для компилятора и для линкера).

Скачать файл