Деградирането на софтуера
В книгата „Електронната епоха: работата, любовта и животът, когато роботите управляват света“ Робърт Хансън кратко се спира на деградирането на софтуера“
„Програмното осигуряване първоначално е създадено за определен кръг задачи, инструменти и ситуации. Но то бавно се променя, за да може да се справи с новия поток от задачи, инструменти и задачи. Софтуерът от този тип става сложен, крехък и в него става все по-трудно да се правят полезни промени. В края на краищата, по-добре е всичко да се започне отначало и от нулата да се напишат всички подсистеми, а понякога е по-добре и да се създадат съвсем нов тип подсистеми“.
Сигурен съм, че това е истина и нещата стоят точно така. Като правило, грамотната адаптация на софтуера към възникналите нови условия заема повече време и усилия, отколкото написването на ново програмно осигуряване от нулата. Програмистите не обичат да признават това, но доказателствата са очевидни. В open source проектите има няколко много известни примера.
Многопроцесният FirefoxВ началото Mozilla Firefox стартираше всичко в един единствен процес. Но след излизането на Google Chrome стана ясно, че моделът с няколко процеса повишава информационната безопасност и производителността. Веднага след това разработчиците на Mozilla започнаха да планират реализирането на многопроцесна работа в браузъра Firefox. Това се случи през 2007 година.
След около десет години Mozilla най-после представи многопроцесен Firefox за масовата аудитория. Това забавяне бе не поради липса на желание или нещо друго. Mozilla разполага с талантливи и способни разработчици и програмисти. Но въпреки това, Chrome бе написан буквално от нулата за далеч по-малко време, отколкото бе нужно на Firefox да осъществи планираните промени. Причините за това в основни линии са две:
- Преобразуването на еднопроцесната архитектура в многопроцесна изисква голям брой малки промени. Някои извиквания на функции трябва да бъдат заменени с междупроцесни комуникации. Общото състояние трябва да бъде пронизано от мютекси. Кешовете и локалните бази данни трябва да поддържат паралелен достъп
- Firefox трябва да запази съвместимостта със съществуващите разширения (или разработчиците ще трябва да ги обновят). Google създаде API за Chrome от нулата, без да има притеснения от подобен род
Но ситуацията всъщност е още по-зле. Ограниченията си противоречат едно на друго: необходимо е да бъде престроена вътрешната архитектура, но общодостъпните API трябва да останат без изменения. Не е за учудване, че Mozilla имаше нужда от цели десет години, за да извърши този подвиг.
Събитийно-ориентираният ApacheПървоначално Apache httpd работеше по модела „един поток на една сесия“. Един и същ процес слуша порт 80, след това извършва accept() и fork(). След това един дъщерен процес изпълнява read() и write() в рамките на сесията. Когато заявката приключи, дъщерният процес затваря сесията с close() и се излиза с exit().
Тази архитектура е опростена и лесна за реализиране на всички платформи. И това е всичко. Тя е абсолютно ужасна за производителността, особено при дълготрайни свързвания с дълги сесии. Но все пак това бе през 1995 година. Малко след това Apache премина към многонишков модел, който подобри производителността. Въпреки това, той не може да обработва 10 000 едновременни връзки. Архитектурата „един поток на една връзка“ изисква 1000 потока за обслужването на 1000 връзки. А всеки поток си има собствен стек и състояние, той трябва да е планиран и стартиран от операционната система. А това отнема време.
Точно обратното, Nginx още от самото начало използва Шаблона на реактора. Това му дава възможност още от самото начало да обработва повече едновременни връзки и да го направи неустойчив към Slowloris атаките.
Nginx излезе през 2007 година и неговите преимущества и производителност бяха очевидни. Няколко години преди излизането на Nginx разработчиците на Apache започнаха да преправят httpd с цел повишаване на производителността. Многопроцесният модул event се появи през 2005 година във версия Apache 2.2. Но се оказа, че има проблеми със съвместимостта. И най-лошото бе, че той провали съвместимостта с най-популярните модули, като например mod_php. Програмистите не можаха да се справят с този проблем до 2012 година, когато излезе Apache 2.4, включващ този модул (MPM) по подразбиране. Въпреки че всичко работеше много по-добре, в сравнение с предишните prefork и MPM, полученото въобще не можеше да се сравни с производителността на Nginx. Вместо шаблона на реактора, Apache използва отделни пулове от потоци, за да слуша и приема съединенията и да обработва заявките. Не се получи чак толкова добре.
CPython GILPython е един много добър програмен език. Той е изразителен, лесно се изучава и използва, и се поддържа в различните платформи и операционни системи. Но през последните няколко години най-популярната реализация на Python има сериозен проблем: не може да използва преимуществата на многоядрените процесори.
Причината е глобалното блокиране на интерпретатора (GIL). В документацията на Python е написано:
„В CPython глобалното блокиране на интерпретатора е мютекс, който блокира едновременното изпълнение на няколко потока код. Това блокиране е необходимо. понеже управлението на паметта в CPython не е обезопасено, когато се извършва многопоточна работа. И понеже GIL съществува и няма как да се махне, останалите функции започнаха да зависят от него“.
Първоначално GIL не е проблем. При създаването на Python почти няма многоядрени процесори и компютърни системи. А написването на GIL е лесно и това е една опростена и логична схема. Но днес даже в ръчните часовници има многоядрени процесори и GIL е очевиден и въпиещ дефект във всички отношения на този програмен език. Въпреки популярността на CPython, въпреки талантливите програмисти и разработчици, въпреки спонсорите от ранга на Google, Microsoft и Intel, никой не възнамерява да променя и оправя GIL.
ЗаключениеДори при наличието на талантливи специалисти, много пари и ясен план, зрелият софтуер е твърде трудно да бъде променен. Опитах се да намеря случаи, които да опровергаят деградацията на софтуера, но не можах и изглежда няма такива. Аз наистина искам да намеря примери, които да опровергаят деградацията на софтуера, понеже без тях се очертава една твърде мрачна перспектива.
