yoonji.jang's Blog

[WINDOWS] 하루전 날짜 구하기

Fri, 22 Jan 2010 15:21:58 +0900

출처 : http://nkpower.textcube.com/42

set yyyy=%DATE:~0,4%

set mm=%DATE:~5,2%

set dd=%DATE:~8,2%

set dayCnt=1

REM substract your days here

set /A dd=1%dd% - 100 - %dayCnt%

set /A mm=1%mm% - 100

:CHKDAY

if /I %dd% GTR 0 goto DONE

set /A mm=%mm% - 1

if /I %mm% GTR 0 goto ADJUSTDAY

set /A mm=12

set /A yyyy=%yyyy% -1

set /A mm=12

set /A yyyy=%yyyy% - 1

:ADJUSTDAY

if %mm%==1 goto SET31

if %mm%==2 goto LEAPCHK

if %mm%==3 goto SET31

if %mm%==4 goto SET30

if %mm%==5 goto SET31

if %mm%==6 goto SET30

if %mm%==7 goto SET31

if %mm%==8 goto SET31

if %mm%==9 goto SET30

if %mm%==10 goto SET31

if %mm%==11 goto SET30

REM ** Month 12 falls through

:SET31

set /A dd=31 + %dd%

goto CHKDAY

:LEAPCHK

set /A tt=%yyyy% %% 5

if not %tt%==0 goto SET28

set /A tt=%yyyy% %% 100

if not %tt%==0 goto SET29

set /A tt=%yyyy% %% 400

if %tt%==0 goto SET29

:SET28

set /A dd=28 + %dd%

goto CHKDAY

:DONE

if /I %mm% LSS 10 set mm=0%mm%

if /I %dd% LSS 10 sset dd=0%dd%

set logDate=%yyyy%-%mm%-%dd%

set YY=%logDate:~2,2%

set MM=%logDate:~5,2%

set DD=%logDate:~8,2%

REM IIS 로그파일명

echo ex%YY%%MM%%DD%.log

닷넷 페이지 실행시간 제어

Fri, 15 Jan 2010 16:32:21 +0900

아래 내용은 2003서버 + IIS 6.0 (닷넷 프레임워크 1.1) 기반에서 테스트된 것입니다.

ASP.NET 페이지 실행시간에 대한 내용이며, 스크립트(aspx)와 웹서비스(asmx)
페이지 실행시간은 기타 문서의 내용대로 동작하였으나,
DB와 SAP의 실행문 제어는 의도대로 결과가 나오지 않아,
정확한 내용을 올려드리지 못하였습니다.

필요한 부분만 참고하시기 바랍니다.

※ Session Timeout 과 Page Execution Timeout 은 전혀 다른 내용이니,
혼란이 없길 바랍니다.

[공통]
실행중인 페이지에서 제한시간의 초과로 인해, Exception이 발생한 경우
클라이언트에 System.Web.HttpException 이 전달된다.
-------------------------------------------------------------------
System.Web.HttpException: Request timed out
-------------------------------------------------------------------

[Case 1] ASP.NET 페이지 실행시간 I

[web.config]
----------------------------
compilation defaultLanguage="c#" debug="true"
httpRuntime executionTimeout="90"

[결과]
페이지 실행이 끝날때까지 계속 실행
[원인]
In debug mode the timeout is 30,000,000 seconds which is about a year
[해결]
페이지 실행의 제한시간을 적용하고자 할 경우, compilation debug 속성을 반드시 false로 한다
이외에 개발환경에서 운영환경으로 적용할때는 runtime 성능문제로 인해 반드시 debug="false" 를 적용하도록 한다.

[Case 2] ASP.NET 페이지 실행시간 II

[web.config]
----------------------------
compilation defaultLanguage="c#" debug="true"
httpRuntime executionTimeout="90"

[aspx.cs]
-----------------------
private void Page_Load(object sender, System.EventArgs e)
{
Server.ScriptTimeout = 60; // 기본값은 web.config 의 executionTimeout(초) 임
}

