Деградирането на софтуера

5
3893
Автор на този материал е програмистът Джеф Гриър (Geoff Greer) от Оукланд, написал редица приложения, много от които се намират в неговото хранилище в GitHub.

Деградирането на софтуера

В книгата „Електронната епоха: работата, любовта и животът, когато роботите управляват света“ Робърт Хансън кратко се спира на деградирането на софтуера“

„Програмното осигуряване първоначално е създадено за определен кръг задачи, инструменти и ситуации. Но то бавно се променя, за да може да се справи с новия поток от задачи, инструменти и задачи. Софтуерът от този тип става сложен, крехък и в него става все по-трудно да се правят полезни промени. В края на краищата, по-добре е всичко да се започне отначало и от нулата да се напишат всички подсистеми, а понякога е по-добре и да се създадат съвсем нов тип подсистеми“.

Сигурен съм, че това е истина и нещата стоят точно така. Като правило, грамотната адаптация на софтуера към възникналите нови условия заема повече време и усилия, отколкото написването на ново програмно осигуряване от нулата. Програмистите не обичат да признават това, но доказателствата са очевидни. В 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 GIL

Python е един много добър програмен език. Той е изразителен, лесно се изучава и използва, и се поддържа в различните платформи и операционни системи. Но през последните няколко години най-популярната реализация на Python има сериозен проблем: не може да използва преимуществата на многоядрените процесори.

Причината е глобалното блокиране на интерпретатора (GIL). В документацията на Python е написано:

„В CPython глобалното блокиране на интерпретатора е мютекс, който блокира едновременното изпълнение на няколко потока код. Това блокиране е необходимо. понеже управлението на паметта в CPython не е обезопасено, когато се извършва многопоточна работа. И понеже GIL съществува и няма как да се махне, останалите функции започнаха да зависят от него“.

Първоначално GIL не е проблем. При създаването на Python почти няма многоядрени процесори и компютърни системи. А написването на GIL е лесно и това е една опростена и логична схема. Но днес даже в ръчните часовници има многоядрени процесори и GIL е очевиден и въпиещ дефект във всички отношения на този програмен език. Въпреки популярността на CPython, въпреки талантливите програмисти и разработчици, въпреки спонсорите от ранга на Google, Microsoft и Intel, никой не възнамерява да променя и оправя GIL.

Заключение

Дори при наличието на талантливи специалисти, много пари и ясен план, зрелият софтуер е твърде трудно да бъде променен. Опитах се да намеря случаи, които да опровергаят деградацията на софтуера, но не можах и изглежда няма такива. Аз наистина искам да намеря примери, които да опровергаят деградацията на софтуера, понеже без тях се очертава една твърде мрачна перспектива.

5
ДОБАВИ КОМЕНТАР

avatar
4 Коментари
1 Отговори на коментарите
5 Последователи
 
Коментарът с най-много реакции
Най-горещият коментар
5 Автори на коментарите
Ум умува, ум патки пасеНекъвbure_s_barutКольоКалин Автори на последните коментари
  Абонирай се  
нови стари оценка
Извести ме за
Калин
Калин

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

Това разбира се е перефразиране на известен цитат.

Кольо
Кольо

Едно е напълно ясно. За да се почне от начало, трябва да има идея, креативност и да се знае какво се цели. А да, напоследък има ли някой, който да пише код на ръка, а да не лепи готови шаблони, с което качеството умира, за сметка на излишният обем?

Некъв
Некъв

Да, нормалните програмисти все още не лепят шаблони.

bure_s_barut
bure_s_barut

Точно затова, когато на работа ме накарат да бутам софтуер на по 15+ години аз предлагам да го пренапишем. Ще стане по-бързо, по-лесно и по-добре отколкото да се ровя в нещо, което вече никой не знае как работи. За последно със стар софтуер работих по един MS Access от 2001 година, ако не се лъжа. Изпълних на 90% промените и фиксовете за които бях помолен, а за останалите 10% казах, че е по-добре да не го бутаме, защото иначе не гарантирам и не знам какво може да се обърка. Все пак имах само 2 седмици за промените, а това ми… Виж още »

Ум умува, ум патки пасе
Ум умува, ум патки пасе

Всичко минава в облака, приложенията се пишат основно за мобилни платформи. Като изключим професионалния софтуер, там се концентрират парите. Т.е. бъдещето на качествения софтуер за настолни и преносими компютри с „десктоп ОС“ може да се промени и да стане при следните условия или част от тях: – Създаване на нови кросплатформени ОС; – Създаване на PWA приложения, задвижвани от браузърния двигател и/или интегриране на облачни решения в десктоп среда по друг начин; – Създаване на кросплатформени бинарни формати, които да пускат приложенията на множество платформи. – Интеграция на съществуващите iOS и Android приложения в десктоп без сериозна загуба на функционалност… Виж още »