Огляд існуючих розробок веб-сервісів ведення спортивної статистики і програмного забезпечення прийому замовлень для служб таксі

- 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:

- 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].

Нижче описані рекомендації до роботи з таблицями для досягнення більшої продуктивності:

1. По можливості усі поля декларувати як NOT NULL. Це зробить роботу з таблицями швидшою і збереже 1 біт на кожне таке поле.

2. Застосовувати значення за умовчанням (DEFAULT). При виклику запиту INSERT в таблицю записуватимуться тільки ті поля, значення яких відрізняються від DEFAULT.

3. Використовувати настільки малі типи INT, наскільки це можливо.

4. При використанні декількох послідовних INSERT запитів, краще усі дані вказати в одному INSERT, чим робити декілька INSERT [6].

Конфігураційний файл MySQL можна подивитися в доповненні Б.

В ході розробки та тестування проекту було поставлене питання використовувати G++ чи PHP. Виявилося, що швидкість роботи при використанні G++ на порядок швидше, але за умовою, що немає звертання до банку даних. Якщо йде звертання до банку даних, то час обробки однаковий.

Графік залежності кількості оброблюваних запитів в секунду від вибраної технології зображений на рисунку 3.2.

Тестування проводилося за допомогою утиліти Apache Bench (ab). Такого роду тест не дає результату, наближеного до реальності, оскільки у реальному режимі користувачі звертаються до різних скриптів, а також до статичних об'єктів. Також ця утиліта не враховує ширини каналу. Але для порівняння двох технологій вона є прийнятною.



Графік залежності кількості оброблюваних сервером запитів від вибраної технології

При запиті до двох скриптів на G++ і PHP з однаковою функціональністю і без звернення до бази даних співвідношення кількості запитів до стрипту в секунду можна виразити формулою:

G = 20*P, (4.1)

де G - кількість запитів до скрипта на G++, P - кількість запитів до скрипта PHP в секунду.

При запиті до двох скриптів з однаковою функціональністю, але із зверненням до бази даних, співвідношення кількості запитів можна виразити формулою:

G ? P (4.2)

Таким чином залежність можна об'єднати в одну формулу:

G = 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]. Виходячи з попереднього досвіду програмування, він є найбільш зручним і ефективним.

3.2 Розробка соціальної мережі і забезпечення її взаємодії з мобільним додатком

За своїмі функціональними можливостями соціальна мережа www.sportdiary.net практично ідентична з тією, яка вбудована в мобільне застосування. У неї є тільки дві додаткові функції:

1) коментування статистики користувачів;

2) вхід в соціальну мережу під логіном і паролем, виданим в мобільному додатку.

Інтерфейс соціальної мережі sportdiary.net зображений на рисунку 3.3.

Для синхронізації мобільного застосування з сайтом були розроблені спеціальні API.

Для того, щоб відправити якісь дані на сервер з мобільного додатку необхідно виконати POST-запит по вказаному посиланню і передати в тілі запиту необхідні дані. Для того, щоб отримати якісь дані від сервера, необхідно виконати GET-запит і отримати дані у відповідь у вигляді JSON-масиву.

Нижче наведений приклад GET-запиту перевірки наявності Інтернету:

int num = rand();

NSString * request = [NSString stringWithFormat:@ «http://sportdiary.net/api/isinet.php? rand=%i», num];

NSData* data = [NSData dataWithContentsOfURL:

[NSURL URLWithString: request]];

Усі URL-запити передаються на сервер nginx, який у свою чергу виконує усі PHP-скрипты в режимі FastCGI. Виконаний скрипт передає вихідні дані в сокет, з якого прочитується JSON-массив, що потрапляє в об'єкт NSData* data.

Вміст скрипта isinet.php приведене нижче:

<?

echo ' {«status»: «ok»}';

?>

Таким чином, якщо цей скрипт викликався, то у будь-якому випадку додатку вдалося з'єднатися з сервером, і Інтернет є. Інакше об'єкт отримає невизначені дані.

Аналогічні API-функції розроблені для наступних дій:

- перевірка Інтернету;

- отримання логіна і пароля;

- видалення або додавання вправи;

- зміна фотографії;

- зміна імені;

- синхронізація статистичних даних;

- завантаження користувачів;

- підписка на користувачів;

- завантаження новин;

- пошук користувачів;

- завантаження статистики користувачів.

Робота усіх скриптів була протестована. Усі дані синхронізуються справно і абсолютно аналогічні для мобільного застосування і соціальної мережі. На рисунках 3.4 і 3.5 зображений інтерфейс вкладки «Користувачі» мобільного застосування і сайту відповідно.

Інтерфейс вкладки «People» в мобільному додатку SportDiary

Як видно з приведених рисунків, дані синхронізовані коректно і є однаковими.

Аналогічно синхронізуються статистичні дані по кожному користувачеві. Дані з локальної бази SQLite мобільного додатка SportDiary відправляються на сервер за допомогою POST-запиту і переписуються в базу даних SQL на сервері. Структура бази даних за статистикою аналогічна тій, яка була описана в мобільному застосуванні. Відмінністю є таблиця користувачів, в якій зберігаються наступні дані:

- ім'я користувача;

- id користувача;

- логін користувача;

- пароль користувача.

Також в базі даних зберігаються деякі дані для взаємодії з іншими соціальними мережами, але ці дані у рамках магістерської роботи неважливі.

При перегляді статистики на сайті статистичні дані підвантажуються з бази даних на сервері і відображуються на екрані за допомогою вільної бібліотеки jQuery jqplot.

Графік статистики на сайті sportdiary.net

3.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.

2. Томсон Л. Разработка Web-приложений на PHP и MySQL / Л. Томсон, Л. Веллинг. - К.: «ДиаСофт», 2001. - 22 с.

3. Lerner Michael. Building worldwide Web sites: [Електронний ресурс]. - Режим доступу: http://www.ibm.com/developerworks/library/web-localization.html

4. Matt Neuburg. Programming iOS 5. / Matt Neuburg. - O'Reilly, 2012 - p. 873.

5. Далримпл Марк, Кнастер Скотт. Objective-C 2.0 и программирование для Mac. / Далримпл Марк, Кнастер Скотт. - Издательский дом «Вильямс», 2010 - с. 166.

6. Документація з MySQL: [Електронний ресурс]. - Режим доступу: http://www.mysql.ru/docs/tnastroyka.html

7. Wei-Meng Lee. Beginning iOS 5 Application Development. / Wei-Meng Lee. - John Wiley & Sons, 2012 - p. 11-13.

8. Patrick Alessi. Beginning iOS Game Development. / Patrick Alessi. - Wiley Publishing, 2012 - p. 13.

9. Настройка и оптимизация MySQL сервера: [Електронний ресурс]. - Режим доступу: http://habrahabr.ru/post/108418/

10. Apple Inc. iOS Human Interface Guidelines, 2012 - p. 14.

11. Довідкова література з nginx: [Електронний ресурс]. - Режим доступу: http://nginx.org/ru/

12. 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.

15. Навакатікян О.О. Охорона праці користувачів комп'ютерних відеодисплейних терміналів / О.О. Навакатікян, В.В. Кальниш, С.М. Стрюков - К., 1997. - с. 400.

Размещено на Allbest.ru