[결과]
페이지 로드시 Server.ScriptTimeout 속성을 60초로 변경하였으나,
값이 적용되지 않고, 페이지 실행이 끝날때까지 계속 실행(Case1과 동일한 문제)
[원인]
In debug mode the timeout is 30,000,000 seconds which is about a year
[해결]
페이지 실행의 제한시간을 적용할 경우, compilation debug 속성을 반드시 false로 한다
Server.ScriptTimeout 프로퍼티도, web.config 의 debug="false" 인 경우에만 적용됨.

[Case 3] 웹서비스(.asmx)의 실행시간

[asmx -> web.config]
------------------------------
compilation defaultLanguage="c#" debug="false"
httpRuntime executionTimeout="90"

[결과] - 90초후 페이지 실행 강제 종료
System.Threading.ThreadAbortException : Thread was being aborted
[원인]
웹서비스가 속해있는 응용프로그램의 web.config 설정의 executionTimeout 파라미터 값 적용됨.
[해결]
시간을 더 늘리고자 한다면, web.config에서 executionTimeout 값을 늘리거나,
asmx.cs 에서 [웹메소드] 블록 첫 라인에 Server.ScriptTimeout 값을 셋팅하면 된다.

[Case 4] ASP.NET 페이지내에서 원격의 웹서비스(.asmx)를 호출

[aspx -> web.config]
------------------------------
compilation defaultLanguage="c#" debug="false"
httpRuntime executionTimeout="300"

[asmx -> web.config]
------------------------------
compilation defaultLanguage="c#" debug="false"
httpRuntime executionTimeout="300"

[결과] - 100초후 webservice request timeout 발생( .asmx 페이지는 300초동안 실행됨)
System.Net.WebException : The operation has timed-out
[원인]
웹서비스를 호출한 경우, 호출한 aspx페이지의 설정에 따라 두가지 결과가 나타남.
(1) System.Threading.ThreadAbortException(페이지강제종료)
: executionTimeout, Server.ScriptTimeout 값이 proxy.Timeout 값보다 작은 경우
(2) System.Net.WebException(웹서비스 요청시간 만료)
: proxy.Timeout값(기본값:100초)이 executionTimeout, Server.ScriptTimeout값보다 작은 경우
[해결]
위 경우, 호출하는 asmx의 응답을 기다리는 시간을 300초로 유지하고 싶은 경우,
다음과 같이 호출시에 웹서비스 인스턴스의 Timeout 프로퍼티를 미리 셋팅한다.
TestWebSrvCall.kr.co.test.www.Service1 test = new TestWebSrvCall.kr.co.test.www.Service1();
test.Timeout = 300000; // 설정하지 않으면 default(100,000 ms == 100 seconds)

※ 주의 : 이 값에 의해, 원격에서 실행되는 웹서비스 실행이 중단되는 것은 아님.
원격의 웹서비스는 자신의 설정값에 의해 실행이 중단되며,
호출하는 페이지에서 사용하는 웹서비스 proxy Timeout 속성은 웹서비스 응답을 기다려주는 시간임.

[Case 5] ASP.NET 페이지내에서 SAP 프록시 실행 (proxy.Parameter.Timeout)

- Case 4 웹서비스와 유사한 동작
xml web service 클라이언트에서 동기 xml web service 요청이 완료될때까지 대기하는 시간(밀리초)
기본값 : 100,000 ms(100초)

[Case 6] ASP.NET 페이지내에서 DB 쿼리 수행(실행시간 제약조건으로 인해, SP호출)

(1) 테스트케이스로.. 아래의 2가지 Oracle Provider에서 제공하는 CommandTimeOut 속성값을 적용해 테스트를 해 보았으나,
Document와는 다르게 해당 속성이 적용되지 않아, 정확한 결과를 얻지 못함.
- Oracle.DataAccess.Client.OracleCommand.CommandTimeOut (ODP.NET 9.2.0.7)
- System.Data.OracleClient.OracleCommand.CommandTimeout (Managed Data Provider for Oracle 1.1, EnterpriseLibrary 1.1)

※ 테스트 결과, SAP 연결후 실행문에 대한 제어는 잘 작동되지 않았습니다.
DB쪽도 쿼리에 대한 CommandTimeOut 속성이 잘 동작하지 않았습니다. (ODP.NET 및 .NET 오라클 프로바이더)
이에 대해서는 다른 방법을 강구하는 것이 필요하겠습니다.

Cookieless Sessions & Aspnet_filter.dll

