BG Development


Страници: (2) 1 [2]   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Криптиран backup - Ubuntu
gat3way
Публикувано на: 12-02-2018, 11:02
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 2579
Регистриран на: 22.06.12



Абе ако пайпването беше между процеса дето компресира и процеса дето криптира и няма никъде включено IO, тогава е очевиден проблем - овърхеда от превключване на контексти, копиране на памет и т.н. Когато включим и дисковото и мрежовото IO, тези неща спират да имат толкова значение - дори вариант с няколко процеса дето си комуникират през пайпове най-вероятно ще се окаже по-бърз (доколкото разликата има значение) от тривиалната имплементация всичко в едно където имаш блокиращо четене -> gzip компресия -> блоков шифър -> писане в блокиращ сокет. Защо - то е очевидно защо, защото докато чакаш да ти се изчете или засили по мрежата, стоиш и не правиш нищо. Сега разбира се ще кажеш "да, ама няма да го правим така, ще го оптимизираме". Разбира се, но ще се вкараш в приличен филм докато го сътвориш това, заради разни противни подробности. Първо, за да ти е ефективна компресията, трябва да имаш достатъчно голям "прозорец" от вече изчетени неща от диска, за да можеш да кодираш ефективно всеки байт с колкото битчета там, все пак gzip-а ползва хъфманови дървета и прочее глупутки. Т.е няма да е баш най-лесното с неблокиращото четене дето за всичко изчетено от дескриптора караш по общия ред, трябва да си организираш буфериране като хората, после при gzip-а се ползват плъзгащи се прозорци и това допълнително ще ти сговни живота с въпросното буфериране. Още повече ще ти го сговни факта че криптирането е с блоков шифър и работи с вход с фиксирана дължина, няма как да запратиш произволен вход през това. И gzip компресията, и блоковия шифър в повечето ползвани режими са ужасно неподатливи на паралелизиране неща и там няма да успееш да се пребориш за нищо. И накрая имаш засилването на резултата през неблокиращия сокет, където трябва да прихващаш всякакви несгоди и да им реагираш правилно, например FTP подържа REST и най-доброто като се счупи сокета не е да изревеш и да почнеш отначало, а да продължиш оттам откъдето си стигнал.

Та като цяло далеч не е невъзможно, то дори е много добро занимание за програматори които държат да се себедоказват. Въпросът е че като цяло, няма да намажеш особено от цялото упражнение, освен че строшиш ненужно много време и усилия и ще сътвориш нещо, на което ще му оправяш бъговете и частните случаи още сума време. Овърхеда от контекст суичването и копиранията в крайна сметка е нищо на фона на мрежовото I/O и дали крайният резултат ще е с 2-3% по-бърз - никой няма да се трогне от това според мен.
PMEmail Poster
Top
1 потребители преглеждат тази тема в момента (1 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) 1 [2]  Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2018 | BG Development | All Rights Reserved
RSS 2.0