Как работи epoll

системни ресурси

Думата epoll определено е модна дума в момента, главно поради нарастването на популярността на неблокиращите HTTP сървъри. В същото време малко хора се опитват да разберат какво всъщност стои зад него и защо продуктите, използващи този механизъм, сред които например nginx, node.js и Tornado, заемат достойно място, така че значително надминават най-близките алтернативи в изпълнението. Искате да копаете по-дълбоко?

Какво ще бъде обсъдено?

  • epoll е мащабируема, не блокираща I/O система за уведомяване в Linux. За разлика от по-старите механизми, времето за реакция на epoll не зависи от броя на дескрипторите на отворени файлове.
  • epoll използва се за обработка на неблокиращи събития на TCP сокет, операционната система уведомява приложението, когато един от наблюдаваните сокети е готов да получи или изпрати съобщение. В традиционния подход за всеки сокет се разпределя нишка, която блокира, докато повикването се върне към съответния сокет.

Какво дава?

  • Няма нужда да губите системни ресурси за създаване, унищожаване и поддържане на пул от нишки.
  • Един системен процес може да поддържа значително повече TCP връзки.
  • Дългосрочните връзки, които рядко получават съобщения, не съдържат блокиран поток и консумират минимум системни ресурси.
  • Няма проблеми със синхронизирането на пула от нишки и достъпа до споделена памет.
  • Способността (но не и необходимост) без допълнителни усложнения да запази някакво общо състояние в паметта на процеса, ако приложението го изисква.

но от друга страна

  • Изпълнителните нишки в блокиращия модел имат относително кратък жизнен цикъл и рано или късно освобождават разпределената им памет, процесът на обработка на неблокиращи връзки живее много по-дълго и е много по-уязвим от изтичане на памет.
  • Използването на един системен процес без пул от нишки ограничава приложението само до едно ядро ​​на процесора, което прави този подход по-малко подходящ за приложения, които консумират много изчислителни ресурси. В повечето случаи приемливо решение е да стартирате няколко еднакви копия на приложението на един и същ сървър по броя на процесорните ядра.
  • Грешките в кода могат да повлияят отрицателно на работата на целия процес на приложение, докато в блокиращ модел нишките на изпълнение обикновено са доста изолирани една от друга.