TNonblockingServer, TThreadedServer и TThreadPoolServer, кой е най-подходящ за моя случай?

Нашият аналитичен сървър е написан на c++. Той основно прави запитвания към основния механизъм за съхранение и връща доста големи структурирани данни чрез спестяване. Типичните заявки ще отнемат около 0,05 до 0,6 секунди, за да завършат, в зависимост от размера на заявката.

Забелязах, че има няколко опции по отношение на това кой Thrift сървър можем да използваме в кода на c++, по-специално TNonblockingServer, TThreadedServer и TThreadPoolServer. Изглежда, че TNonblockingServer е правилният начин, тъй като може да поддържа много повече едновременни заявки и все още да използва пул от нишки зад сцената, за да премине през задачите. Той също така избягва разходите за конструиране/разрушаване на нишките.

Актуализация на Facebook относно спестовността: http://www.facebook.com/note.php?note_id=16787213919

Тук във Facebook работим върху напълно асинхронен клиент и сървър за C++. Този сървър използва I/O, управляван от събития, като текущия TNonblockingServer, но неговият интерфейс към кода на приложението е изцяло базиран на асинхронни обратни извиквания. Това ще ни позволи да пишем сървъри, които могат да обслужват хиляди едновременни заявки (всяка от които изисква извършване на повиквания към други Thrift или Memcache сървъри) само с няколко нишки.

Свързани публикации за stackover: Голям брой едновременни връзки в thrift

Като се има предвид това, не е задължително да можете да вършите работа по-бързо (манипулаторите все още се изпълняват в пул от нишки), но повече клиенти ще могат да се свържат с вас наведнъж.

Просто се чудя има ли други фактори, които пропускам тук? Как да реша кой отговаря най-добре на нуждите ми?


c++ multithreading thrift nonblocking threadpool
person Community    schedule 22.08.2010    source източник
comment
Попаднах на този пост. blog.51cto.com/luckybins/1344189. Беше ми ясно.   -  person sivabudh    schedule 22.07.2018

Отговори (2)


arrow_upward
7
arrow_downward

Заявките, които отнемат 50-600 милисекунди за изпълнение, са доста дълги. Времето, необходимо за създаване или унищожаване на нишка, е много по-малко от това, така че не позволявайте този фактор да повлияе на вашето решение в момента. Бих избрал този, който е най-лесен за поддръжка и който е най-малко склонен към грешки. Искате да сведете до минимум вероятността от фини грешки в паралелността.

Ето защо често е по-лесно да се напише код за обработка на транзакции с една нишка, който блокира там, където трябва, и много от тях да работят паралелно, отколкото да имате по-сложен неблокиращ модел. Блокирана нишка може да забави отделна транзакция, но не пречи на сървъра да върши друга работа, докато чака.

Ако натоварването на вашата транзакция се увеличи (т.е. повече клиентски транзакции) или заявките станат по-бързи за обработка (доближава 1 милисекунда на транзакция), тогава разходите за транзакции стават по-голям фактор. Показателят, на който трябва да обърнете внимание, е пропускателната способност: колко транзакции са завършени за единица време. Абсолютната продължителност на една транзакция е по-малко важна от скоростта, с която те се изпълняват, поне ако остане доста под една секунда.

person Community    schedule 25.10.2011

arrow_upward
7
arrow_downward

Един човек от Github направи хубаво сравнение

TThreadedServer

TThreadedServer създава нова нишка за всяка клиентска връзка и всяка нишка остава жива, докато клиентската връзка не бъде затворена. Това означава, че ако има 1000 едновременни клиентски връзки, TThreadedServer трябва да изпълнява 1000 нишки едновременно.

TNonblockingServer

TNonblockingServer има една нишка, предназначена за мрежови I/O. Същата нишка може също да обработва заявки или можете да създадете отделен пул от работни нишки за обработка на заявки. Сървърът може да обработва много едновременни връзки с малък брой нишки, тъй като не е необходимо да създава нова нишка за всяка връзка.

TThreadPoolServer (не е тестван тук)

TThreadPoolServer е подобен на TThreadedServer; всяка клиентска връзка получава своя собствена нишка на специален сървър. Различава се от TThreadedServer по 2 начина:

Нишката на сървъра се връща в пула от нишки, след като клиентът затвори връзката за повторно използване. Има ограничение за броя на нишките. Пулът от нишки няма да надхвърли ограничението. Клиентът увисва, ако в пула от нишки няма повече налична нишка. Използването му е много по-трудно в сравнение с другите 2 сървъра.

person Community    schedule 16.02.2015