Огляд існуючих розробок веб-сервісів ведення спортивної статистики і програмного забезпечення прийому замовлень для служб таксі
Вступ
Основним двигуном
прогресу в розвитку web-технологій є проекти, орієнтовані на багатомільйонну
аудиторію і здатні витримувати високе навантаження на ресурси (більше 1000
запитів за секунду). По-перше, для реалізації подібних проектів необхідно максимально
ефективно оптимізувати програмний код, по-друге, - використовувати потужну
апаратуру.
На поточному етапі
розвитку IT-технологій спостерігається тенденція завоювання міцних позицій
смартфонами. Основними їх перевагами є зручність, наявність ряду вбудованих
функцій (GPS-навігація, акселерометр, гіроскоп, мобільний зв'язок, фото- і
відео-камера та ін.), а також те, що вони здатні виконувати більшість функцій
стаціонарних комп'ютерів і ноутбуків. З кожним днем все більше людей
відкривають для себе переваги смартфонів, тому багато високонавантажених
Інтернет-сервісів зараз працюють в зв'язці з мобільними пристроями.
У магістерській роботі
розробляється проект ведення спортивної статистики, першим компонентом якого є
додаток для смартфонів сімейства iPhone, основною функцією якого є збір
статистики, другим - веб-сервер, який синхронізується з додатком і видає дані
на сайт.
Другим проектом є
система прийому замовлень для служб таксі, яка передбачає високе навантаження
на сервер і забезпечує збір необхідних статистичних даних.
Наукова новизна. Запропоновані організація системного програмного забезпечення,
що виконує автоматичний підрахунок виконаних фізичних вправ (підтягувань,
віджимань і т. п.), і створення спеціальної соціальної мережі із специфічним
набором функцій, орієнтованих на ведення спортивної статистики. Запропонована
система прийому замовлень для служб таксі і збору специфічних у цій галузі
даних.
Мета магістерської
роботи. Розробка
універсального алгоритму і програмного забезпечення для автоматичного
підрахунку фізичних вправ і ведення спортивної статистики, створення
відповідної соціальної мережі, здатної витримувати високі навантаження на
ресурси (більше 1000 запитів за секунду). Розробка веб-сервісу прийому
замовлень для служб таксі.
Виходячи з мети були
поставлені наступні задачі:
- дослідження
вбудованого акселерометра, розробка алгоритму автоматичного підрахунку фізичнх
вправ і його практична реалізація у вигляді програмного продукту для смартфонів
сімейства iPhone;
налаштування сервера,
здатного витримувати високі навантаження на ресурси (більше 1000 запитів в
секунду), розробка API для взаємодії з додатком для смартфону і створення
соціальної мережі з необхідним набором функцій;
поширення програмного
продукту і тестування його роботи і роботи сервера на реальній аудиторії з
високим навантаженням на ресурси;
дослідження принципу
роботи існуючих служб таксі і аналіз можливості прискорення і автоматизації
процесу замовлення і пошуку вільної машини і розробка відповідного веб-сервісу
прийому замовлень.
Реалізація і
упровадження результатів роботи. Під
час науково-дослідної практики був укладений договір з компанією Apple Inc. на
отримання права розробляти і розміщувати додатки в офіційному магазині.
Розроблений проект SportDiary був розміщений в App Store у вересні 2012 року.
Апробація роботи: основні наукові результати роботи доповідались на
науково-технічній конференції «Информационные управляющие системы и
компьютерный мониторинг» (Донецьк, ДонНТУ - 2012), та багаторазово на
спеціалізованих семінарах.
Структура і об'єм
магістерської роботи:
Робота складається зі
вступу, 5 глав, виводу, переліку посилань (15 найменувань), містить 100
сторінок тексту, 50 рисунків, 3 таблиці і 2 доповнення.
У першому розділі приводиться огляд аналогічних розробок додатків збору спортивної
статистики для мобільних пристроїв і огляд аналогічних проектів по прийому
замовлень для служб таксі.
У другому розділі розробляється загальна структура проекту ведення спортивної
статистики. Приводиться дослідження вбудованого в мобільний пристрій
акселерометра і розробка алгоритму автоматичного підрахунку виконаних фізичних
вправ. Описана розробка кінцевої версії мобільного додатку і використаних
технологій.
У третьому розділі приводиться розробка специфічної соціальної мережі, призначеної
для користувачів мобільного додатка SportDiary. Проведений огляд використаних
технологій і налаштування сервера. Описаний процес забезпечення взаємодії
соціальної мережі з мобільним застосуванням. Проведено розміщення проекту у
відкритому доступі і його тестування на реальних користувачах.
У четвертому розділі описана розробка демонстраційної версії веб-сервісу прийому
замовлень для служб таксі на базі технологій, використаних для розробки
соціальної мережі.
У п'ятому розділі приведені основні положення охорони праці, проведений розрахунок
кондиціонування, освітлення і шуму в приміщенні.
1. Огляд існуючих
розробок веб-сервісів ведення спортивної статистики і програмного забезпечення
прийому замовлень для служб таксі
акселерометр програмний
сервер смартфон
Аналогічні проекти по
веденню спортивної статистики можна розділити на 3 категорії:
1) додатки, які
орієнтовані тільки на ведення статистики і планування режиму тренувань;
2) додатки, які
орієнтовані на ведення статистики з дистанційних вправ (біг, їзда на велосипеді
і т. п.) з використанням вбудованого GPS-навігатору;
) додатки, які
орієнтовані на ведення статистики з силових вправ (віджимання, підтягування і
т. п.) з використанням вбудованого акселерометра, гіроскопа і відео-камери.
Оскільки у рамках
магістерської роботи додаток розробляється для смартфонів сімейства iPhone,
аналіз існуючих проектів проводиться серед аналогічних пристроїв.
Додатки, орієнтовані
тільки на ведення статистики і планування режиму тренувань передбачають
можливість введення даних тільки вручну для будь-яких типів вправ. В основному
подібні проекти розраховані на аудиторію людей, які займаються в тренажерному
залі. У таких додатках не передбачений автоматичний підрахунок повторень і не
використовуються вбудовані акселерометр, гіроскоп, GPS-навигатор і камера.
Додатки, орієнтовані на
ведення статистики з дистанційних вправ, використовують вбудований
GPS-навігатор (рідше акселерометр), за допомогою якого здійснюється збір
необхідних даних (швидкість, пройдена відстань, географічні координати і т.д.).
На основі отриманих даних будується певна статистика.
Одним з найбільш відомих
і багатофункціональних проектів є додаток «Endomondo Sports Tracker». Основними
його функціями є:
- зображення пройденого маршруту на карті;
- реєстрація і збереження різних статистичних даних (пройдена
дистанція, час, швидкість, втрачені калорії і т. п.). Більшість даних
збираються за допомогою вбудованого в iPhone акселерометра;
- синхронізація даних з сервером;
- публікація даних в соціальній мережі.
У проект «Endomondo
Sports Tracker» також входить соціальна мережа, в якій кожен користувач може
ділитися своїми маршрутами і статистичними даними з іншими користувачами.
Інтерфейс програми, на
якому зображений приклад пройденого маршруту і зібраних статистичних даних,
приведений на рисунку 1.1.
Рисунок 1.1 - Інтерфейс
додатка «Endomondo Sports Tracker» з приведеною статистикою
Додатки, орієнтовані на
ведення статистики силових вправ найбільш близькі за змістом до проекту, що
розроблюється в магістерській роботі. Для підрахунку повторень в них
використовуються можливості вбудованого акселерометра, рідше - відеокамери.
Недоліком подібних застосувань є те, що статистику можливо вести тільки для
фіксованого набору вправ. Додавати свої вправи не можна.
Одним з перших і
найбільш успішних застосувань, в яких використовується автоматичний підрахунок
фізичних вправ, є додаток «Push-ups».
Принцип його роботи
полягає в тому, що реєстрація кожного нового повторення здійснюється за допомогою
вбудованої передньої відео-камери. Людина повинна покласти телефон на підлогу,
і віджиматися, ледве торкаючись телефону грудьми. Камера фіксує затемнення
екрану і рахує їх за повторення. Цей додаток розрахований на ведення
статистики, але не включає вбудовану соціальну мережу. Істотним недоліком
додатка є те, що він розрахований тільки на підрахунок віджимань з причини
специфіки алгоритму. Інтерфейс додатка, на якому зображена зібрана статистика з
віджимань, приведений на рисунку 1.2.
Вбудований в iPhone
акселерометр використовувався для підрахунку фізичних вправ в додатку «FitFu»
(на момент оформлення магістерської роботи додаток був видалений з продажу). У
цьому проекті використовувалася власна соціальна мережа, в якій користувачі
могли публікувати свої досягнення. Проте істотним недоліком додатка є те, що
він реалізований у вигляді гри, і не передбачає ведення статистики і додавання
власних вправ. Автоматичний підрахунок може виконуватися тільки для фіксованої
кількості вправ, серед яких немає багатьох базових і найбільш популярних.
Існує безліч програмних
продуктів з прийому замовлень і збору статистичних даних для служб таксі.
Більшість з цих проектів комерційні і закриті.
Рисунок 1.2 - Інтерфейс додатка
«Push-ups» з приведеною статистикою
У рамках магістерської
роботи пропонується усі проекти з прийому замовлень для служб таксі
класифікувати за наступними критеріями:
- по наявності підтримки функцій GPS:
а) з підтримкою функцій
GPS. У таких проектах робиться замовлення через сайт або мобільний додаток за
допомогою мітки на карті і пошук вільних машин, які відмічені на карті;
б) без підтримки функцій
GPS. У таких проектах замовлення робиться по телефону або за допомогою
SMS-сообщения і пошук таксистів - без задіювання відповідних API;
- по організації роботи:
а) повністю
автоматизовані. Замовлення і пошук машини ведеться автоматично, без участі
роботи диспетчера;
б) напівавтоматизовані.
Частина роботи покладається на диспетчера (наприклад, прийом замовлення по
телефону), частина роботи виконується автоматично (наприклад, пошук вільної
машини);
- за способом вибору вільної машини:
а) з використанням
черги. Вибирається перша машина в черзі, в якій відзначаються таксисти;
б) з використанням
пошуку найближчої машини. Вибирається машина, яка знаходиться в даний момент
щонайближче до адреси, на яку робився виклик;
в) по вибору клієнта.
Клієнт сам вибирає найбільш зручну йому машину з усіх можливих, які відмічені
на карті.
Одним з аналогічних
проектів є місцеве таксі міста Донецьк. Принцип його роботи полягає в
наступному. Клієнт робить дзвінок диспетчерові. Замовлення може робитися тільки
по телефону. Диспетчер отримує адресу, на яку треба послати машину і вводить цю
адресу в базу поточних замовлень. Диспетчери діляться на дві категорії:
) диспетчери, які
спілкуються з клієнтами і приймають замовлення;
) диспетчери, які
спілкуються з таксистами і беруть участь в розподілі замовлень.
На локальному сервері
знаходиться система обробки замовлень, яка розподіляє замовлення між
таксистами. Якщо на замовлення, що поступило, немає жодного вільного таксиста,
диспетчер просить клієнта почекати, поки з'явиться вільна машина. Якщо в
потрібному районі є вільний таксист, замовлення відправляється йому.
Для кращої організації
розподілу замовлень існує черга таксистів. Нове замовлення, що поступило,
вирушає першій в цій черзі машині. Кожному таксистові видається мобільний
Java-додаток, за допомогою якого він може відзначатися в черзі і отримувати
повідомлення про замовлення, що поступили.
Диспетчери, які працюють
з таксистами, спілкуються з ними по рації, контролюють порядок роботи і
допомагають в екстрених ситуаціях.
Недоліком цієї схеми
роботи прийому замовлень полягає в наступному:
не оптимальна витрата
бензину (на замовлення часто прибуває вільний таксист, який знаходиться не
щонайближче до необхідної адреси);
часто виникають
ситуації, коли пошук вільної машини затягується більш ніж на 1 хвилину;
в пікові моменти завантаження
служби таксі часто виникають ситуації перевантаження лінії зв'язку і пропуску
дзвінків.
Другим аналогічним
проектом є «Яндекс Таксі». Користуватися послугами «Яндекс Таксі» можна як
через браузер, так і через мобільні додатки для смартфонів iPhone і Android. На
момент написання магістерської роботи сервіс працював тільки в Москві.
Принцип роботи «Яндекс
Таксі» полягає в тому, що система сама підбирає вільний автомобіль який
знаходиться щонайближче до клієнта. Для замовлення машини необхідно вказати
адресу, на яку викликається машина, і пункт призначення, а також час, коли
повинне прибути таксі. Клієнт отримує інформацію про те, скільки приблизно
триватиме поїздка з урахуванням пробок. Також можна вказати особливі вимоги до
автомобіля (кондиціонер, салон для некурящих або курящих і т. п.). Клієнт
бачить на карті усі вільні на даний момент таксі в режимі реального часу.
Клієнтові надається
інформація про викликаний автомобіль: служба таксі і її рейтинг, тариф, дані
про водія, номер його телефону, колір і марка автомобіля, а також його номер.
Для підтвердження виклику необхідно ввести номер свого мобільного телефону або
зайти в Яндекс під своїм акаунтом. Під час виклику на карті можна спостерігати
рух таксиста в режимі реального часу.
швидкий підбір ближчої
машини;
можливість клієнта
самостійно вибирати характеристики автомобіля;
здатність системи
витримувати високе навантаження на ресурси;
економія коштів на
послугах диспетчера і купівлі додаткового обладнання (рацій).
На даний момент існує
тенденція переходу на автоматизовані системи прийому замовлень.
2. Розробка структури
проекту ведення спортивної статистики і оффлайн-версії мобільного додатку для
IPhone
.1 Розробка загальної структури
проекту ведення спортивної статистики
Проект SportDiary
включає мобільний додаток для смартфонів iPhone, який працює в зв'язці із
спеціально розробленою соціальною мережею. Узагальнена схема роботи проекту
SportDiary зображена на рисунку 2.1.
Мобільне застосування
виконує наступні функції:
) автоматичний
підрахунок кількості повторень виконаної фізичної вправи за допомогою
вбудованого в мобільний пристрій акселерометра;
) ведення статистики по
кожній вправі (зібрані дані по вправах зберігаються в локальну базу даних і
видаються користувачеві у вигляді графіку);
) редагування статистики
вручну;
) видалення і додавання
будь-яких вправ;
) зберігання базових
персональних даних користувача (логін і пароль для входу в соціальну мережу,
ім'я, фото);
) синхронізація даних з
сервером за наявності Інтернету;
) перегляд даних
будь-якого користувача соціальної мережі за наявності Інтернету;
) пошук по користувачах;
) можливість підписки на
користувача.
Соціальна мережа
sportdiary.net виконує наступні функції:
) перегляд даних,
синхронізованих з мобільним додатком, перегляд статистики по кожній вправі;
) пошук користувачів;
) перегляд даних
будь-якого користувача;
) коментування вправ
користувачів.
Структура проекту
SportDiary приведена на рисунку.
Структура проекту
SportDiary
Проект розрахований
тільки на користувачів смартфонів iPhone, починаючи з 4 серії. Мобільний
додаток SportDiary розрахований на аудиторію, яка займається фитнесом і виконує
стандартні фізичні вправи. Автоматичний підрахунок повторень виконаної фізичної
вправи робиться за допомогою вбудованого в мобільний пристрій акселерометра.
Отримані дані
зберігаються в локальну базу даних SQLite. Статистика по кожній вправі може
бути виведена на дисплей смартфону.
При підключенні iPhone
до інтернету оновлені дані з локальної бази даних синхронізуються з сервером і
записуються в базу даних SQL на сервері.
На сервері зберігаються
усі необхідні документи, скрипти і бази даних, які забезпечують функціонування спеціально
розробленої соціальної мережі, яка орієнтована на ведення спортивної
статистики.
Доступ до соціальної
мережі можна отримати як з мобільного застосування, так і безпосередньо на
веб-сайті www.sportdiary.net. В соціальній мережі можна проглянути дані
будь-якого користувача: фотографію, ім'я, усі вправи, статистику по кожній
вправі.
2.2 Дослідження
вбудованого в мобільний пристрій акселерометра і розробка алгоритму
автоматичного підрахунку виконаних фізичних вправ
Серед усіх існуючих
мобільних пристроїв смартфони iPhone можна віднести до одних з самих
вдосконалених. Вбудовані в iPhone акселерометр і гіроскоп відкривають широкі
можливості у використанні функцій руху і обертання смартфону.
У рамках магістерської
роботи було поставлено завдання розробити універсальний алгоритм для підрахунку
фізичних вправ за допомогою вбудованого в мобільний пристрій акселерометра. Під
універсальністю мається на увазі те, що один і той же алгоритм виконуватиме
підрахунок усіх підтримуваних фізичних вправ (підтягувань, віджимань,
скручувань, присідань, віджимань на брусах) і різних варіацій цих вправ
(підтягувань різними хватами, тих же самих вправ з додаванням ваги і т. п.).
Кожна з вище вказаних
вправ не передбачає ніяких обертань тіла, тому для розробки алгоритму не
використовується гіроскоп, а використовується тільки акселерометр.
Принцип дії
акселерометра полягає в тому, що при будь-якому русі смартфону реєструються
відповідні прискорення по трьом осях X, Y, Z [4].
На рисунку зображено,
яка вісь відповідає певній орієнтації смартфону в просторі і рух в якому
напрямі відповідає руху в позитивну або негативну піввісь. У цьому полягає
спрощений принцип дії акселерометра.
За початкове прискорення
по певній осі, якщо та знаходиться перпендикулярно опорі, прийнято прискорення
g = 9.81 м/с2.
Спрощений принцип роботи
вбудованого в iPhone акселерометра
У iPhone прийняті
наступні орієнтації пристрою в просторі:
) Portrait Up - смартфон
розташований у вертикальному положенні, нижня кнопка дивиться вниз, прискорення
по осі Y дорівнює - g, по інших осях - нуям;
) Portrait Down -
смартфон розташований у вертикальному положенні, нижня кнопка дивиться вгору,
прискорення по осі Y дорівнює +g, по інших осях - нулям;
) Landscape Right -
смартфон розташований в горизонтальному положенні, нижня кнопка дивиться
вправо, прискорення по осі X дорівнює - g, по інших осях - нулям;
) Landscape Left -
смартфон розташований в горизонтальному положенні, нижня кнопка дивиться вліво,
прискорення по осі X дорівнює +g, по інших осях - нулям;
) Face Up - смартфон
розташований паралельно поверхні землі, екран дивиться вгору, прискорення по
осі Z дорівнює - g, по інших осях - нулям;
) Face Down - смартфон
розташований паралельно поверхні землі, екран дивиться вгору, прискорення по
осі Z дорівнює +g, по інших осях - нулям.
При якому-небудь
переміщенні смартфону в просторі значення прискорення по осях X, Y, Z
змінюються.
У всіх вище вказаних
вправ існує загальна особливість - одне повторення вправи складається з руху
вгору-вниз, або вниз-вгору. Таким чином, існує можливість об'єднати підрахунок
усіх вправ в один алгоритм.
Для дослідження сигналу
від акселерометра і розробки алгоритму було використано безкоштовне
застосування для iPhone Sensor Monitor, яке надає сигнал від різних датчиків
смартфону у вигляді графіків. Інтерфейс додатка Sensor Monitor приведений на
рисунку.
Поле Freq. служить для
вибору частоти опитування акселерометра, яка вимірюється в Гц. Чим вище частота
опитування акселерометра, тим більш точно видається графік сигналу. У додатку
Sensor Monitor можливо встановити 4 значення частоти опитування акселерометра:
30, 60, 90 і 120 Гц. Для реєстрації одного повторення вправи навіть частота 30
Гц є надмірною, оскільки навіть в найшвидшому темпі дуже складно зробити навіть
2 повторення будь-які з вправ. Тому подальші дослідження акселерометра
проводяться на частоті 30 Гц.
Лівіше за поле Freq.
виводяться значення прискорення по кожній з осей X, Y, Z. Значення змінюються з
вказаною частотою.
На тимчасовій діаграмі
зображений графік сигналу, що поступає від акселерометра, по трьох осях.
Інтерфейс додатка Sensor
Monitor
Нижня
частина екрану відведена для тих же даних, що поступають від гіроскопа. Ці дані
надалі ніяк не враховуватимуться.
Далі необхідно
досліджувати сигнал для п'яти базових фізичних вправ: підтягувань, віджимань,
віджимань на брусах, присідань і скручувань і виявити загальні закономірності.
Графік сигналу від
акселерометра при виконанні підтягувань зображений на рисунку.
При виконанні цієї
вправи iPhone знаходився в орієнтації Portrait. Для фіксації смартфону досить
покласти його в кишеню або тримати в руках. Як видно з графіку, дані по осях X
і Z мало коливаються, і дуже складно виділити які-небудь пікові області. Значення
прискорення по осі Х приблизно прагне до нуля. Тому для реєстрації повторень в
даному випадку необхідно аналізувати дані, отримані по осі Y.
Графік сигналу від
акселерометра при виконанні підтягувань
До початку вправи
значення прискорення по осі Y дорівнює - 1g. Перед першим підняттям корпусу
вгору над перекладиною прискорення різко зменшується приблизно до - 1.6g, і
потім збільшується приблизно до - 0.4g. При наступних трьох повтореннях
спостерігається приблизно такий же характер вихідного сигналу, але без
початкового падіння.
Через високу частоту
опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте
їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного
сигналу. Деякі стрибки амплітуд пов'язані з самим рухом корпусу, але вони також
не сильно спотворюють форму вихідного сигналу.
Таким чином, можна
зробити висновок, що для реєстрації початку вправи треба простежити перше
падіння прискорення - 1g до приблизно - 1.5g. Значення можна узяти із запасом
< - 1.3g. Для реєстрації кожного повторення необхідно виділити послідовність
двох рухів - вгору-вниз. Рух вгору визначається по стрибку прискорення > -
0.7g, рух вниз - по падінню прискорення нижче - 1.3g. Усі значення прискорення
беруться з невеликим запасом приблизно 10%, з урахуванням того, що кожна людина
виконує вправу з різною силою і швидкістю.
Далі необхідно провести
дослідження сигналу від акселерометра при виконанні віджимань. Графік
приведений на рисунку.
Графік сигналу від
акселерометра при виконанні
віджимань
При виконанні віджимань
значення прискорення по осях X і Y не сильно відхиляються від початкового
положення. Найбільш зручною для реєстрації повторень є вісь Z.
До початку вправи
значення прискорення по осі Z дорівнює - 1g. Перед першим опусканням корпусу
вниз прискорення різко збільшується приблизно до - 0.4g, і потім зменшується
приблизно до - 2.3g. При наступних чотирьох повтореннях спостерігається
приблизно такий же характер вихідного сигналу.
Через високу частоту
опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте
їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного
сигналу. Деякі стрибки амплітуд пов'язані з самим рухом корпусу, але вони також
не сильно спотворюють форму вихідного сигналу.
Далі необхідно провести
дослідження сигналу від акселерометра при виконанні віджимань на брусах.
При виконанні віджимань
на брусах значення прискорення по осях X і Z не сильно відхиляються від
початкового положення. Найбільш зручною для реєстрації повторень є вісь Y.
До початку вправи
значення прискорення по осі Y дорівнює - 1g. Перед першим опусканням корпусу
вниз прискорення різко збільшується приблизно до - 0.6g, і потім зменшується
приблизно до - 2.2g. При наступних чотирьох повтореннях спостерігається
приблизно такий же характер вихідного сигналу.
Через високу частоту
опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте
їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного
сигналу. Деякі стрибки амплітуд пов'язані з самим рухом корпусу, але вони також
не сильно спотворюють форму вихідного сигналу.
Графік сигналу від
акселерометра при виконанні
віджимань на брусах
Таким чином, можна
зробити висновок, що для реєстрації початку вправи треба простежити перше
збільшення прискорення - 1g до приблизно - 0.6g. Значення можна узяти із
запасом > - 0.7g. Для реєстрації кожного повторення необхідно виділити
послідовність двох рухів - вниз-вгору. Рух вниз визначається по падінню
прискорення нижче - 1.3g, рух вгору - по стрибку прискорення вище - 0.7g. Усі
значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням
того, що кожна людина виконує вправу з різною силою і швидкістю.
Далі необхідно провести
дослідження сигналу від акселерометра при виконанні присідань. Графік
приведений на рисунку 2.8.
При виконанні присідань
значення прискорення по осях X і Z не сильно відхиляються від початкового
положення. Найбільш зручною для реєстрації повторень є вісь Y.
Графік сигналу від
акселерометра при виконанні присідань
До початку вправи
значення прискорення по осі Y дорівнює - 1g. Перед першим опусканням корпусу
вниз прискорення різко збільшується приблизно до - 0.6g, і потім зменшується
приблизно до - 2.4g. При наступних двох повтореннях спостерігається приблизно
такий же характер вихідного сигналу.
Через високу частоту
опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте
їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного
сигналу. Деякі стрибки амплітуд пов'язані з самим рухом корпусу, але вони також
не сильно спотворюють форму вихідного сигналу.
Таким чином, можна
зробити висновок, що для реєстрації початку вправи треба простежити перше
збільшення прискорення - 1g до приблизно - 0.6g. Значення можна узяти із
запасом > - 0.7g. Для реєстрації кожного повторення необхідно виділити
послідовність двох рухів - вниз-вгору. Рух вниз визначається по падінню
прискорення нижче - 1.3g, рух вгору - по стрибку прискорення вище - 0.7g. Усі
значення прискорення беруться з невеликим запасом приблизно 10%, з урахуванням
того, що кожна людина виконує вправу з різною силою і швидкістю.
Останньою стандартною
вправою є скручування.
Графік сигналу від
акселерометра при виконанні
скручувань
При виконанні скручувань
найбільш зручною для реєстрації повторень є вісь Z.
До початку вправи
значення прискорення по осі Z дорівнює 1g. Перед першим підняттям корпусу
прискорення різко збільшується приблизно до +1.6g, і потім зменшується
приблизно до - 1g. При наступних двох повтореннях спостерігається приблизно
такий же характер вихідного сигналу.
Через високу частоту
опитування акселерометра в сигналі є присутніми високочастотні перешкоди, проте
їх амплітуда практично не виділяється і ніяк не впливає на характер вихідного
сигналу. Деякі стрибки амплітуд пов'язані з самим рухом корпусу, але вони також
не сильно спотворюють форму вихідного сигналу.
Таким чином, можна
зробити висновок, що для реєстрації початку вправи треба простежити перше
збільшення прискорення від +1g до приблизно +1.6g. Значення можна узяти із
запасом > +1.3g. Для реєстрації кожного повторення необхідно виділити
послідовність двох рухів - вгору-вниз. Рух вгору визначається по падінню
прискорення нижче 0.7g, рух вниз - по стрибку прискорення вище +1.3g. Усі
значення прискорення беруться з великим запасом (запас при скручуваннях можна
було зробити меншим), з урахуванням того, що кожна людина виконує вправу з
різною силою і швидкістю і з урахуванням відповідності іншим вправам.
Оскільки смартфон може
знаходитися в руках або кишені користувача в шести різних орієнтаціях (Portrait
Up, Portrait Down, Landscape Right, Landscape Left, Face Up, Face Down), то і
реєстрація повторень може проводитися за допомогою різних осей - X, Y або Z.
Значення прискорень в різних орієнтаціях ніяк не відрізняються по амплітуді і
частоті. Визначальним в підрахунку повторень є чинник вибору орієнтації, а отже
і осі.
Як можна переконатися з
усіх досліджених вправ, характер сигналу в усіх випадках практично однаковий.
Значення амплітуд відрізняються трохи. Для кожної вправи рух вниз і вгору можна
визначити як відхилення амплітуди прискорення від початкового значення на +0.3g.
Якщо положення смартфону
відрізняється від усіх стандартних орієнтацій в просторі, і початкові значення
по усіх осях приміром прагнуть по модулю до 0.5g, то погрішність є не критичною
і близько 95% повторень реєструються. Єдиною перешкодою для правильної реєстрації
повторень є погана фіксація смартфону в кишені або руках. Якщо користувач під
час виконання вправи якось повертає або трясе iPhone, це може бути зараховано
за зайві повторення.
Також на практиці слід
досліджувати неправильне повторення вправ, тобто виконання вправ не в повну
силу.
Графік сигналу від
акселерометра при неправильному виконанні віджимань на брусах
При неправильному
виконанні вправ відхилення амплітуди прискорення по модулю становить менше ніж
0.3g. Таким чином це можна врахувати в організації алгоритму і не зараховувати
неправильне виконання вправ.
У блоці «Визначення
орієнтації смартфону» отримуються значення прискорень по усіх осях і фіксується
найбільш відповідна орієнтація. Залежно від орієнтації смартфону в просторі
вибирається вісь, згідно якої реєструватимуться повторення.
Кожні 50 мс поступають
нові значення від акселерометра. Якщо значення по вибраній осі відрізняється
від початкового більш ніж на 0.3g, це прискорення реєструється як рух вгору або
вниз. Якщо перший рух був вгору, то після появи руху вниз лічильник кількості
повторень збільшується на 1. Якщо перший рух був вниз, то після появи руху
вгору лічильник кількості повторень збільшується на 1. Підрахунок повторень
триває, поки тривають нові рухи. Якщо по події п'яти секунд не було жодного
руху, підрахунок зупиняється.
Для зручності
користувача початок і кінець вправи супроводжуються звуковим сигналом. Існує
безліч звукових бібліотек з різними функціональними можливостями [8]. У проекті
SportDiary використовується бібліотека AVFoundation.
Фрагмент початкового
коду алгоритму автоматичного підрахунку вправ включений в опис класу
TrainingViewController і приведений в додатку А.
2.3 Розробка кінцевої
версії мобільного додатку і огляд використаних технологій
Розробка iPhone-додатків
повинна проводитись на комп’ютерах сімейства Macintosh в середовищі розроблення
програмного забезпечення XCode. У рамках магістерської роботи використовується
версія XCode 4.
Пакет XCode підтримує
мови програмування C, C++, Objective-C, Objective-C++, Java, AppleScript,
Python та Ruby з різними моделями програмування. Для розробки проекту
SportDiary використовується тільки Objective-C, оскільки він є стандартною
мовою програмування для розробки додатків під iPhone.C - підмножина С - є
об’єктно-орієнтованою мовою програмування корпорації Apple. Основною
відмінністю Objective-C є концепція відправлення повідомлень об’єктам, на що
об’єкт відповідає виконанням певних дій. Для прикладу можна привести графічний
інтерфейс, коли головний контролер відправляє повідомлення View нарисувати коло
певного розміру, на що View рисує коло. Objective-C підтримує всі оператори
мови С та білшість концепцій об’єктно-орієнтованого програмування.
Програма XCode
призначена для розробки додатків для OS X (операційна система для комп’ютерів
сімейства Macintosh), та iOS (операційна система для iPad, iPhone і iPod touch)
і включає в себе низку інструментів для розробки програмного забезпечення,
таких як документація розробника, додаток, що використовується для розробки
графічних інтерфейсів, пакет моніторингу, та інші.
Операційні системи OS X
та iOS архітектурно дуже схожі, за відміною того, що в ОС для смартфонів
верхнім шаром є Cocoa Touch Framework, а в OS X - Cocoa Framework.
Загальна архітектура
операційних систем Mac OS X та iPhone OS
Оскільки проект
розроблюється для iPhone, далі буде розглядатися тільки архітектура iOS.
Нинжній рівень Core OS є
фундаментом операційної системи. Він відповідає за організацію пам’яті, файлову
систему, мережі та інші задачі, відповідні за апаратне забезпечення. Core OS
складається з наступних компонентів:
- ядро OS X;
- Mach 3.0;
BSD;
сокети;
рівень
захисту;
управління
потужністю;
Keychain;
сертифікати;
файлова система;
Bonjour.
Наступний рівень Core
Services є абстракцією над нижнім рівнем. Він забезпечує базовий доступ до
сервісів iOS та включає наступні компоненти:
- колекції;
- адресна книга;
мережі;
доступ до
файлів;
SQLite;
Core Location;
веб-сервіси;
потоки;
Preferences;
URL-утіліти.
Рівень Media забезпечує
мультимедійні сервіси, що можна використовувати в додатках для iPhone та iPad.
Він складається з наступних компонентів:
Core Audio;
- OpenGL;
- Audio Mixing;
аудіозапис;
програш відео;
JPG, PNG,
TIFF;
PDF;
Core
Animation;
OpenGL ES.
Рівень Cocoa Touch являє
собою абстрактний шар, що представляє різноманітні бібліотеки для програмування
iPhone та iPad, такі як наступні:
- події Multi-Touch;
- контроль
Multi-Touch;
акселерометр;
ієрархія View;
локалізація;
сигнали;
Web Views;
People Picker;
Image Picker;
контролери
[7].
У програмуванні iOS усі
функції на кожному з рівнів забезпечуються за допомогою низки бібліотек. У
проекті SportDiary використовуються усі рівні окрім нижчого.
Проект SportDiary
розроблюється в пакеті розроблення програмного забезпечення XCode 4 в
операційній системі Mac OS Lion.
Програма написана згідно
зі схемою проектування MVC (model-view-controller), тобто
модель-представлення-контролер.
Згідно з концепцією MVC
програмний продукт повинен складатися з трьох компонентів: контролеру,
представлення та моделі. Представлення - це графічний вид, тобто інтерфейс
програми. Модель - це абстрактне представлення даних. Контролер - компонент
який здійснює комунікацію між цими двома компонентами та оброблює необхідні
дані.
Концепція проектування
Model-View-Controller
Програмний продукт
взаємодіє із користувачем через контролер. Додаток також взаємодіє з базою
даних через абстрактну модель.
Отже розроблений проект
SportDiary складається з наступних компонентів:
. Графічний інтерфейс
(приклад одного View приведений на рисунку 2.14). Графічний інтерфейс
збудований згідно з рекомендаціями компанії Apple та є зручним та зрозумілим у
використанні [10].
. Контролер для кожного
View.
. Локальна база даних, в
якій зберігаються статистичні дані та деякі дані користувача.
. Модель, в якості якої
використовуються встроєні в бібліотеку libsqlite3 функції.
Приклад View з проекту
SportDiary
Головними компонентами
програми є:
. Автоматичний лічильник
повторювань вправи. Алгоритм цього лічильнику є універсальним і може
підраховувати віджимання, підтягування, віджимання на брусах, присідання,
скручування, та різні варіації цих вправ, таких як підтягування з вузьким
хватом, широким хватом та інші.
. Складання статистики
по кожній вправі та зберігання значень в базі даних SQLite. Відбудовування
графіку статистики по кожній вправі (рисунок 2.15).
Статистика складається
за наступним принципом. Усі повторювання вправи за день сумуються та
зберігаються до бази даних. Якщо значення за сьогоднішній день вже зберігається
в базі даних, то нове значення додається до попередньго і новий результат
зберігається до бази даних. Коли користувач переходить до View, на якому
представлений графік статистики, із бази даних вибираються значення для цієї
вправи за кожен день та будується графік, кожна точка в якому представляє
кількість повторювань вправи за один день. Статистика представляється за весь
період тренувань. Якщо користувач взагалі не виконував цієї вправи, графік
пустий.
Рисунок 2.15 - Графік
статистики по обраній вправі
3. Синхронізація даних
статистики та користувача з сервером. Для цього використовуються вбудовані
функції роботи з URL для організації post та get-запросів.
На сервері були створені
спеціальні API для взаємодії із додатком смартфону. Наприклад, для отримання
кількості точок на графіку статистики з серверу необхідно сформувати строку
запросу наступним чином:
NSString * request =
[NSString stringWithFormat:@ «#"576554.files/image016.gif">
Інтерфейс редагування статистики
Усі дані відправляються
на сервер за допомогою POST-запиту. Нижче приведений фрагмент програмного коду
відправлення даних на сервер за допомогою POST-запиту:
*postData = [params
dataUsingEncoding: NSUTF8StringEncoding allowLossyConversion: NO];*postLength =
[NSString stringWithFormat:@ "%d», [postData length]];num = rand();*
reqURl = [NSString stringWithFormat:@ «#"576554.files/image017.gif">
Інтерфейс новин
соціальної мережі в мобільному додатку SportDiary
Вкладка News аналогічна.
У ній відображуються останні новини від користувачів All і Favourites. Дані,
якими заповнюється Table View отримується у форматі JSON-массива в результаті
запиту до сервера. JSON-массив зберігає наступну інформацію по кожному
користувачеві: id користувача, його ім'я і новину. Фотографія користувача в
дрібному форматі 75*75 пікселів отримується за допомогою звичайного запиту за
адресою, по якій зберігається це фото.
Для того щоб проект
працював без збоїв, його необхідно протестувати в менеджері профілей у профілі
витоку пам’яті.
Тестування проекту на
витоки пам’яті
Як видно із малюнку 3.6
в проекті немає витоків пам' яті. Іноді при виділенні пам' яті під рядка можуть
бути витоки блоків пам' яті не більш ніж 200 байт, але сморід не мають ніякого
впливу на правильність роботи програми, оскільки в операційній системі є
менеджер автоматичного підрахунку посилань, який виправляє витоки незначного
розміру. Коли об'єкт має бути знищений через обнулення його лічильника
посилань, Objective-C автоматично відправляє об'єкту повідомлення dealloc і
розробник не повинен за цим стежити [5].
3. Розробка специфічної
соціальної мережі, призначеної для користувачів мобільного додатка Sportdiary
.1 Налаштування сервера
і огляд використаних технологій
Для підтримки соціальної
мережі з великою (у перспективі) кількістю користувачів необхідно вибрати
потужний і надійний сервер, який здатний витримувати високе навантаження на
ресурси - більше 1000 запитів за секунду.
Раніше в ході роботи над
високонавантаженими веб-сервісами було розроблено три додатки для соціальних
мереж, які набрали аудиторію 130 000 користувачів.
Спочатку для підтримки цих
додатків використовувався VPS-сервер, наданий українським підприємством
HostLife. Основні характеристики цього сервера:
процесор: 900 Мгц;
ОЗП: 1 Гб;
жорсткий диск: 20 Гб;
трафік необмежений;
ціна 30 у. е.
Проте із зростанням
аудиторії приблизно до 100 000, сервер перестав справлятися з навантаженням.
Завантаження оперативної пам'яті і процесора були в межах 90-100%. Це
дослідження проводилося за допомогою команди top.
Також за весь час
використання сервера були збої праці до цілої години.
Тому було прийнято
рішення знайти потужніший і надійніший сервер.
В якості нового сервера
був вибраний Root-сервер EX 5, наданий німецькою компанією Hetzner, сервери
якої знаходяться поблизу міста Гамбург. Основні характеристики цього сервера
наступні:
процесор: Intel® Core™
i7 - 920 Quad-Core;
ОЗП: 24 GB DDR3 RAM;
жорсткий диск: 1.5 Тб;
трафік необмежений;
ціна 76 у. е.
Співвідношення
ціна-якість німецького сервера набагато кращі за український. Також компанія
Hetzner надає дуже зручну функцію автоматичного сповіщення про збої по смс і
e-mail.
Протягом одного дня усі
веб-додатки були перенесені на новий сервер і при тій же аудиторії трохи більше
100 000 чоловік завантаження оперативної пам'яті і процесора при перевірці
командою top склало близько 1%.
Графік залежності
завантаження сервера від кількості користувачів веб-додатків
Таким чином був
зроблений висновок, що проект SportDiary на початковому етапі слід розмістити
на сервері Hetzner. Оскільки сервер з легкістю обслуговує додатки для
соціальних мереж з аудиторією 130 000, то й додаток SportDiary
обслуговуватиметься ще простіше, оскільки запити до сервера в іграх соціальних
мереж повинні відбуватися набагато частіше, ніж до спортивного щоденника.
В якості HTTP-сервера
був встановлений nginx. Для обробки скриптів був використаний обробник PHP-FPM,
що працює в режимі FastCGI.
Нижче приведені основні
директиви, які використовувалися при розробці сайту sportdiary.net, і які
прописані в конфігураційному файлі nginx:
fastcgi_intercept_errors
on | off - визначає, чи передавати клієнтові відповіді FastCGI-сервера з кодом
більше або рівним 400, або ж перенаправляти їх на обробку nginx'у за допомогою
директиви error_page. У конфігураційному файлі встановлено значення on;
fastcgi_ignore_client_abort
on | off - визначає, чи закривати з'єднання з FastCGI-сервером у разі, якщо
клієнт закрив з'єднання, не дочекавшись відповіді. Встановлено значення off;
fastcgi_connect_timeout
час - задає таймаут для встановлення з'єднання з FastCGI-сервером. Необхідно
мати на увазі, що цей таймаут зазвичай не може перевищувати 75 секунд.
Встановлений в значення 60;
fastcgi_send_timeout час
- задає таймаут при передачі запиту FastCGI-серверу. Таймаут встановлюється не
на усю передачу запиту, а тільки між двома операціями запису. Якщо після
закінчення цього часу FastCGI-сервер не прийме нових даних, з'єднання
закривається. Встановлений в значення 180;
fastcgi_read_timeout час
- задає таймаут при читанні відповіді FastCGI-сервера. Таймаут встановлюється
не на усю передачу відповіді, а тільки між двома операціями читання. Якщо після
закінчення цього часу FastCGI - сервер нічого не передасть, з'єднання
закривається. Встановлений в значення 180;
fastcgi_buffer_size
розмір - задає розмір буфера, в який читатиметься перша частина відповіді, що
отримується від FastCGI-сервера. У цій частині відповіді знаходиться, як
правило, невеликий заголовок відповіді. За умовчанням розмір буфера дорівнює
розміру одного буфера в директиві fastcgi_buffers, проте його можна зробити
менше. Встановлений в значення 128k;
fastcgi_buffers число
розмір - задає число і розмір буферів для одного з'єднання, в які читатиметься
відповідь, що отримується від FastCGI - сервера. За умовчанням розмір одного
буфера дорівнює розміру сторінки. Залежно від платформи це або 4K, або 8K.
Встановлено значення 4 256k;
fastcgi_busy_buffers_size
розмір - обмежує сумарний розмір буферів, які можуть бути зайняті для відправки
відповіді клієнтові, поки відповідь ще не прочитана цілком. Буфери, що
залишилися, тим часом можуть використовуватися для читання відповіді і, при
необхідності, буферизації частини відповіді в тимчасовий файл. За умовчанням розмір
обмежений двома буферами, заданими директивами fastcgi_buffer_size і
fastcgi_buffers. Встановлено значення 256k;
fastcgi_temp_file_write_size
розмір - обмежує розмір даних, що скидаються в тимчасовий файл за один раз, при
включеній буферизації відповідей FastCGI-сервера в тимчасові файли. За
умовчанням розмір обмежений двома буферами, заданими директивами
fastcgi_buffer_size і fastcgi_buffers. Максимальний розмір тимчасового файлу
задається директивою fastcgi_max_temp_file_size [11]. Встановлено значення
256k.
Для обробки баз даних
був встановлений MySQL-сервер.
Для підвищення
продуктивності необхідно оптимізувати MySQL-сервер. Далі будуть описані різні
настройки MySQL, які були протестовані.
Базові настройки:
low-priority-updates -
ця опція знижує пріоритет операцій INSERT / UPDATE в порівнянні з SELECT.
Актуально, якщо дані важливо швидше прочитати, чим швидше записати;
skip-external-locking -
опція встановлена за замовчуванням, починаючи з версії 4. Вказує MySQL-серверу не
використовувати зовнішні блокування при роботі з базою. Зовнішні блокування
необхідні в ситуаціях, коли кілька серверів працюють з одними і тими ж файлами
даних, тобто мають однакову datadir, що на практиці не використовується;
skip-name-resolve - не
визначати доменні імена для IP-адрес клієнтів, що підключаються. При цьому
користувальницькі дозволу потрібно налаштовувати не на хости, а на IP-адреси
(за винятком localhost). Якщо користувач з'єднується із сервером тільки з
локальної машини, то особливого значення не має. Для зовнішніх з'єднань
прискорить установку з'єднання;
skip-networking - не
використовувати мережу, тобто взагалі не обробляти TCP / IP з'єднання.
Спілкування з сервером при цьому буде відбуватися виключно через сокет.
Рекомендується, якщо у немає ПО, яке використовує тільки TCP / IP для зв'язку з
сервером.
Обмеження:
bind-address -
інтерфейс, який буде прослуховувати сервер. З метою безпеки рекомендується
встановити 127.0.0.1, якщо не використовуються зовнішні з'єднання з сервером;
max_allowed_packet -
максимальний розмір даних, які можуть бути передані за один запит. Слід
збільшити, якщо виникає помилка Packet too large;
max_connections -
максимальна кількість паралельних з'єднань до сервера. Необхідно збільшити,
якщо виникає проблема Too many connections;
max_join_size -
забороняє SELECT оператори, які імовірно будуть аналізувати більш вказаного
числа рядків або більше вказаного числа пошуків по диску. Використовується для
захисту від поганих запитів, які намагаються рахувати мільйони рядків. Значення
за умовчанням більше 4 мільярдів;
max_sort_length -
вказує, скільки байтів з початку полів типу BLOB або TEXT використовувати при
сортуванні. Значення за умовчанням 1024, якщо є імовірність некоректно
спроектованих таблиць або запитів, то слід його зменшити.
Настройки потоків:
thread_cache_size -
вказує число кешованих потоків. Після обробки запиту сервер не завершуватиме
потік, а розмістить його в кеші, якщо число потоків, що знаходять в кеші менше,
ніж вказане значення. Значення за умовчанням 0, необхідно збільшити його до 8
або відразу до 16. Якщо спостерігається ріст значення змінної стану
Threads_Created, то слід ще збільшити thread_cache_size;
Кешування запитів:
query_cache_limit -
максимальний розмір кешувального запиту;
query_cache_min_res_unit
- мінімальний розмір збереженого в кеші блоку;
query_cache_size -
розмір кеша. 0 відключає використання кеша. Для вибору оптимального значення
необхідно спостерігати за змінною стану Qcache_lowmem_prunes і домогтися, щоб
її значення збільшувалося незначно. Також потрібно пам'ятати, що надмірно
великий кеш буде створювати непотрібне навантаження;
query_cache_type - (OFF,
DEMAND, ON). OFF відключає кешування, DEMAND - кешування буде вироблятися
тільки при наявності директиви SQL_CACHE в запиті, ON включає кешування;
query_cache_wlock_invalidate
- визначає, чи будуть дані братися з кеша, якщо таблиця, до яких вони
відносяться, заблокована на читання.
Кеш запитів можна
представити як хеш-масив, ключами якого є запити, а значеннями - результати
запитів. Крім результатів, MySQL зберігає в кеші список таблиць, вибірка з яких
закешірована. Якщо в будь-який з таблиць, вибірка з якої є в кеші, проіcходят
зміни, то MySQL видаляє з кешу такі вибірки. Також MySQL не кешує запити,
результати яких можуть змінитися.
При запуску MySQL
виділяє блок пам'яті розміром в query_cache_size. При виконанні запиту, як
тільки отримано перші рядки результату сервер починає кешувати їх: він виділяє
в кеші блок пам'яті, рівний query_cache_min_res_unit, записує в нього результат
вибірки. Якщо не вся вибірка помістилася в блок, то сервер виділяє наступний
блок і так далі. У момент початку запису MySQL не знає про розмір отриманої
вибірки, тому якщо записаний у кеш розмір вибірки більше, ніж
query_cache_limit, то запис припиняється і зайняте місце звільняється, отже,
якщо відомо наперед, що результат вибірки буде більшим, варто виконувати його з
директивою SQL_NO_CACHE.
Таймінги:
interactive_timeout -
час в секундах, протягом якого сервер очікує активності з боку інтерактивного
з'єднання (використовує прапор CLIENT_INTERACTIVE), перш ніж закрити його;
log_slow_queries -
вказує сервера логувати довгі («повільні») запити (виконуються довше
long_query_time). Як значення передається повне ім'я файлу (наприклад / var /
log / slow_queries);
long_query_time - якщо
запит виконується довше зазначеного часу (в секундах), то він буде вважатися
повільним;
net_read_timeout - час в
секундах, протягом якого сервер буде очікувати отримання даних, перш ніж
з'єднання буде перервано. Якщо сервер не обслуговує клієнтів з дуже повільними
або нестабільними каналами, то 15 секунд буде достатньо;
net_write_timeout - час
в секундах, протягом якого сервер буде очікувати відправку даних, перш ніж
з'єднання буде перервано. Якщо сервер не обслуговує клієнтів з дуже повільними
або нестабільними каналами, то 15 секунд буде достатньо;
wait_timeout - час в
секундах, протягом якого сервер очікує активності сполуки, перш ніж перерве
його. У загальному випадку 30 секунд достатньо.
Буфери:
key_buffer_size - розмір
буфера, який виділяється під індекси і доступного всім потокам. Вельми важлива
настройка, яка впливає на продуктивність. Значення за умовчанням 8 МБ, його
однозначно варто збільшити. Рекомендується 15-30% від загального обсягу ОЗУ,
однак немає сенсу встановлювати більше, ніж загальний розмір усіх MYI файлів.
Необхідно спостерігати за змінними стану Key_reads і Key_read_requests,
ставлення Key_reads / Key_read_requests повинно бути якомога менше (<0,01).
Якщо це відношення велике, то розмір буфера варто збільшити;
max_heap_table_size -
максимальний допустимий розмір таблиці, що зберігається в пам'яті (типу
MEMORY). Значення за замовчуванням 16 МБ, якщо ви не використовуєте MEMORY
таблиць, то встановіть це значення рівним tmp_table_size;
myisam_sort_buffer_size
- розмір буфера, який виділяється MyISAM для сортування індексів при REPAIR
TABLE або для створення індексів при CREATE INDEX, ALTER TABLE. Значення за
умовчанням 8 МБ, його варто збільшити аж до 30-40% ОЗУ. Виграш в продуктивності
відповідно буде тільки при виконанні вищезазначених запитів;
net_buffer_length -
об'єм пам'яті, що виділяється для буфера з'єднання і для буфера результатів на
кожен потік. Буфер з'єднання буде зазначеного розміру і буфер результатів буде
такого ж розміру, тобто на кожен потік буде виділений подвійний розмір
net_buffer_length. Вказане значення є початковим і при необхідності буфери
будуть збільшуватися аж до max_allowed_packet. Розмір за замовчуванням 16 КБ. У
разі обмеженої пам'яті або використання тільки невеликих запитів значення можна
зменшити. У разі ж постійного використання великих запитів і достатнього обсягу
пам'яті, значення варто збільшити до передбачуваного середнього розміру запиту;
read_buffer_size - кожен
потік при послідовному скануванні таблиць виділяє зазначений обсяг пам'яті для
кожної таблиці. Як показують тести, це значення не слід особливо збільшувати.
Розмір за замовчуванням 128 КБ, спробуйте збільшити його до 256 КБ, а потім до
512 КБ і поспостерігайте за швидкістю виконання запитів типу SELECT COUNT (*)
FROM table WHERE expr LIKE «a%»; на великих таблицях;
read_rnd_buffer_size -
актуально для запитів з «ORDER BY», тобто для запитів, результат яких повинен
бути відсортований і які звертаються до таблиці, що має індекси. Значення за
замовчуванням 256 КБ, збільште його до 1 МБ або вище, якщо дозволяє пам'ять.
Врахуйте, що вказане значення пам'яті також виділяється на кожний потік;
sort_buffer_size - кожен
потік, що виробляє операції сортування (ORDER BY) або угруповання (GROUP BY),
виділяє буфер вказаного розміру. Значення за замовчуванням 2 МБ, якщо ви використовуєте
зазначені типи запитів і якщо дозволяє пам'ять, то значення варто збільшити.
Велике значення змінної стану Sort_merge_passes вказує на необхідність
збільшення sort_buffer_size. Також варто перевірити швидкість виконання запитів
виду SELECT * FROM table ORDER BY name DESC на великих таблицях, можливе
збільшення буфера лише сповільнить роботу (в деяких тестах це так);
table_cache
(table_open_cache з версії 5.1.3) - кількість кешованих відкритих таблиць для
всіх потоків. Відкриття файлу таблиці може бути досить ресурсномісткою
операцією, тому краще тримати відкриті таблиці в кеші. Слід врахувати, що кожен
запис в цьому кеші використовує системний дескриптор, тому можливо доведеться
збільшувати обмеження на кількість дескрипторів (ulimit). Значення за
замовчуванням 64, його найкраще збільшити до загальної кількості таблиць, якщо
їх кількість в допустимих рамках. Змінна стану Opened_tables дозволяє
відстежувати число таблиць, відкритих в обхід кеша, бажано, щоб її значення
було якомога нижче;
tmp_table_size -
максимальний розмір пам'яті, виділеної для тимчасових таблиць, створюваних
MySQL для своїх внутрішніх потреб. Це значення також обмежується змінної
max_heap_table_size, тому в підсумку буде вибрано мінімальне значення з
max_heap_table_size і tmp_table_size, а інші тимчасові таблиці будуть
створюватися на диску. Значення за умовчанням залежить від системи, спробуйте
встановити його рівним 32 МБ і поспостерігати за змінною стану
Created_tmp_disk_tables, її значення повинно бути якомога менше.
Значення в
конфігураційному файлі задаються в байтах, відповідно кілобайти і мегабайти
потрібно переводити в байти.:
innodb_additional_mem_pool_size
- розмір пам'яті, що виділяється InnoDB для зберігання різних внутрішніх
структур. Якщо InnoDB буде недостатньо цієї пам'яті, то буде запитана пам'ять у
ОС і записано попередження в лог помилок MySQL;
innodb_buffer_pool_size
- розмір пам'яті, що виділяється InnoDB для зберігання і індексів і даних.
Значення - чим більше, тим краще. Можна збільшувати аж до загального розміру
всіх InnoDB таблиць або до 80% ОЗУ, в залежності від того, що менше;
innodb_flush_log_at_trx_commit
- має три допустимих значення: 0, 1, 2. При значенні рівному 0, лог скидається
на диск один раз в секунду, незалежно від відбуваються транзакцій. При значенні
рівному 1, лог скидається на диск при кожній транзакції. При значенні рівному
2, лог пишеться при кожній транзакції, але не скидається на диск ніколи,
залишаючи це на совісті ОС. За замовчуванням використовується 1, що є
найнадійнішою налаштуванням, але не найшвидшою. У загальному випадку ви можете
сміливо використовувати 2, дані можуть бути загублені лише в разі краху ОС і
лише за декілька секунд (залежить від налаштувань ОС). 0 - найшвидший режим,
але дані можуть бути загублені як при краху ОС, так і при краху самого сервера
MySQL (втім дані лише за 1-2 секунди);
innodb_log_buffer_size -
розмір буфера логу. Значення за замовчуванням 1 МБ, збільшувати його варто,
якщо ви знаєте, що буде велика кількість транзакцій InnoDB або якщо значення
змінної стану Innodb_log_waits зростає. Вам навряд чи доведеться збільшувати
його вище 8 МБ;
innodb_log_file_size -
максимальний розмір одного лог-файлу. При досягненні цього розміру InnoDB буде
створювати новий файл. Значення за замовчуванням 5 МБ, збільшення розміру
поліпшить продуктивність, але збільшить час відновлення даних. Встановіть це
значення в діапазоні 32 МБ - 512 МБ в залежності від розміру сервера (оцінивши
його суб'єктивно) [9].
Нижче описані
рекомендації до роботи з таблицями для досягнення більшої продуктивності:
. По можливості усі поля
декларувати як NOT NULL. Це зробить роботу з таблицями швидшою і збереже 1 біт
на кожне таке поле.
. Застосовувати значення
за умовчанням (DEFAULT). При виклику запиту INSERT в таблицю записуватимуться
тільки ті поля, значення яких відрізняються від DEFAULT.
. Використовувати
настільки малі типи INT, наскільки це можливо.
. При використанні
декількох послідовних INSERT запитів, краще усі дані вказати в одному INSERT,
чим робити декілька INSERT [6].
Конфігураційний файл
MySQL можна подивитися в доповненні Б.
В ході розробки та
тестування проекту було поставлене питання використовувати G++ чи PHP.
Виявилося, що швидкість роботи при використанні G++ на порядок швидше, але за
умовою, що немає звертання до банку даних. Якщо йде звертання до банку даних,
то час обробки однаковий.
Графік залежності
кількості оброблюваних запитів в секунду від вибраної технології зображений на
рисунку 3.2.
Тестування проводилося
за допомогою утиліти Apache Bench (ab). Такого роду тест не дає результату,
наближеного до реальності, оскільки у реальному режимі користувачі звертаються
до різних скриптів, а також до статичних об'єктів. Також ця утиліта не враховує
ширини каналу. Але для порівняння двох технологій вона є прийнятною.
Графік залежності
кількості оброблюваних сервером запитів від вибраної технології
При запиті до двох
скриптів на G++ і PHP з однаковою функціональністю і без звернення до бази
даних співвідношення кількості запитів до стрипту в секунду можна виразити
формулою:
= 20*P, (4.1)
де G - кількість запитів
до скрипта на G++, P - кількість запитів до скрипта PHP в секунду.
≈ P (4.2)
Таким чином залежність
можна об'єднати в одну формулу:
= k * P
(4.3)
де G - кількість запитів
до скрипта на G++, P - кількість запитів до скрипта на PHP, k = 1, якщо в
скрипті є звернення до бази даних, k = 20, якщо звернення до бази даних немає.
Оскільки в усіх
скриптах, використовуваних в проекті SportDiary є звернення до бази даних, то
дуже складно зробити вибір лише за критерієм швидкодії.
Проте за критерієм
надійності вибір технології PHP є переважним. Якщо відбувається збій сервера,
перезапустити програму G++ можна тільки вручну. PHP у свою чергу
перезапускається автоматично. Тому для написання скриптів був вибрана саме
технологія PHP.
Для забезпечення
швидкого завантаження сторінки і зручності для користувачів, сторінка
завантажується таким чином: спочатку завантажується статична html-сторінка, і
тільки потім вона заповнюється даними за допомогою jQuery і PHP-скриптів.
Початковий код сторінок
написаний на html5 і JavaScript з використанням бібліотеки jQuery. JavaScript є
найбільш популярною скриптовою мовою [12]. Виходячи з попереднього досвіду
програмування, він є найбільш зручним і ефективним.
.2 Розробка соціальної
мережі і забезпечення її взаємодії з мобільним додатком
За своїмі
функціональними можливостями соціальна мережа www.sportdiary.net практично
ідентична з тією, яка вбудована в мобільне застосування. У неї є тільки дві
додаткові функції:
) коментування
статистики користувачів;
) вхід в соціальну
мережу під логіном і паролем, виданим в мобільному додатку.
Інтерфейс соціальної
мережі sportdiary.net зображений на рисунку 3.3.
Для синхронізації
мобільного застосування з сайтом були розроблені спеціальні API.
Для того, щоб відправити
якісь дані на сервер з мобільного додатку необхідно виконати POST-запит по
вказаному посиланню і передати в тілі запиту необхідні дані. Для того, щоб
отримати якісь дані від сервера, необхідно виконати GET-запит і отримати дані у
відповідь у вигляді JSON-масиву.
Нижче наведений приклад
GET-запиту перевірки наявності Інтернету:
num = rand();
NSString * request =
[NSString stringWithFormat:@ «#"576554.files/image021.gif">
Інтерфейс вкладки
«People» в мобільному додатку SportDiary
Як видно з приведених
рисунків, дані синхронізовані коректно і є однаковими.
Аналогічно
синхронізуються статистичні дані по кожному користувачеві. Дані з локальної
бази SQLite мобільного додатка SportDiary відправляються на сервер за допомогою
POST-запиту і переписуються в базу даних SQL на сервері. Структура бази даних
за статистикою аналогічна тій, яка була описана в мобільному застосуванні.
Відмінністю є таблиця користувачів, в якій зберігаються наступні дані:
ім'я користувача;
id користувача;
логін користувача;
пароль користувача.
Також в базі даних
зберігаються деякі дані для взаємодії з іншими соціальними мережами, але ці
дані у рамках магістерської роботи неважливі.
При перегляді статистики
на сайті статистичні дані підвантажуються з бази даних на сервері і
відображуються на екрані за допомогою вільної бібліотеки jQuery jqplot.
Графік статистики на
сайті sportdiary.net
.3 Тестування роботи
проекту на реальних користувачах
Заздалегідь була
проведена зразкова оцінка можливостей сервера за допомогою утиліти Apache
Bench.
Кількість звернень до
різних скриптів в секунду варіювалася від 1 500 до 17 000 запитів за секунду. У
такі пікові моменти мобільне застосування затримувалося приблизно на 2-3
секунди під час запитів до сервера. Проте неможливо зробити які-небудь точні
висновки з отриманих даних. Не можна визначити, якою буде реальна максимальна
кількість запитів користувачів до сервера в секунду.
По-перше, запити
поступають до різних скриптів і статичних файлів з різною частотою. По-друге,
невідомо, якою за розміром буде відповідь скрипта - 1 кілобайт або 1 мегабайт.
Утиліта ab ніяк не враховує ширину каналу сервера (яка дорівнює 100 мбит).
Наочнішою є оцінка
відвідувань реальних користувачів. Як згадувалося раніше, сервер вже обслуговує
стотридцятитисячну аудиторію користувачів. І тому дуже зручно оцінити роботу
спортивного щоденника в зв'язці з додатками для соціальних мереж.
Оскільки сервер
обслуговуватиме одночасно соціальні додатки і додаток SportDiary, можна буде
зробити приблизну оцінку можливостей сервера.
Аудиторія трьох додатків
складає 130 000 чоловік. У пікові моменти за день додаток відвідували 15 000
унікальних користувачів і максимальне завантаження складало 200 запитів в
секунду. При такому навантаженні на ресурси сервер був завантажений усього на
1%. З цього можна зробити висновок, що практично із стовідсотковою вірогідністю
сервер витримає навантаження набагато більше, ніж 1000 запитів за секунду, якщо
це дозволить ширина каналу. Оскільки дуже рідко один запит вимагає більше ніж 1
кілобайт (зазвичай значно менше), то сервер можна вважати високонавантаженим.
Таким чином проект
SportDiary є високонавантаженим веб-сервісом.
Для поширення додатка по
всьому світу слід прагнути, щоб він підтримував багато мов [3]. Тому надалі
планується його переклад на німецьку, французьку, російську, італійську та інші
мови.
Далі буде розглянута
публікація додатка в офіційному магазині App Store і його тестування на
реальній аудиторії.
Для публікації додатків,
як платних, так і безкоштовних, необхідно реєструватися розробником на
офіційному магазині Apple. Для цього треба заповнити бланк заяви з вказівкою
своїх контактних даних і сплатити щорічний внесок 99 у. о.
Для того, щоб додаток
розмістили в офіційному магазині, він у свою чергу повинен відповідати ряду
вимог до змісту, а також справно працювати і не піддаватися критичним помилкам.
Раніше було наведено тестування додатка на помилки і втрати пам'яті, яке
підтвердило правильність виконання програми.
Для розміщення в
офіційному магазині спочатку необхідно скомпілювати проект з налаштуваннями
розробника. Головні налаштування розробника приведені на рисунку 3.7.
Рисунок 3.7 - Основні
налаштування розробника проекту SportDiary в середовищі розробки XCode
Далі необхідно
відкомпілювати проект і створити архів для подальшого розміщення в App Store.
Сховище архівів в середовищі розробки XCode з проектом SportDiary приведене на
риснуке 3.8.
Далі необхідно пройти
перевірку програмного продукту (Validate). Якщо перевірка пройшла успішно,
додаток можна розміщувати в офіційному магазині (Distribute).
Після цього додаток
з'являється в профілі розробника на сайті itunesconnect.apple.com. Перед
фінальною публікацією додатка треба скласти його опис (бажано на декількох
мовах), зробити від одного до п'яти скриншотів, а також виконати деякі
налаштування.
Коли усі налаштування
зконфігуровані, проект можна відправляти в чергу публікації. Проект SportDiary
був розміщений в офіційному магазині приблизно через 2 тижні після відправлення
заявки.
За весь час роботи
додатка у користувачів не було жодного збою в роботі додатка. Додаток працює
швидко і завантаження даних з сервера триває не більше за одну секунду. З
урахуванням того, що сервер обслуговує ще 130 000 користувачів додатків для
соціальних мереж, завантаження сервера складає біля одного відсотка.
4. Розробка веб-сервісу
прийому замовлень для служб таксі
На основі налагодженого
сервера і використаних технологій була розроблена система автоматичного прийому
замовлень для служб таксі.
Система виконує функцію
автоматичного пошуку найближчого таксиста. Також в базу даних передбачений збір
різних статистичних даних, які можуть бути взяті до уваги для можливого
коригування роботи таксистів.
В процесі дослідження і
спілкування з кваліфікованими працівниками в цій області було прийнято рішення
розробити напівавтоматичну систему прийому замовлень, тобто для того, щоб
викликати машину, клієнт повинен подзвонити з мобільного або стаціонарного
телефону. Такий принцип роботи вибраний з міркувань надійності. Якщо зробити
повністю автоматичну систему замовлень (клієнт замовляє машину з веб-сайту), то
є велика вірогідність того, що багато замовлень будуть помилковими.
Другим чинником є те, що
замовлення по телефону викликають у людини більше довіри.
Інтерфейс розробленого
сайту для прийому замовлень зображений на рисунку 4.1.
Цей інтерфейс спочатку
створений для диспетчера, проте за бажанням замовника його легко можна
модифікувати різними способами і зробити сторінку для клієнта, начальника і т.
п.
У лівому верхньому кутку
екрану знаходиться область введення даних, в якій знаходиться три поля. У перші
два поля вводяться адреса виклику і номер клієнта. У третє поле вводиться
адреса призначення.
У нижній частині екрану
знаходиться карта міста. Усе що пов'язане з локацією, пошуком вільних машин і
відміткою таксистів на карті, реалізовано з використанням Maps Yandex API.
Оскільки цей проект на
момент написання магістерської роботи знаходиться в Demo-режимі, то деякі
функції в ньому відсутні. Це зроблено із міркувань того, що для кожного
замовника проект певним чином модифікуватиметься і немає сенсу створювати
повністю функціональний програмний продукт.
На карті в якості
прикладу відмічено 5 вільних таксистів в різних частинах міста. На даний момент
таксисти не можуть відзначатися самі, оскільки проект ще не введений в
експлуатацію. При необхідності відмітку таксистів можна виконати різними
способами:
за допомогою мобільного
додатку;
за допомогою
смс-повідомлення;
повідомленням по рації.
При натисненні кнопки
«Замовити» прораховуються маршрути усіх таксистів до місця замовлення, і
вибирається найближчий таксист. Також диспетчер може подивитися інформацію про
усіх таксистів. На рисунку 4.2 зображений процес вибору найближчого таксиста.
Після вибору таксиста
формується 2 смс-повідомлення: одне - таксистові, друге - клієнтові. Клієнт
може подивитись номер таксиста, марку автомобіля, час, через який прибуде
таксист і вартість проїзду. Таксист отримує номер телефону клієнта і адресу
виклику.
На даний момент ці
смс-повідомлення лише показові, але в реальному проекті досить просто додати
смс-розсилку. Існує безліч сервісів, що надають цю послугу, включаючи офіційних
операторів мобільного зв'язку.
В якості критерію вибору
найближчої машини можна визначити або мінімальну відстань, або мінімальний час
прибуття з урахуванням пробок. У цьому прототипі критерієм вибору є мінімальна
відстань.
У статистичну базу даних
заноситься інформація по кожному замовленню: номер таксиста, довжина маршруту
до точки виклику, довжина маршруту поїздки, ціна поїздки, час до точки виклику,
передбачуваний час поїздки. За бажанням замовника дані можна модифікувати, а
також надати статистику у вигляді графіку, діаграма і т. п.
Таким чином система
прийому замовлень для виклику таксі працює в демонстраційному режимі. До
моменту введення в експлуатацію планується додати необхідні деталі за бажанням
замовника, а також реальну відправку смс-повідомлень і реальну відмітку
таксистів на карті міста.
Переваги системи прийому
замовлень DoExclusiveTaxi наступні:
мала вірогідність
помилкових замовлень;
автоматичний прорахунок
маршруту, а отже економія бензину і прискорення часу поїздки;
зв'язок таксиста і клієнта
за допомогою смс.
Недоліком є випадок,
якщо клієнтові необхідно їхати в декілька точок. В цьому випадку систему треба
модифікувати, інакше не можна прорахувати приблизну ціну поїздки.
Висновки
Результати магістерської
роботи відповідають поставленим у вступі задачам. У роботі досліджений
вбудований в мобільний пристрій акселерометр і розроблений універсальний
алгоритм підрахунку фізичних вправ і збереження результатів в базу даних для
ведення спортивної статистики. Ці дослідження об'єднані в кінцевий програмний
продукт для смартфонів iPhone. Організована синхронізація статистичних даних з
сервером. Розроблена відповідна соціальна мережа з рядом певних функцій,
орієнтованих на ведення статистики. Проведена заміна сервера на новіший і
надійніший і оптимізація початкового коду веб-сервісу з метою збільшення його
швидкодії і надійності.
Кінцевий продукт
(зв'язка мобільного додатку і соціальної мережі) був протестований на реальній
аудиторії. При максимальному навантаженні на сервер від розроблених раніше
додатків для соціальної мережі (200 запитів в секунду) останній був
завантажений усього на 1%. Таким чином можна зробити висновок, що сервер з
легкістю витримає більше 1000 запитів за секунду, якщо запити будуть не більше
10 кілобайт. На момент завершення магістерської роботи (початок грудня 2012
року) SportDiary набрав 300 користувачів. За весь час не поступало жодної
критичної помилки від додатків і сервер не давав збоїв.
В якості доповнення на
базі використаних технологій була розроблена демонстраційна версія веб-сервісу
прийому замовлень для служб таксі, що повністю готова для презентації
потенційним клієнтам.
Надалі планується
розробка ще декількох додатків для мобільних пристроєв, а також розробка
додатків для соціальних мереж на базі опанованих технологій.
Перелік посилань
1. Shawn Grimes, Colin Francis. IOS 5 Recipes. A Problem-Solution
Approach. / Shawn Grimes, Colin Francis. - Apress, 2012 - p. 353.
. Томсон Л. Разработка Web-приложений на PHP и MySQL / Л. Томсон,
Л. Веллинг. - К.: «ДиаСофт», 2001. - 22 с.
. Lerner Michael. Building worldwide Web sites: [Електронний
ресурс]. - Режим доступу: http://www.ibm.com/developerworks/library/web-localization.html
. Matt Neuburg. Programming iOS 5. / Matt Neuburg. - O’Reilly,
2012 - p. 873.
. Далримпл Марк, Кнастер Скотт. Objective-C 2.0 и программирование
для Mac. / Далримпл Марк, Кнастер Скотт. - Издательский дом «Вильямс», 2010 -
с. 166.
. Документація з MySQL: [Електронний ресурс]. - Режим доступу: http://www.mysql.ru/docs/tnastroyka.html
. Wei-Meng Lee. Beginning iOS 5 Application Development. /
Wei-Meng Lee. - John Wiley & Sons, 2012 - p. 11-13.
. Patrick Alessi. Beginning iOS Game Development. / Patrick
Alessi. - Wiley Publishing, 2012 - p. 13.
. Настройка и оптимизация MySQL сервера: [Електронний ресурс]. -
Режим доступу: http://habrahabr.ru/post/108418/
. Apple Inc. iOS Human Interface Guidelines, 2012 - p. 14.
. Довідкова література з nginx: [Електронний ресурс]. - Режим
доступу: http://nginx.org/ru/
. Ling Luo, Chen Zhong, Qiao Pan Mu, Yao Huang, Xiao Sun Ling.
Improve the performance of your web applications: [Електронний ресурс]. - Режим
доступу: http://www.ibm.com/developerworks/web/library/wa-webappperformance/
13. Закон України «Про охорону праці» в редакції від 21 листопада
2002 року.
14. Жидецький В.Ц. Охорона праці користувачів комп'ютерів.
Навчальний посібник / В. Жидецький - Вид. 2-ге, доп. - Львів: Афіша, 2000 - с.
176.
. Навакатікян О.О. Охорона праці користувачів комп'ютерних
відеодисплейних терміналів / О.О. Навакатікян, В.В. Кальниш, С.М. Стрюков - К.,
1997. - с. 400.