오늘 할일
1. 랜섬웨어 발표자료 준비
2. 데이터 베이스 공부
3. Project-X
4. Project-X 과제
5. 고급 웹 프로그래밍 과제
6. 사상의학 과제 시작
7. 진로동아리 서류제출
8. 데이터 통신 증빙서류제출
오늘 한일
1. 랜섬웨어 실행속도 중앙값 측정(StarCraft파일 5.61GB, 10회, 단위: 초)
1-1. 50MB이상 멀티스레딩.......: 40.3 40.3 40.6 40.7 40.9 40.9 41.0 41.0 41.1 41.6 (mid: 40.9)
1-2. 50MB이상 멀티스포세싱..: 41.5 41.5 41.5 41.7 41.8 41.8 41.9 42.0 42.1 42.1 (mid: 41.8)
1-3. 디렉토리별 멀티스레딩.....: 40.0 40.1 40.1 40.1 40.4 40.7 40.9 41.1 41.3 44.4 (mid: 40.4)
1-4. 디렉토리별 멀티프로세싱: 43.9 44.0 44.0 44.5 44.6 44.7 45.3 45.9 46.0 47.2 (mid: 44.6)
1-5. 일반실행..................................: 39.9 39.9 40.0 40.0 40.2 40.2 40.2 40.5 40.8 41.5 (mid: 40.1)
분석: 같은 파일을 반복적으로 접근하기에, 캐시 메모리 정보를 사용하여 가장 마지막에 실행 한 일반 실행의 결과가 가장 좋게 나왔다. 만약 위의 가설이 맞다면 컴퓨터를 재부팅 후 실행했을 때 속도가 다소 느려질 것이다.
1-6. 재부팅 후 일반 실행: 40.0 40.6 41.0 41.2 41.4 41.5 42.0 43.4 43.4 45.2 (mid=41.4)
분석: 예상한 바와 같이 전보다 느리게 나왔다. 1~4의 실험을 거치며 어느정도의 속도 향상의 원인이 만들어졌을 거라고 보지만, 차이가 유의미 할 정도로 크지 않다.
어느 방식으로 암호화 할 것인지 이제는 결정해야한다. 우선 5가지 방법 중 가장 시간이 오래걸린 디렉토리 별 멀티프로세싱은 제외한다.
또한 실험을 진행하며 얻어낸 또 다른 사실은 디렉토리 별 병렬작업은 파일 크기를 기준으로 한 병렬작업보다 훨씬 많은 스레드가 생성되었다. 파일 크기 기준 스레드는 7번 생성되는 반면, 디렉토리 기준으로는 27번 생성되었다. 두가지 방식의 실행 속도에 큰 차이가 없다면 자원을 절약하기 위해 디렉토리 별 멀티스레딩 역시 제외한다.
아래는 이전에 진행한 실험의 결과이다.
위에 10회의 중앙값을 측정한 실험과, 이전의 실험 결과를 봤을 때, 50MB이상 파일을 기준으로 한 병렬작업에서 멀티 프로세싱보다 멀티 스레딩이 더 빠른 작업을 수행하는 것을 볼 수 있다. 고로 50MB이상 기준 멀티 프로세싱을 제외한다.
최종적으로 선택한 병렬진행 방식은 50MB이상 파일 기준 멀티 스레딩이다. 여기서 추가적으로 생각해야할 사항은 일반 실행 결과가 50MB이상 파일 기준 멀티 스레딩 결과보다 빠르다면 병렬작업을 추가할 필요가 없다는 것이다. 다만 위의 실험에서 이전에 실행한 결과가 영향을 끼치는 것 같다는 가설이 있었기에 해당 가설을 보완하여 재부팅 후 50MB이상 파일 기준 멀티 스레딩의 속도를 재측정하겠다.
1-7. 재부팅 후 50MB이상 파일 기준 멀티 스레딩: 39.5 40.0 40.1 40.5 40.7 40.8 40.8 41.1 41.4 45.9 (mid: 40.7)
분석: 재부팅 후 실험한 1-6, 1-7의 중앙값을 비교해보았을 때 50MB이상 파일 기준 멀티 스레딩이 일반 실행 결과보다 다소 빠른 것을 알 수 있었다.
결론: 50MB이상 파일 기준 멀티 스레딩을 병렬처리 진행 방식으로 채택한다.
맡은 파트 정리해서 발표ppt에 업로드
중요 논리 오류 발견
문제는 시연 영상을 녹화하는 도중 발견하였다.
thread를 사용하였는데 tkinter창이 종료될 때 까지 암호화가 시작되지 않는 문제를 발견하였다.
문제는 스레드 생성 시에 있었는데, 해당 경고창을 실행시키는 코드는 아래와 같았다.
task_thread = threading.Thread(target=fakeAlert())해당 target함수 설정 시 함수를 실행시켜 버리기 때문에 실행시킬 함수를 저장하는 과정에서 단순 실행되어 멀티 스레드가 제대로 작동하지 않는 것이었다. 해당 코드는 아래와 같이 작성하므로서 디버깅이 가능했다.
task_thread = threading.Thread(target=fakeAlert)문제는 지금 까지 실행해왔던 모든 코드를 위와 같은 스타일로 잘못 작성했다는 것이다. 그래서 클래스 메서드를 넣어보려했지만, 일반 함수와는 달리 클래스 메서드를 넣어 스레드 생성하는 과정에서 문제가 발생했다. 해당 문제는 @classmethod 어노테이션을 사용하여 static메서드를 사용하게 끔 리팩토링하여 해결하였다.
class Encryptor:
def __init__(self, files=0):
self._files=files
@classmethod
def encEach(self, path):
with open(path, "rb") as File:
data=File.read()
encryptedFile=EncryptModule.encrypt(data)
with open(f"{path}.LoL", "wb") as File:
File.write(encryptedFile)
os.remove(path)
def encryptFile(self):
try:
for file in self._files:
if(os.path.isfile(file)==True):
if(file==sys.argv[0]):
return
if(os.path.getsize(file)>500000000):
th=Thread(target=Encryptor.encEach, args=(file,))
ThreadPool.append(th)
th.start()
#self.encEach(file)
else :
self.encEach(file)
except Exception as e:
print(f"[DEBUG] Error on EnDecrypt.encryptFile(): {e}")모듈을 생성자로 입력받는 방식과 달리 전역 변수를 사용하여 초기화하게 하여 static method로 재생성하였다. 이는 복호화하는 Client_after_enc.py역시 수정하였다. 문제는 실험을 처음부터 다시 해야한다는 것이다. 또한 기존에 실험할 때 사용했던 StarCraft파일을 메모리 부족으로 삭제해 버린 탓에 새로운 데이터 파일을 구해야했다.
디버깅 과정에서 일부만 암호화 된 경우 Client_after_enc.py에서 .LoL이 아닌 파일에 대하여 Exception을 발생시키는 문제가 추가로 발생하였다. 해당 문제는 아래와 같이 해결하였다.
extension=os.path.splitext(file)[-1]
if(extension!='.LoL'):
continue;문제는 enc와 dec를 분리한지라 테스트 자동화를 위해 둘을 합쳐서 새 스크립트를 만들어야 할 듯 하다.
3차실험 진행. 510MB 10회. 디렉토리 기반은 이전 실험결과에서 스레드가 너무 많이 생성됐기에 배제.
1. 일반실행: mid 5.92
2. 50MB 멀티스레딩: mid 5.24
3. 50MB 멀티프로세싱: mid 6.79
분석: 일반 실행에 비해 50MB이상 파일 기준 멀티 스레딩이 12%빠른 속도를 수행했고, 이전 실행결과와 비슷하게 50MB이상 파일 기준 멀티프로세싱은 14%느린 속도를 기록했다. Thread함수의 target 논리오류를 발견해서 디버깅 후, 이전보다 작은 용량의 파일을 타겟으로 재측정을 해보니 일반 실행 결과보다 50MB 멀티스레딩이 더 빠른 작업을 수행한다는 점을 알 수 있었다.
추가적으로, 이전의 5.6GB였던 StarCraft 파일과의 속도 비교를 위해 비례식을 이용해 위의 실험 결과를 10.98배한 결과는 아래와 같다.
- 일반실행: mid 65
- 50MB 멀티스레딩: mid 57.54
- 50MB 멀티프로세싱: mid 74.55
이전 StarCraft파일보다 느린 속도이지만, 파일 구조의 차이로 인한 속도 차이로 보인다. 추후 보다 다양한 디렉토리 구조에서의 실행이 필요해 보인다.
결론: 멀티스레드를 다루는 부분에서 논리 오류를 디버깅 후, 510MB파일 기준 속도 측정을 다시 해보았는데 일반 실행보다 50MB이상 파일 기준 멀티 스레딩이 약 12% 빨랐다. 다만 아쉬운 점은 기존에 테스트파일인 5.6GB의 StarCraft파일이 아닌 510MB의 다른 파일(강의자료)로 대체되었다는 점이다. 이는 강의 자료 파일 외에 더 큰 용량의 데이터로 새로이 실험 데이터를 쌓아가며 분석해야 한다.