Tue, 22 Dec 2009 18:49:18 +0900

Enter Cookieless Sessions

you don't have to change anything in your ASP.NET application to enable cookieless sessions, just enter sessionState cookieless="true" in your web.config.

Internal Implementation of Cookieless Session in ASP.NET

The implementation of cookieless sessions includes couple of runtime modules:

1. SessionStateModule [A standard session HTTP Module]
2. Aspnet_filter.dll [Works as an executable]

Once the HTTP Request come at the server, a small piece of Win32 code works as an ISAPI filter. HTTP modules and ISAPI filters are in opinion of the same concept, except that HTTP modules are created by the managed code and require ASP.NET and CLR to trigger and work. Classic ISAPI filters like aspnet_filter.dll are invoked by IIS. Both capture IIS events fired during the processing of the request.

When the first request of a new browser session comes at server to process, the SessionStateModule reads about the cookie support in the web.config file [By default “machine.config” specifies cookie enabled session]. If the “cookieless” attribute of the section is set to true, the module generates a new session ID, twists the URL by appending the session ID just before the requested page name, and redirects the browser to the newly created URL using the “HTTP 302 command”.

When each request reaches at the IIS boundary?far before it is handed over to ASP.NET?aspnet_filter.dll is given a chance to look at it. If the URL appends a session ID in parentheses, then the session ID is extracted and copied into a request header called AspFilterSessionId. The URL is then rewritten to exactly like the originally requested resource and let go. This time the ASP.NET session state module retrieves the session ID from the request header and proceeds with session-state binding.

The cookieless mechanism works great as long as the URL contains information that can be used to obtain the session ID. As you'll see in a moment, this poses some usage restrictions.

Let's review the pros and cons of cookieless sessions.

Advantages of Cookieless Session

In ASP.NET, session management and forms authentication are the only two system features that use cookies under the hood. With cookieless sessions, you can now deploy stateful applications that work regardless of the user's preferences about cookies. As of ASP.NET 1.x, though, cookies are still required to implement forms authentication. The good news is that in ASP.NET 2.0 forms authentication can optionally work in a cookieless fashion.

Another common reason advanced against cookies is security. This is a point that deserves a bit more attention.

Cookies are inert text files and as such can be replaced or poisoned by hackers, should they gain access to a machine. The real threat lies not much in what cookies can install on your client machine, but in what they can upload to the target site. Cookies are not programs and never run like programs; other software that gets installed on your machine, though, can use the built-in browser support for cookies to do bad things remotely.

Furthermore, cookies are at risk of theft. Once stolen, a cookie that contains valuable and personal information can disclose its contents to malicious hackers and favor other types of Web attacks.

Disadvantages of Cookieless Session

By looking the advantages of cookieless session we should not reach on any conclusion: Considering security aspect, your cookieless sessions are easier to hack in compare. Session Hijacking can act against this approach.

In brief, session hijacking occurs when an attacker gains access to the session state of a particular user. Basically, the attacker steals a valid session ID and uses that to get into the system and snoop into the data. One common way to get a valid session ID is stealing a valid session cookie. That said, if you think that cookieless sessions put your application on the safe side, you're deadly wrong. With cookieless sessions, in fact, the session ID shows up right in the address bar

With cookieless sessions, stealing session IDs is easier than ever.

Using cookieless sessions also raises issues with links. For example, you can't have absolute, fully qualified links in your ASP.NET pages. If you do this, each request that originates from that hyperlink will be considered as part of a new session. Cookieless sessions require that you always use relative URLs, like in ASP.NET postbacks. You can use a fully qualified URL only if you can embed the session ID in it. But how can you do that, since session IDs are generated at run time?

The following code breaks the session:

Click

To use absolute URLs, resort to a little trick that uses the ApplyAppPathModifier method on the HttpResponse class:

The ApplyAppPathModifier method takes a string representing a URL and returns an absolute URL that embeds session information. For example, this trick is especially useful in situations in which you need to redirect from a HTTP page to an HTTPS page.

오라클 프로바이더 및 타임아웃

Mon, 21 Dec 2009 12:33:33 +0900

