2010년 6월 18일 금요일

asp.net 성능 튜닝 (processModel)

<processModel
   enable="true"
   timeout="Infinite"
   idleTimeout="Infinite"
   shutdownTimeout="0:00:05"
   requestLimit="Infinite"
   requestQueueLimit="5000"
   restartQueueLimit="10"
   memoryLimit="60"    
   webGarden="false"
   cpuMask="0xffffffff"
   userName="machine"
   password="AutoGenerate"
   logLevel="Errors"
   clientConnectedCheck="0:00:05"
   comAuthenticationLevel="Connect"
   comImpersonationLevel="Impersonate"
   responseRestartDeadlockInterval="00:09:00"
   responseDeadlockInterval="00:03:00"    
   maxWorkerThreads="25"
   maxIoThreads="25"/>

(여기서 말하는 프로세스는 ASP.NET worker process를 말함)
   
1) enable="[true|false]"
processModel의 설정을 이용할 것인지 결정함(false일 경우 processModel설정이 무시됨)
true일 경우 웹어플리케이션이 ASP.NET worker process에서 실행되기 때문에 processModel 세팅이 이용되나, false일 경우 IIS process에서 실행되므로 이 설정이 의미가 없어진다.

2) timeout="[Infinite | HH:MM:SS]"
프로세스의 수명, 즉 얼마동안 프로세스가 실행이 되고 새로운 프로세스로 대체되는지 결정. (책에서는 이렇게 설명함 - 새 작업자 프로세스로 대체하기 전까지 구 작업자 프로세스를 얼마나 오래 살아있게 할 것인지 결정)
디폴트값인 Infinite를 사용하게 되면 한 프로세스만 쭉 사용하게 되므로, 몇일 혹은 몇주후에 프로세스 성능이 저하되는 경우는 이값을 설정하여 자동으로 새로운 프로세스를 시작하도록 한다.

3) idleTimeout="[Infinite | HH:MM:SS]"
프로세스가 어떤 작업도 처리하지 않을때 자동으로 종료되는 시간설정. Infinite일 경우 한 번 시작되면 요청이 들어오지 않더라도 종료되지 않는다.

4) shutdownTimeout="[Infinite | HH:MM:SS]"
프로세스를 kill명령(프로세스를 강제로 제거하는 저수준 명령)을 내리기전에 프로세스에게 주어진 시간.

5) requestLimit="[Infinite | number]"
프로세스가 처리할 Request개수. 이 설정값만큼 처리하게 되면 프로세스가 자동으로 재시작한다.
timeout과 비슷한 개념이지만 timeout은 시간을 기준으로 하는 반면, 이 설정은 요청 개수를 기준으로 한다.

6) requestQueueLimit="[Infinite | number]"
프로세스는 Request를 처리하기 위해 Thread를 이용하게 되는데, Thread 상태가 Request를 처리할 수 없을경우 해당 Request는 Queue에 쌓이게 된다.
만약 Queue에 쌓인 Request개수가 이 설정값을 넘어서면 프로세스를 재시작한다.

7) restartQueueLimit="[Infinite | number]"
프로세스가 재시작하는 동안 Queue에 보관한 Request개수.

8) memoryLimit="[number]"
프로세스가 사용가능한 물리적 메모리 사용율. 프로세스가 이 설정값을 넘으면 자동으로 재시작한다.
(작업관리자에 프로세스탭의 메모리사용 값과 일치)

9) webGarden="[true|false]"
다중 프로세스(CPU)를 지원하는지 여부를 결정. cpuMask값(아래에 설명)과 같이 이용.

10) cpuMask="[bit mask]"
webGarden값이 true일때 어느 프로세스를 사용할지 결정한는 bitmask이다.
먄악 CPU가 4개 있을경우 (왼쪽부터 3,2,1,0 번 CPU) 3,1,0번만 사용할려면 이 값이 1011이 되므로 16진수로 0x0000000B가 된다.
디폴트값인 Oxffffffff은 모든 CPU를 사용하겠다는 뜻이다.

11) userName="[user]", password="[AutoGenerate | password]"
프로세스가 사용할 계정. 만약 userName이 "SYSTEM"이면 localsystem의 계정(높은권한)으로 실행이 되고, "machine"이면 ASPNET 계정(낮은권한)으로 실행된다.
IIS6.0에서는 이 설정이 의미가 없다.

12) logLevel="[All|None|Errors]"
프로세스가 이벤트로그에 어떤 이벤트를 기록할 것인지 결정. "Errors"는 에러만 기록함.

13) clientConnectedCheck="[HH:MM:SS]"
Queue에 쌓여진 Request에 대해 해당 Request에 대해서 클라이언트가 연결되었는지 체크하는 시간.
체크할 당시 클라이언트가 연결되어있지 않다면 Request을 취소한다.

