32
процессорами будет 1500 операций, а загрузка процессоров составит 5%. В
обработке данной операции задействованы web –сервер, на котором находится
форма для отправки данных, и сервер БД, где происходит запись значений в
таблицу базы данных.
Производительность процессора (количество операций в секунду –
flops) рассчитывается по формуле:
, где
F – тактовая частота процессора,
N – количество ядер процессора,
I – количество обрабатываемых инструкций за такт.
Результаты расчета производительности процессоров этих серверов для
обоих проектов представлена в таблице 2.5.
Таблица 2.5. Производительность web-сервера и сервера БД для проекта 1 и проекта 2
Наименование
Проект 1
Проект 2
Web-сервер
118,4 Гопер/с
217,6 Гопер/с
Сервер баз данных
198,4 Гопер/с
230,4 Гопер/с
Произведем расчеты с указанными параметрами для обоих проектов:
Для проекта 1:
t =
Для проекта 2:
t =
Получаем следующие результаты:
33
Параметр
Проект 1
Проект 2
t
p
2
0,99999999987
0.99999999988
Анализ полученных результатов показывает, что оба проекта удовлетворяют
требованию p
2
>0,999.
Аналогичным образом рассчитаем достоверность для операции
сохранения информации на жесткий диск сервера баз данных.
Для проекта 1:
t =
Для проекта 2:
t =
Повторяем расчеты и получаем следующие результаты:
Параметр
Проект 1
Проект 2
t
p
3
0,99999999932
0.99999999933
На основании полученных результатов можно сделать вывод, что оба
проекта на этом участке модели удовлетворяют требованию p
3
>0,999.
Вычисляем значение общей достоверности информации по каждому из
проектов по формуле:
, как произведение вычисленных выше
значений достоверности для каждого элемента модели достоверности. Для
проекта № 1 это значение составит 0.999723, для проекта №2 - 0.999724.
На основании сделанных расчетов делаем вывод, что оба результата
удовлетворяет требованию P >0,999, т.е. общая достоверность, с учетом
34
введенной схемы дополнительного контроля ошибок при ручном вводе
информации, полностью удовлетворяет техническим требования проекта.
2.5 Расчет задержки передачи данных на основе структурной модели
комплекса технических средств
Необходимо рассчитать задержку передачи запроса пользователя для
получения информации о контенте, а также задержку передачи ответа.
Требования: задержка передачи данных не должна превышать 0,5 с.
Структурная модель расчета времени задержки передачи данных
представлена на рисунке 2.7.
Маршрутизатор Web-сервер Коммутатор
Сервер баз
данных
ЛВС ЛВСЛВС
1
2
3
4 5 6
7
Рис. 2.7. Структурная модель расчета времени задержки передачи данных
В приложении 2 приведены исходные, на основании которых будут
сделаны расчеты задержки времени при передаче данных внутри комплекса
технических средств.
При расчете будем полагать, что система обрабатывает только один
запрос, чтобы не брать в расчет потери времени на очереди, возникающие при
одновременной обработке нескольких запросов в многопользовательских
системах.
Общее время задержки вычисляется по формуле:
????
????
????
????
, где
t
прд
(запрос) – время передачи запроса к серверу баз данных;
t
srv
– время обработки запроса сервером и формирование ответа;
t
прд
(ответ) – время передачи ответа (для всего количества записей на один
запрос);
Для проекта № 1:
35
Тпрд (запрос) =
Tsrv =
Тпрд (ответ) =
Значит, суммарная задержка для проекта № 1 составляет:
T = 0.250375407 < 0,5 (что меньше требуемого параметра 0,5 сек)
Для проекта № 2:
Тпрд (запрос) =
Tsrv =
Тпрд (ответ) =
Значит, суммарная задержка для проекта №2 составляет:
T = 0.2499099105 < 0,5 (что меньше требуемого параметра 0,5 сек)
Анализируя полученные результаты, можно сделать вывод, что
параметры задержки КТС при обработке пользовательского запроса у обоих
проектов меньше необходимого 0,5 сек, что соответствует техническим
требованиям проекта.
36
Полученная оценка является оптимистической. Она не учитывает время
распространения сигнала в среде передачи, задержки ЛВС на доступ к среде
передачи, блокировки при многопользовательском режиме доступа к среде
передачи и базе данных. Однако позволяет понять порядок величины
задержки.
В заключении второй главы, подведем предварительные итоги и
сделаем выводы о проделанной работы.
Для поиска оптимального проекта было выполнено сравнение
предложенных вариантов по нескольким критичным техническим параметрам
- это надежность КТС, достоверность вносимой информации и задержка
передачи данных.
Лучшим по техническим характеристикам оказался второй вариант,
который изначально, без дополнительных доработок, соответствовал
техническим требованиям, изначально предъявляемым к проекту.
37
ГЛАВА III
РАЗРАБОТКА ПРОГРАММНЫХ СРЕДСТВ ИНФОРМАЦИОННОЙ
СИСТЕМЫ ДИСТРИБУЦИИ КОНТЕНТА
3.1 Разработка структуры приложения
Разработка программного продукта будет проводиться в текстовом
редакторе с подсветкой синтаксиса Notepad++ [23].
Для доступа к базе данных и отладки запросов будет использовано
приложение HeidiSQL[22].
Обе программы являются бесплатными, свободно распространяемые
разработчиками с открытым исходным кодом, свободные от каких либо
лицензионных требований.
Запуск и отладка скриптов до установки на рабочий сервер будет
производиться на портативной серверной платформе Open Server Panel[24],
которое устанавливается на ПК разработчика под управлением ОС Windows,
и включает в себя сборки разных версий СУБД MariaDB, HTTP сервера Apache
и PHP с отладчиком Xdebug.
Основываясь на схеме работы сайта, представляемой заказчиком,
разработана структурная схема приложения, представленная на рисунке 3.1.
Главная страница
Поиск контента
Оформление заявки
на сотрудничество
Редактирование
информации о
контенте
Авторизация
Страница доступа к
контенту
Контакты
Добавление клиента
Редактирование
информации о
клиенте
Страница доступа к
контенту
Рис 3.1. Структурная схема сайта
38
Сайт состоит из девяти страниц, каждая из которых, за исключением
страниц для авторизованных пользователей, имеет сквозные ссылки на все
остальные.
Для сохранения информации о пользователях, правах доступа и
размещаемом контенте в информационной системе предполагается
использовать базу данных.
Доступ на запись и изменение информации в ее таблицах
предполагается из специальных форм на сайте, доступ к которым требует
авторизации.
База данных разработана посредством теории нормализации,
представляющей собой последовательное изменение структуры таблиц до тех
пор, пока каждое отношение не будет удовлетворять требованиям последней
нормальной форме (которая определяется с учетом конкретных требований).
Структура таблиц базы данных, в которых будет храниться
информация, представлена в приложении 3.
Логическая модель базы данных изображена на рисунке 3.2.
Рис. 3.2. Логическая модель базы данных
Для удобства хранения информации и оптимизации доступа все
используемые в таблицах данные были разделены на 7 таблиц.
39
В целях оптимизации и увеличения доступа, информация об авторе была
разнесена на 2 таблицы Author и AuthorDesc, чтобы убрать редко
используемую информацию с описанием в AuthorDesc, тем самым облегчить
основную, часто используемую в запросах таблицу Author. Аналогично
поступили с таблицами Janr и Tip_Janr.
3.2 Разработка интерфейса приложения
В процессе разработки были созданы динамически генерируемые веб-
формы, информационное наполнение которых осуществляется посредством
запроса информации из базы данных. Некоторые формы представляют собой
интерфейс доступа к базе данных, и позволяют авторизованным
пользователям вносить в нее изменения.
На всех страницах присутствует навигационное меню, позволяющее
перемещаться между страницами по ссылкам.
Описания основных страниц сайта:
Страницы, доступные всем пользователям:
Главное меню:
На данной странице находится приветственное окно, а также
список недавно добавленных клиентов-держателей контента. По кнопке
«подробнее» осуществляется переход на страницу подробного описания
автора с доступом к его контенту. Главная (домашняя страница)
представлена ниже, на рис. 3.3.
Рис. 3.3. Страница главной страницы сайта.
40
Поиск:
Эта страница содержит форму поиска и позволяет осуществлять
поиск авторов по заданным критериям (фильтрам). Активация процесса
поиска введенных в форму данных происходит при нажатии кнопки
«поиск».
Данные, введенные в поля этой формы, посредством запроса к базе
данных сверяются со строками таблицы Контент (ContentElement) и, если есть
совпадения, показываются в поле «результаты поиска» в виде списка.
Из этого списка можно перейти на страницу просмотра контента автора
после нажатия копки «подробнее». Страница поиска представлена ниже, на
рисунке 3.4.
Рис. 3.4. Страница поиска.
Страница обратной связи:
Данная страница предназначена для оформления заявки клиентом-
держателем на распространение контента, и является одним из основных
вариантов, предназначенных для связи с сотрудниками компании.
Заполненные поля данной страницы после обработки скриптом
сохраняются в базе данных. Эта информация будет доступна для
41
использования сотрудником компании-агрегатора при рассмотрении заявки и
создании учетной записи для нового клиента.
Страница связи показана ниже, на рисунке 3.5.
Рис. 3.5. Страница связи.
Страница контактов:
Страница контактов содержит информацию о контактах компании-
агрегатора. Данная страница исключительно информативная. Страница
контактов представлена ниже, на рисунке 3.6.
Рис. 3.6. Страница контактов.