App에서 오라클 연결제한(ConnectionTimeout) 및 실행제한(CommandTimeout) 에 대한 글입니다.
KB251248 에 따르면, MS에서 제공하는 ODBC와 OLEDB 프로바이더가
Connection Timeout and Query Timeout 기능을 포함하고 있지 않다고 합니다.

닷넷에서 오라클에 접근하는 7가지 방법
http://www.simpleisbest.net/archive/2005/08/15/203.aspx

Oracle CommandTimeout does not work in .NET Framework 2.0 (Microsoft Enterprise Library)
http://social.msdn.microsoft.com/forums/en-US/adodotnetdataproviders/thread/58ad7d4d-e561-477c-8cdf-dc7466626c94

None of the current Microsoft implemented Oracle drivers support a command or connection timeout. See for example:
251248 PRB: Connection Timeout and Query Timeout Not Supported with Microsoft Oracle ODBC Driver and OLE DB Provider
http://support.microsoft.com/default.aspx?scid=kb;EN-US;251248

글의 주제와는 조금 거리가 있지만, ConnectionPooling 과 관련된, ODP.NET의 문제점이 있어 보입니다.
주로 idle time 이 어느정도 존재하고, DB서버쪽 혹은 방화벽쪽에서 tcp 세션을 끊는 동작이 존재할 경우,
충분히 문제가 될만한 사안이라고 생각됩니다.

.NET Data Provider vs ODP.NET(ConnectionPooling)
"ORA-00028: your session has been killed"
"ORA-01012: not logged on"
http://blogsnippet.blogspot.com/2008/12/net-data-provider-vs-odpnet.html

Microsoft Visual Studio .NET 2003 디버깅 오류

Thu, 17 Dec 2009 18:32:13 +0900

I hate that, and it seems that every time I (or a co-worker) gets the error “Unable to Start Debugging on the Web Server” on a machine when attempting to debug an ASP.NET project, I have to scramble to remember what to look at. Here's a few things that has worked for me to get things working so you can debug your ASP.NET project when/if you ever get this error:

- Make sure that IIS is configured to use Integrated Windows Authentication. Look for the checkbox on the Authentication Method dialog launched from the Directory Security tab of the site properties.

- Make sure that HTTP Keep Alives are enabled. You'll find that checkbox on the Web Site tab of the properties dialog, in the connections section.

- This one is strange, but it seemed to do the trick for many out there, add http://localhost to the trusted sites in Internet Explorer. To tell the truth, this seems to be a fix for the symtoms, not actually fixing the problem itself, but if it works it works. BTW, you'll have to uncheck the “Require server verification (https:) for all sites in this zone“ checkbox to add it as a trusted site.

Good luck.

+ I found this to be a very complete resource guide to solve this problem

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vsdebug.asp

소켓 종료와 TIME_WAIT

Thu, 17 Dec 2009 14:58:22 +0900

오늘은 소켓의 종료와 그에 따라 발생하는 소켓의 상태 변화에 대해 알아 보도록 하겠다.

먼저 소켓은 생성될 때는 3-way hand shaking을 통해서 생성되지만, 종료 될때는 한단계 더 많은 4-way hand shaking을 거쳐 종료 된다.

위에서 분명히 4-way.. 4단계라고 이야기 했다. 그럼 어떤 4단계를 거치는지 알아 보자.

1. A가 B에게 연결 종료를 요청한다.
2. B는 바로 종료를 하는 것이 아니라, 단순히 ACK만을 날리고 있다.
B도 종료 하기 전에 할 일이 있기 때문에 바로 FIN을 날리지 않고,
단순히 ACK를 날리고 CLOSE_WAIT 상태로 넘어간다.
3. 볼일을 다 보고난 B는 이제서야 FIN을 날리고 연결을 종료 하고자 한다.
4. A는 B의 FIN을 잘 받았다는ACK를 B에게 보내게 되고, A의 ACK를 받으면 B는 종료한다.

4의 과정에서 A는 ACK를 날리고 난후 소켓이 제거될때 까지 TIME_WAIT상태에 있게 되며
이 시간은 대략 30 초 정도지만 시스템 마다 다르다.
TIME_WAIT에 있는 동안에는 커널이 주소와 port를 바인딩 하고 있기때문에 재사용 할 수가 없다.
게다가 TIME_WAIT에 있는 주소와 port를 재사용 요청을 하면 TIME_WAIT 시간을 더욱 늘릴 뿐이다.