14) comAuthenticationLevel="[Default|None|Connect|Call|Pkt|PktIntegrity|PktPrivacy]"
DCOM 보안에 대한 인증 수준을 결정.

15) comImpersonationLevel="[Default|Anonymous|Identify|Impersonate|Delegate]"
COM 보안에 대한 인증 수준을 결정.

16) responseDeadlockInterval="[Infinite | HH:MM:SS]"
프로세스가 요청을 처리하는 동안 Deadlock이 걸릴수 있는데, 이 설정값이 지나게 되면 자동으로 빠져나오게 된다. (프로세스를 재시작함.)

17) responseRestartDeadlockInterval="[Infinite | HH:MM:SS]"
연속적인 Deadlock이 걸렸을 경우에 프로세스 재시작이 자주 일어나는것을 방지하기 위해 시간을 설정.
만약 교착 상태 문제로 프로세스가 다시 시작하면, 이 설정값 만큼의 시간이 지나야 reaponsDeadlockInterval의 값을 체크한다.
즉, 이 설정값 만큼의 시간동안은 Deadlock을 체크하지 않는다.

18) maxWorkerThreads="[number]"
프로세스는 요청을 처리하기 위해 Thread를 이용하는데 Thread pool내에 존재하는 최대 CPU당 Thread수.

19) maxIoThreads="[number]"
Thread pool내에 존재하는 최대 CPU당 IO Thread개수.

20) serverErrorMessageFile="[filename]"
프로세스가 재시작할 때, Server Unavailable 에러 메세지를 만날 수 있는데, 이 때 filename(machine.config에 대한 상대경로)을 보여준다.

출처 : http://www.xdotnet.com/xdotnet/board/BoardRead.aspx?B_Index=1109&F_Code=24&B_Code=1084&B_Page=0

2010년 3월 15일 월요일

2010년 2월 15일 월요일

enum의 Flag 연산

enum(열거형)에서는 Flag(FlagsAttribute)속성이 있는데, 이를 이용하면 하나의 속성을 선택하는 것이 아니라 여러 속성을 선택하는 것이 가능합니다.
다음의 코드는 열거형의 Flag연산을 쉽게 정리해 놓은 것입니다.

[Flags]

public enum Column

{

None = 0,

Priority = 1 << 0,

Customer = 1 << 1,

Contract = 1 << 2,

Description = 1 << 3,

Tech = 1 << 4,

Created = 1 << 5,

Scheduled = 1 << 6,

DueDate = 1 << 7,

All = int.MaxValue

};

 

[Flags] 속성을 사용하면 아래와 같은 코드가 가능합니다.(두 속성을 하나의 변수에 담는 것):

Column MyColumns = Column.Customer | Column.Contract;

 

값이 존재하는지 확인:

if((MyColumns & Column.Customer) != 0)

특정 값을 추가:
MyColumns |= Column.Tech;

 

특정 값을 제거:

MyColumns &= ~Column.Tech;

 

특정 값을 반전(1은 0으로, 0은 1로):

MyColumns ^= Column.Contract;

 

모든 값 삭제:

MyColumns = Column.None;

 

모든 값 설정:

MyColumns = Column.All;

 

특정 값을 제외하고 모두 설정:

MyColumns = Column.All ^ Column.Tech ^ Column.Status;

 

출처 : http://blog.naver.com/sjpison/150034457150

2010년 2월 1일 월요일

WCF 성능 향상 팁

WCF Performance Optimization Tips

.NET Framework 3.0 부터는 Enterprise Services 를 잘 구현할 수 있는 WCF(Windows Communication Foundation) 라이브러리를 제공합니다. 특히 최근 .NET Framework 3.5 SP1 에서는 서비스의 통합 뿐만 아니라 Enterprise Services Bus 를 구현하여 최상의 SOA(Services Oriented Architecture) 를 구현할 수 있는 프레임워크입니다.

그렇기 때문에 기존에 .NET 이 제공하던 XML Web Services 와 WCF 를 동일 선상에서 비교하거나 생각하는 것은 굉장히 위험할 수 있습니다. 가끔 BasicHttpBinding 이나 WSHttpBinding 등을 사용하여 IIS 에 호스팅 할 경우 성능에 대해 고민을 해 보신 분들도 계실 겁니다. 예전에 XML Web Service 로 잘 수행했던 프로젝트를 WCF 를 사용하여 만들었을 경우 서버가 자주 뻗는 경우도 있었을 것입니다.

   

Web Based Performance Optimization Tips

즉, 일반적으로 IIS 에 호스팅되는 Web Application 이나 XML Web Service 의 성능을 향상시키기 위해서는 Thread 나 Connection 을 늘려주는 방법으로 성능 튜닝을 할 수 있었습니다. ( default 는 .NET Framework 1.1 기준 )

  • Max Connection - default 2
  • Max IO Threads - default 20
  • Max Worker Threads - default 20
  • Min Free Threads - default 8
  • Min Local Request Free Threads - default 4

