ab(아파치 벤치마킹) 명령어 사용법

http://faq.hostway.co.kr/xe/lnx_web/293
http://duronex.tistory.com/1

ab명령어는 아파치가 설치할 때 같이 설치된다.
옵셥으로 주로 사용하는 -n은 요청수, -c는 사용자수로 생각하면 되며, URL 뒤는 반드시 /로 끝내야 한다.

ab -n 10 -c 5 http://livelog.no.de/

주요 결과는…

  • Document Length: 한 요청당 받아온 데이터 크기
  • Requests per second: 초당 처리하는 요청 수
  • Time per request: 요청당 걸린 시간
  • Percentage of requests served within a certain time: 특정 시간만큼 소요된 요청의 비율

실험해봤더니, 봄싹에 띄워둔 live.log 앱이 Joyent에 띄워둔 것보다 조금 더 빨랐다.

흠.. 근데 비가와서 그런가.. 요청 보낼때마다 결과가 좀 다르군요. 네트워크를 빼고 테스트 하려면 ab를 해당 서버 내부에서 호출해 봐야하는건가.. ??


MD5, SHA, 다이제스트, 솔트, 이터레이션

– 암호화에는 키가 주고 받는 놈끼리 같은 기법이 있고(대칭) 다른 기법(비대칭) 기법이 있다.

– Public/Private 키는 비대칭 기법이다. Public 키는 복호화할 때 쓰고, Private은 암호화 할 때 쓴다.

– 다이제스트는 목적이 좀 다르다. 복호화가 아에 안되고 오리지날 정보 확인하는 용도다.

– 일단 다이제스트할 본문이 매우 길면 위조하기 힘들겠지만, 패스워드 같이 짧은 단어는 부르트 포스로 꺨 수가 있다.

여기서 부르트 포스란… 00000 부터 zzzzz 까지 전부 다 대입해 보는거.. 무식한 공격법.. 그런데 언젠가는 돌다가 알아낼 수 있겠지.

– 숫자, 알파벳 조합 10자리 정도는 PC로 3-4이면 나온단다.

– 그래서 Salt를 사용한다.

여기서 Salt란,. 임의의 문자를 암호 앞이나 뒤에 넣어서 길이를 길게 하고 원래 암호에 추가 정보를 넣어서 암호화 하는 방법이란다.

– 그런데 만약에 솔트 마져도 2-4 자리라면.. 열심히 돌아서 뚫을 수 있다.

– 그래서 랜덤 솔트를 사용하는데.. 그렇게 되면 또 어느 부분이 솔드 인지 추측이 되니까 그걸 빼서 사용하는게 가능해진다.

– 그래서 이터레이션 기법을 사용한다. 이터레이션은 랜덤솔드+다이제스트를 또 다른 랜덤솔트를 사용해서 또다시 다이제스트 하는건데 이런식으로 한 100번 쯤 돌리면… 거의 부르트 포스로 꺠기에는 무쟈게 오래 걸릴테지만…. 만약에 비번이 00000 이면 도로묵..

결론. 비번은 숫자, 문자, 특수문자 조합해서 부르트 포스로 꺠기 어렵게 만들고, 암호화는 “256 bit SHA+랜덤 솔트+이터레이션”쯤하면 거의 완벽한 다이제스트가 됨.

MD5: Message Digest algorithm 5, http://ko.wikipedia.org/wiki/MD5

SHA: Secure Hash algorithm, http://ko.wikipedia.org/wiki/SHA-1

STS(스프링 툴 스위트) 쉽게 다운 받기

http://www.springsource.com/landing/best-development-tool-enterprise-java

다운로드 페이지로 가면 이름이며 살고 있는 나라 등을 입력하라는데 귀찮습니다. 그런데도 어쩔 수 있나요. 입력해야지 하면서 입력해왔었는데.. 이게 왠 걸… MySQL 받을 때도 마찬가지였는데 여기도 우회하는 링크가 있었네요. 쥐꼬리만하게 생긴 링크가….

1

링크 누르기 전에 약관 동의에 체크 한담에 누르셔야 합니다. 그럼 편하게 STS를 받아서 사용합시다~

ps: IntelliJ는 10.5 버전에 벌써 Java 7 지원 기능이 들어갔다고 하네요…

[maven] 버전 범위 지정 비추합니다.

아주 위험합니다. 스프링 같이 하위 호환성을 매우 잘 유지시켜주는 프레임워크나 라이브러리를 의존성으로 추가하는 경우에나 버전 범위를 지정하면 모를까.. 그 이외의 JUnit을 포함한 Twitter4J 같은 라이브러리는 전혀 하위 호환성이 유지 되지 않기 때문에 조심해야 합니다.

버전은 꼭 명시적으로!!!!


[maven] 역시 나만 불편한게 아니였어.

[xml]
<sourceDirectory>src/main</sourceDirectory>
<testSourceDirectory>src/test</testSourceDirectory>
<resources>
<resource>
<directory>src/main</directory>
</resource>
</resources>
<testResources>
<testResource>
<directory>src/test</directory>
</testResource>
</testResources>
[/xml]

 

이 코드는 스프링 소스 직원이 3.1 m1 예제 코드에서 작성한 메이븐 설정 파일인데 지금 내가 사용하고 있는 코드와 거의 비슷한 구조로(완전히 같지는 않고 설정도 뭔가 미흡해 보이지만) 사용하고 있는 코드를 발견했습니다. 이미 오래전부터 여러번 포스팅 했던 내용인지라.. 또 쓰고 싶진 않네요.ㅋㅋ

암튼.., 메이븐 기본 패키지 구조는 너무 불편합니다.

1. depth가 필요 이상으로 깊어지고.

2. 소스와 관련된 설정을 찾기가 힘들고

3. 처음 보는 사람에게는 낯설답니다.

마치 빌드계의 EJB라고 할까나.. 하지만 다행인 것은 패키지 구조를 얼마든지 설정을 사용해서 원하는 대로 고쳐서 쓸 수 있다는 거…

Plain Old Java Proejct Structure(POJPS)를 원한다!!