그렇다면 이렇게 불편한 TIME_WAIT를 왜 사용해야만 하는가??
만 일 A가 B로 보낸 마지막 종료 메시지(SEQ:5001,ACK:6002) 이후 바로 종료 했다고 가정하자.
그런데 라우터의 문제라던지 기타등등의 네트워크 상에서 발생하는 어떠한 원인에 의해 마지막 종료 메시지가 B에 도착하지 않게되었다.
이때쯤 되면 B는 종료하지 못하고(TCP는 소심해서 뭘 하던지 완료 메시지를 받아야 마음을 놓는다)
다시 A에게 한번 더 FIN(SEQ:6001, ACK:5001)을 날린다.
여 기서 A가 TIME_WAIT가 아니라 바로 종료 되어버린 상태 였다면,
이 마지막 FIN 역시 무시했을 테고 B는 여전히 A가 종료 되었는지 살아 있는지 모르고 아둥바둥거리고 있게 될 것이다.
하지만 TIME_WAIT에 있는 A의 소켓은 여전히 주소와 포트를 바인딩 하고 있는 상태이기 때문에
다시 날아 오는 B의 FIN을 감지하고 다시한번 마지막 ACK를 날려 줄 수 있는 것이다.

Creating a Web garden enhances performance

Wed, 16 Dec 2009 13:38:27 +0900

Gardening w3wp worker processes in an IIS 6.0 Web Garden

In the dynamic landscape of today's organizational knowledge management scenario, it is imperative that an enterprise website be able to exhibit traits of scalability and robustness, which apart from its ability to satisfy user knowledge requirements, go a long way in creating an image of reliability and dependability for the enterprise.

Websites that can cater to their user bases, and their knowledge requirements without succumbing to constraints imposed by existing technology in providing information and resources, will always find favor with their audiences. This article tells you how

When a website or a web application is created in IIS 6.0, it is assigned to an application pool which in most cases, unless
re-allocated, is in the 'Default Application Pool'. Each application pool has at least one worker process (w3wp.exe) which is responsible for handling the requests sent to a Web Server for the specific application pool. In order to make a website consistently available and accessible to your users, the administrator can increase the number of worker processes servicing the application pool by implementing a Web garden, which in other words, is an application pool that uses more than one worker process.

Good Gardening Practices:

The magnitude of requests and their contention for system resources essentially decides the number of worker processes to be added to an application pool. Additionally, if a particular application or a website is receiving more process requests than it can handle, it can be assigned to another application pool, where it can be allocated as many worker processes as required to handle the demands on its resources.

Reduced contention for resources - When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to an available worker process in the Web garden. This helps smooth out the overall workload and reduce contention for system resources.

Setting up your Garden:

To configure multiple worker processes to an application pool, the steps involved are as given below:

* In IIS 6.0 Manager, expand the Local Computer path
* Expand the particular Application Pool
* Right click to choose Properties
* Click the Performance tab, and under Web Garden
* In the 'Maximum number of Worker Processes' box, type the number of worker processes that have to be assigned to the application pool
* Click OK

Web Garden Benefits:

Creating a Web garden enhances system performance by providing the following benefits:

* Robust processing of requests - In situations where a particular worker process is unable to focus on more requests owing to its occupied state, other worker processes in the Web Garden can step in and take over the processing requirements, without any drop in the system performance.
* Reduced contention for resources - When a Web Garden reaches a steady state, each new client request is assigned, according to a round-robin scheme, to an available worker process. This helps smooth out the overall workload and reduce contention for system resources.

Caveats:

Since Web gardens enable the use of multiple processes, all processes have their own copy of application state, in-process session state, caches, and static data. Web applications using an in-process ASP sessions state face random and frequent loss of session information. ASP.Net has three ways by which it manages ASP session states:

* In-Process Session State- Default mode, where sessions are stored in w3wp worker process
* Out-Process Session State- ASP.Net Session State Service
* SQL-Server Session Management (Using SQL Server)

Classic ASP web applications employ an In-Process Session State, and hence a Web Garden concept in IIS 6.0 may not work out.