잘 모르시겠다구요~? MSDN 에 보시면 나옵니다. 각각 항목은 단지 권장 값이고 튜닝을 하기 위해서는 "추천 수치 * CPU 개수" 가 바로 최상의 성능을 낼 수 있는 Threads 나 Connection 이 됩니다. 사실 기본 값으로 서버 성능을 최상으로 발휘하기에는 무리가 있습니다.

   

WCF Based Performance Optimization Tips

하지만 WCF 에서는 이러한 성능 튜닝 방법은 전혀 다른 차원의 이야기 입니다. 왜냐하면 Web Application 이나 XML Web Service 와 달리 WCF 는 ASP.NET Pipeline(파이프라인) 을 거치지 않기 때문입니다.

Microsoft 의 WCF 개발 팀은 이런 부분에서 참 아이러니한 이야기를 합니다.

"DDos 공격을 방지하기 위함이다!" 라고...

틀린 이야기는 아니죠. ASP.NET HttpRuntime 환경을 그대로 WCF 환경으로 적용하기에는 WCF 프레임워크의 아키텍처와는 너무나 비호환적이기 때문인 것 같습니다. 다시 바꾸어 말하면, WCF 는 내부적인 ASP.NET 파이프라인을 타지 않습니다. 그렇기 때문에 기본 옵션의 Session 이나 Call 옵션으로 Service Host 가 락(Lock) 에 걸리는 상황이 옵니다.

MaxConcurrentSessions 는 Default 가 10 이므로, Closing 되지 않은 클라이언트의 세션이 이를 초과하게 되면 Lock 이 걸리게 됩니다. 아래는 간단한 예제이지만, Closing 을 잘해주더라도 Multi Thread 로 테스트를 해 보시면 금방 Lock 이 걸리게 할 수 도 있답니다.

namespace WcfService1Console

{

class Program

{

static void Main(string[] args)

{

for (int i = 0; i < 20; i++)

{

ServiceReference1.Service1Client client = new WcfService1Console.ServiceReference1.Service1Client();

Console.WriteLine(i + " " + client.GetData(3));

}

}

}

}

 

WCF 서비스는 기본값이 Max Session 이 10개에 도달하면 클라이언트의 연결을 거부합니다. Session Lock 이 걸리고 이전의 세션이 끝나야 다른 Session 의 연결을 수락하게 됩니다. WCF Session 은 HTTP Session 과 다르며, 클라이언트와 서버의 인스턴트를 연결하는 인증 매커니즘과 비슷합니다. WCF 의 SessionMode 를 NotAllowed 로 동작하도록 세션 사용을 하지 않도록 설정해도 되지만, 이러한 방법으로는 클라이언트와 서버간의 연결을 보장하지 않을 뿐이지, 실제로 세션이 연결이 되지 않는 것은 아니기 때문에, 퍼포먼스 향상을 위한 좋은 방법이라고 볼 수는 없습니다.

그리하여 WCF 의 퍼포먼스를 향상시키기 위해서는 ASP.NET 과는 별도의 Throttling 환경의 조정이 필요합니다.

<behaviors>

<serviceBehaviors>

<behavior name="WcfWsHttpSvc.Service1Behavior">

<!-- 메타데이터 정보를 공개하지 않으려면 배포하기 전에 아래의 값을 false로 설정하고 위의 메타데이터 끝점을 제거하십시오. -->

<serviceMetadata httpGetEnabled="true"/>

<serviceThrottling maxConcurrentCalls="50"

maxConcurrentSessions="50"

maxConcurrentInstances="100"/>

<!-- 디버깅 목적으로 오류에서 예외 정보를 받으려면 아래의 값을 true로 설정하십시오. 예외 정보를 공개하지 않으려면 배포하기 전에 false로 설정하십시오. -->

<serviceDebug includeExceptionDetailInFaults="false"/>

</behavior>

</serviceBehaviors>

</behaviors>

그리고 다시 테스트를 해보시면 Lock 이 걸리지 않는 것을 확인할 수 있습니다.

이 옵션은 아래와 같은 튜닝하는 것이 좋다고 가이드 합니다. 단지 권장 값이기 때문에 더 높은 값을 주어도 상관은 없습니다. 특히 MaxConcurrentInstances 는 Int32.MaxValue 값을 주셔도 됩니다. WCF 어플리케이션 서버의 배치와 Load-Balancing 을 고려하여 적절하게 주시면 됩니다.

  

기본 값

권장 값

예 (4-Core)

MaxConcurrentSessions

10

기본 값 * CPUs

40

MaxConcurrentCalls

