Главная | Обратная связь

Багатопотокові сервери

Хоча багатопотокові клієнти мають істотні переваги, основні переваги багатопоточності в розподілених системах забезпечуються на стороні сервера. Практика показує, що багатопотоковість не лише істотно спрощує код сервера, але й робить набагато простішою розробку тих програмних серверів, у яких для досягнення високої продуктивності потрібне паралельне виконання декількох програмних комплексів, до яких належать і мультипроцесорні системи. Навіть нині, коли мультипроцесорні комп’ютери активно випускають у вигляді робочих станцій загального призначення, використання для паралельної обробки багатопотоковості не втратило своєї актуальності.

Приклад.Щоб відчути переваги потоків виконання для написання кодів серверів, розглянемо організацію файлового сервера, який періодично блокується, очікуючи доступу до диска. Файловий сервер зазвичай чекає вхідного запиту на операції з файлами, після чого обробляє отриманий запит і повертає відповідь. Одне з можливих архітектурних рішень показано на рис. 6, на якому один з потоків виконання (диспетчер) прочитує запити на файлові операції, які надсилають клієнти із зазначенням кінцевої точки цього сервера. Після перевірки запиту сервер обирає (тобто блокує) робочий потік виконання, який перебуває у стані очікування, і передає запит йому.

Рис. 6.Багатопотоковий сервер, організований за схемою диспетчер-робочий потік.

 

Робочий потік здійснює блокуюче читання з локальної файлової системи, що призупиняє потік виконання на час читання даних з диска. На час призупинення потоку виконання керування може бути передане іншому потоку виконання, наприклад потоку-диспетчеру або диспетчер може обрати інший готовий до запуску робочий потік.

Структура з диспетчером – не єдиний спосіб організації багатопотокового сервера. У моделі «команда» всі потоки виконання еквівалентні, кожен отримує й обробляє власні запити (рис.7). Іноді завдання надходять, а потрібний потік зайнятий, зазвичай це відбувається, коли кожен потік спеціалізується на виконанні особливого виду робіт. У цьому разі створюється черга незавершених робіт, за якої потоки виконання мають спочатку переглядати чергу робіт, а потім виконувати завдання, яке щойно надійшло.

Рис. 7.Багатопотоковий сервер, який працює за схемою «команда».

 

Потоки виконання можуть також мати організацію розкладу обчислень у вигляді конвеєра (рис.8), за якої перший потік породжує деякі дані й передає їх для обробки наступному потоку виконання і т. д. Незважаючи на те, що така організація і не підходить для файлового сервера, для інших завдань, зокрема задач «виробник-споживач», це рішення є ефективним.

Рис. 8. Багатопотоковий сервер, який працює за схемою «конвеєр».

 

Розглянемо, як файловий сервер міг би виконувати запис, якщо немає потоків виконання. Одна з можливостей – виконувати обчислення так, ніби файловий сервер працює з єдиним потоком виконання. Основний потік файлового сервера отримує запит, перевіряє його і передає на виконання раніше, ніж отримає наступний. Поки сервер чекає закінчення дискових операцій, він не обробляє інших запитів від клієнтів. Крім того, якщо файловий сервер працює на віддаленій машині, то процесор під час дискових операцій не зайнятий, у результаті чого обробляється значно менша кількість запитів за секунду. Таким чином, потоки виконання забезпечують суттєве підвищення продуктивності, не зважаючи на те, що вони запускаються на виконання по черзі.

Наявні такі можливі організації обчислювального процесу на сервері: багатопотоковий і однопотоковий сервер або потоків виконання немає зовсім, але за умови, коли спадання продуктивності через використання однопотокової архітектури робить її застосування можливим. За іншої організації обчислювального процесу сервер використовують як великий кінцевий автомат (рис.9).

Рис.9. Алгоритм роботи кінцевого автомата.

 

Після надходження запиту його перевіряє єдиний потік виконання, якщо всі команди запиту не можливо обробити в кеші, то відбувається звернення до до дискової системи. Проте, замість блокування потік виконання записує стан поточного запиту в таблицю і переходить до стану очікування й отримання нового повідомлення. Нове повідомлення може бути як запитом на здійснення нової операції, так і відповіддю на попередній запит від дискової підсистеми. Якщо це новий запит, то починається нова робота, якщо це відповідь від диска, то з таблиці вилучається відповідна інформація, відповідь формується і передається клієнтові. Згідно з цією схемою сервер має мати можливість здійснювати неблокуючі виклики send і receive.

У такій архітектурі моделі «послідовних процесів» немає. Стан обчислень для кожного повідомлення, яке приймається і відправляється, має повністю зберігатися і отримуватися з таблиці, у результаті чого потоки виконання та їх стеки складно моделювати. Процес, який протікає в кінцевому автоматі, полягає у фіксації подій і, залежно від їх типу, реакції на ці події.

Потоки виконання уможливлюють одночасне збереження ідеї послідовних процесів, які здійснюють блокуючі системні виклики (як і під час викликів RPC для роботи з диском), і паралельної роботи. Блокуючі системні виклики спрощують програмування, а паралельність обробки потоків підвищує продуктивність. Однопотокові сервери зберігають простоту блокуючих системних викликів, але втрачають у продуктивності. Підхід, використовуваний у кінцевих автоматах, дозволяє завдяки паралелізму досягти високої продуктивності, але через наявність неблокуючих викликів важко програмується (див. табл.1).

Таблиця 1. Способи побудови сервера

Модель	Характеристики
Потоки виконання	Паралельність обробки потоків, блокуючі системні виклики
Однопотоковий процес	Немає паралелізму, блокуючі системні виклики
Кінцевий автомат	Паралелізм, не блокуючі системні виклики

Клієнти