Web Gardens are primarily designed for applications that are independent of CPU affiliation, and involved in long running database requests. In other words, applications that exhibit a considerable amount of dependency on back end databases, and where the session state is effectively managed outside the workspace.

But as with every technology, Web Gardens have their share of critics. There are those who advocate the creation of additional application pools and the isolation of web entities into individual application pools, rather than opting for a Web Garden. It all depends on identifying the standard relative performance of your application in a Web Garden before deciding on the feasibility of implementing a Web Garden in your server environment.

Web Garden is NOT a performance feature

Wed, 16 Dec 2009 13:11:09 +0900

Thoughts on Application Pools running out of threads

Question:

Perhaps "application pool running out of thread", that's what my vendor tell me when their asp.net application has intermittent performance problem.

I searched and read quite some documentation, but no luck. What did he mean by "running out of thread"? Where can I check or adjust the setting for this?

And I want to know the exact benefic of web garden. Do more than one w3wp.exe achieve better performance than only one?

Answer:

If the vendor tells you their ASP.Net application is "running out of threads", then the vendor is basically telling you that his ASP.Net application has some performance issue because it is performing too many simultaneousy synchronous operations tying up worker threads to prevent other requests from being serviced.

In other words, the vendor's application has a problem, he is simply blaming Microsoft because it is easy and convenient, and you believed it because you had no other information.

Now, you may think "wait a minute; if the application is tying up worker threads, then shouldn't IIS/ASP.Net simply detect this and create more worker threads to continue functioning - so isn't this this really an IIS/ASP.Net issue?"

Ahh... but that is a common misconception about threads (and similarly, processes). Increasing concurrency (i.e. having the system perform more work simultaneously by creating more threads or starting up additional processes such as Web Garden) is not synonymous with improving performance. Why?
Computation 101

You can view the CPU of your computer as something that can perform some number of operations in a second, and at any point in time, it can only perform one operation.

Since the CPU does not perform multiple operations at any point in time, it means that it is not possible to run multiple applications simultaneously. A computer gives the ILLUSION of running multiple applications simultaneously by quickly switching the CPU between various applications such that each application gets a "slice" of CPU time to perform useful work with its operations.

Note that switching the CPU between various applications is not free; it takes a small but non-zero amount of CPU time.
Example

How does this translate into performance? Suppose you have:

1. CPU that performs 120 operations per second
2. A request takes 10 operations to complete
3. Switching between threads takes 1 operation
4. CPU switches threads every 5 operations

* If your worker process only has one thread, it can perform at most 120 / 10 = 12 requests/second.
* If your worker process has two threads, it can perform at most 120 / ( 2 x ( 5 + 1 ) ) = 10 requests/second (remember, it takes two context switches to gather up the CPU slices to perform 10 operations of work to complete the request).

Notice that increasing concurrency (in this case, the number of threads) DECREASES the potential request/second throughput. This decrease comes from the cost of context switching (in this case, between threads) that is otherwise not performing useful work. In other words, increasing concurrency decreases potential throughput because it must waste CPU cycles maintaining that concurrency.

At this point, the astute reader should wonder "if increasing concurrency decreases potential throughput (and hence max performance), then why in the world do we want concurrency? It's just bad, right?"

Well, suppose that the request can monopolize and hang whatever thread it is running on, and it does this every 6 requests.

* If your worker process only has one thread, you get 5 requests before your worker process is unable to service any more requests since it has no more threads.
* If your worker process has two threads, you get 10 requests before your worker process is unable to service any more requests since it has no more threads.

Notice what concurrency brings:

* If you are running blocking operations, concurrency allow you to run more of those operations before being totally blocked. In other words, it improves the appearance of availability.
* However, concurrency does not solve blocking operations. It only delays the inevitable when all sources of concurrency gets blocked.

Conclusion

Thus, I would refrain from asking a question like "does more than one w3wp.exe achieve better performance than only one" because the answer completely depends on the behavior of each request.

* If you have performant code that does not block, then having one w3wp.exe is ideal since it maximizes request throughput by not having any loss due to context switching
* If you have code which blocks, you *may* want to consider increasing concurrency by adding threads or Web Garden... but realize that this only gives short-term appearance of availability at the expense of decreased raw performance, does not solve the non-performant code, and only delays the inevitable.