16

기본 값 * CPUs

64

MaxConcurrentInstances

26

권장 값의 MaxConcurrentSessions + MaxConcurrentCalls

104


2010년 1월 11일 월요일

쿠키 허용 확인하기

출처 : http://user.chollian.net/~spacekan/source/cookie/cookieCheck.htm

Cookie는 사용자가 설정을 선택을 지정할 수 있습니다. 기본값으로는 선택되어 있지만 끌수도 있습니다. 그래서 cookie를 사용하여 특별한 작업을 하기 위해서는 사용자에게 cookie를 선택해 놓으라고 알려 주어야 합니다. cookie를 Client-Side, Server-Side에서 사용하던 마찬가지입니다.

ie4, ie5는 Navigator 객체의 cookieEnabled 라는 요소가 있습니다. 사용 허용은 true 값을 가지고 있고 선택을 꺼놓은 허용 불가는 false 값을 가집니다. 그래서 아래로 cookie를 사용하게 선택해 놓았는지 알 수 있습니다.

if(navigator.cookieEnabled) {
	cookie 작업 구문..
}
else alert("cookie를 꺼놓았습니다. 선택해 주세요..")
ie4, ie5에는 cookieEnabled 라는 요소로 알 수 있지만 nn4 이하는 이 요소가 없습니다. 그래서 직접적인 방법을 사용하지 않고 다른 방법을 사용하여야 합니다. 방법은 임시로 아무 cookie 값을 지정하고 그 cookie 값이 있는지 확인하는 방법입니다.
document.cookie = 1
if(document.cookie) {
	cookie 작업 구문..
}
else alert("cookie를 꺼놓았습니다. 선택해 주세요..")
cookie에 아무 값이나 지정하고 그 값을 사용하여 그것을 읽으면 굳이 cookie 지정여부를 말해주는 요소가 없어도 nn3 이상의 대부분의 브라우저에서 확인할 수 있습니다.

AJAX 강의 (링크)

출처 : http://blog.naver.com/jinoxst/140021511970

AJAX 강의 1장 - AJAX 소개

AJAX 강의 2장 - XMLHttpRequest 오브젝트 사용하기
AJAX 강의 3장 - 서버와 통신하기(요청/응답 처리)
AJAX 강의 4-1장 - 폼 입력값 검증 하기
AJAX 강의 4-2장 - 응답 헤더정보 다루기
AJAX 강의 4-3장 - 동적으로 리스트 박스 로딩하기
AJAX 강의 4-4장 - auto refresh 기능 구현하기
AJAX 강의 4-5장 - Progress Bar 기능 구현하기
AJAX 강의 4-6장 - 툴팁 구현하기
AJAX 강의 4-7장 - 동적으로 웹페이지 수정하기
AJAX 강의 4-8장 - 웹서비스 접근하기
AJAX 강의 4-9장 - 자동완성 기능 구현하기
AJAX 강의 5-1장 - JSDoc 을 이용한 자바스크립트 다큐먼트 생성하기
AJAX 강의 5-2장 - FireFox 확장기능을 이용한 HTML 코드검사
AJAX 강의 5-3장 - Dom Inspector 를 이용한 노드검색
AJAX 강의 5-4장 - 자바스크립트 소스코드 검증기 JSLint
AJAX 강의 5-5장 - 자바스크립트 파일압축 및 Obfuscation
AJAX 강의 5-6장 - Web Developer Extension for FireFox
AJAX 강의 5-7장 - 자바스크립트 심화학습/객체지향(상속)
AJAX 강의 5-8장 - 자바스크립트 심화학습/객체지향(은닉)
AJAX 강의 5-9장 - 자바스크립트 심화학습/객체지향(종합)
AJAX 강의 6-1장 - JsUnit 활용/시작하기
AJAX 강의 6-2장 - JsUnit 활용/테스트 메소드작성
AJAX 강의 6-3장 - JsUnit 활용/setUp & tearDown 메소드
AJAX 강의 6-4장 - JsUnit 활용/setUpPage 메소드
AJAX 강의 6-5장 - JsUnit 활용/Tracing and Logging
AJAX 강의 6-6장 - JsUnit 활용/page timeout 필드
AJAX 강의 6-7장 - JsUnit 활용/Progress bar 및 상태표시 필드
AJAX 강의 6-8장 - JsUnit 활용/쿼리 스트링 사용하기
AJAX 강의 7-1장 - 디버깅툴/XMLHttpRequest Debugging
AJAX 강의 7-2장 - 디버깅툴/FireFox 자바스크립트 콘솔
AJAX 강의 7-3장 - 디버깅툴/Microsoft Script Debugger
AJAX 강의 7-4장 - 디버깅툴/Venkman
AJAX 강의 7-4장 - 디버깅툴/Venkman(계속)