In other words, Web Garden is NOT a performance feature. It is a reliability/availability feature, and it improves appearance of reliability/availability at the cost of decreasing performance. It basically gives you another process (and more threads) which help improve reliability/availability if you are running code that hangs and chews up threads of a w3wp by providing additional processes and threads that can be chewed up by the same code. In other words, it delays the inevitable hang of a bad application. The cost of providing this concurrency is performance because there are more context switches between the process/threads, and context switch is basically wasted CPU cycle that does no useful work.

//David

파일의 크기와 디스크 할당 크기

Tue, 08 Dec 2009 10:58:36 +0900

파일의 등록정보를 보면, 크기와 디스크 할당 크기라는 구분이 있다.

두 값을 자세히 살펴보면, 실제 파일 크기 보다 디스크 할당 크기가 큰 경우가 대부분이다.

디스크에 파일을 저장할 때는 클러스터 단위를 사용한다.

이 크기는 OS에서 지원하는 파일시스템(FAT,NTFS,기타)의 종류와,
디스크 파티션 포맷시에 지정하는 할당단위크기(Allocation Unit Size)에 종속적이다.

NTFS 의 경우는 512,1024,2048,4096 바이트를 지원하며, 기본값은 4K(4096)이다.

파일의 실제크기와 디스크 할당 크기의 차이는 슬랙(Slack)이라는 용어를 사용한다.
즉, 디스크 클러스터중 사용되지 않는 공간이다.

파일 사이즈가 1KB 이고, 디스크 할당 크기가 4KB이라면, 슬랙은 3KB이다.

일반적으로 할당크기가 작으면, 사이즈가 적은 파일이 많은 경우 공간활용의 잇점이 있고,
할당크기가 크면 하드디스크 내부 검색량이 줄어, 속도면에서 있점이 있다고 한다.

DiskSlackChecker등.. 슬랙 크기를 알려주는 프로그램도 있다고 하니..
사용중인 PC의 슬랙공간을 계산해 보고,
파티션 포맷시 어떤 값을 선택할지 결정하면 될듯 싶다.

다음은 구글에서 찾은 C#을 사용한 파일의 디스크 할당 크기 구하기에 관한 내용이다.

- I want to get the size on disk of a selected file in c#.
By using FileInfo.Length i am able to get the file size. But i need "size on disk" in c#.

- The size on disk should be the sum of the size of the clusters that store the file:
long sizeondisk = clustersize * ((filelength + clustersize - 1) / clustersize);
You'll need to dip into P/Invoke to find the cluster size; GetDiskFreeSpace() returns it.

- If you are using ntfs this approach won't work for files with the compressed attribute on.
On such files the 'size on disk' is usually smaller than the actual file size :-)

- The Win32 function GetCompressedFileSize() can get the size of a compressed file.
Use File.GetAttributes() to determine whether the file is compressed.

[LogParser] 텍스트 파일 통계

Fri, 04 Dec 2009 13:18:03 +0900

[쉼표구분자가 있는 데이터]

comma.csv
--------------------------------------
2009-12-04 , 오전 12:00 , 10.21.00.000
2009-12-04 , 오전 12:00 , 59.3.00.00
2009-12-04 , 오전 12:00 , 61.78.000.000
2009-12-04 , 오전 12:00 , 112.156.00.0
--------------------------------------

comma.h 파일 생성
--------------------------------------
date,time,ip
--------------------------------------

IP항목값을 중복없이 뽑아내기
--------------------------------------
c:\> logparser -i:CSV -iHeaderFile:comma.h "select DISTINCT ip from comma.csv
order by ip" -q:ON > access-ip.txt

[space 구분자가 있는 데이터]

space.log
--------------------------------------
2009-12-04 오전 12:00 10.21.00.000
2009-12-04 오전 12:00 59.3.00.00
2009-12-04 오전 12:00 61.78.000.000
2009-12-04 오전 12:00 112.156.00.0
--------------------------------------

space.h 파일 생성
--------------------------------------
date time ip
--------------------------------------

IP항목값을 중복없이 뽑아내기
--------------------------------------
c:\> logparser -i:TSV -iHeaderFile:space.h "select DISTINCT ip from space.log order by ip" -iSeparator:space -q:ON > access-ip.txt