세션은 어떻게 할까...창을 닫아버리면 어쩔까...컴터를 끄면 어쩔까...고민하다가... QnA에서 힌트를 얻어서...만들었습니다... 필요하신 분은 참고하세요~ 우선 두개의 테이블을 만들었습니다... checklog Table - ip(접속 ip) - id(사용자 id) - loginTime(로그인 시간) duplicatelog Table (중복접속이 일어났을 경우 로그기록을 남기기 위해서 존재) - id(사용자 id) - date(날짜) - ip(접속 ip) 자주 쓰는 테이블은 checklog Table 하나면 됩니다. 중복체크를 로그기록으로 남기지 않으시면, duplicatelog 테이블은 필요 없습니다. 그래서, 로그인 할때 마다 '로그인 중복 방지###########################..
Think Outside The Box 검색 결과
웹사이트를 운영하다 보면 이미지 파일을 함부로 다운로드 받지 못하도록 이미지의 경로를 노출시키고 싶지 않은 경우가 있다. 여기서는 ASP를 이용한 간단한 방법을 살펴보도록 하겠다. 우선 간단한 예제부터 살펴보도록 하자. 아래 샘플 이미지가 있는데 이 이미지는 여기서 살펴볼 방법에 의해 이미지를 로드한 것이다. 이미지의 경로가 .gif나 .jpg가 아니라 .asp인 asp파일로 되어 있다. 즉, asp 파일 안에서 적절한 이미지를 불러 오는 것이다. 그렇다면 /etc/codeexample/asp/19444.asp의 내용은 어떻게 되어 있을까?
- ASP syntax - ASP가 여러 사람 먹여 살리는 것 같습니다. 1996년 당시, CGI가 판을 칠 때 슬그머니 나타난 ASP. 전 아직도 그 때 당시를 잊지 못합니다. 이렇게 쉬운 것도 있구나... DOS에서 C와 C++을 하다가 윈도상에서 DB를 해야 했을 때 VB, 델파이 등 여러 가지를 시도하다 MS-Access를 만났을 때와 마찬가지로 그 감동은 엄청난 것이었습니다. MS에서 제공해주는 기본적인 예제와 메뉴얼로 이렇게 저렇게 해보다 결국 하나하나 화면이 만들어지는 그 감동. 프로그래머라면 누구나 느끼시는 것일 겁니다. IIS가 웹서버 시장의 절반정도를 차지하고 있는 작금의 현실은 그대로 ASP에 대입된다고 볼 수 있겠죠. 그만큼 사용자나, 개발자가 많다는 얘깁니다. 작설하고.. 본론으로..
앞서 말한 4가지 중 어떤 것이 주된 원인이 되는지 정형화시키기는 사실 매우 어렵다. 그러나, 일반적으로 분류해 보면, 컴포넌트의 오류와 데이터베이스의 오류가 대부분이다. 혹은 이 둘의 복합적인 양상을 띠게 된다. 일반적으로 컴포넌트 오류로 인한 문제는, 주기적으로 이 컴포넌트와 관계된 오류 메시지가 웹 로그에 나타나므로 그 문제점의 발생 및 수정은 비교적 쉽다. 간혹, 컴포넌트 문제가 아니라 웹 서버 자체의 설치 문제와 관계된 사항들에 의해 시스템 에러를 받기도 한다. 이러한 문제들은 디버거를 사용하여 해결하는 경향이 크다. 웹 사이트 자체를 디버깅 모드로 운영하면서 생기는 여러 결함들을 잡아 낼 것을 일반적으로 권하고 있다. 컴포넌트 오류가 아닌 경우에는 정말 어딘가의 병목이 있어서이다. 이 경우가 ..
튜닝 포인트라는 개념은, 실제로 웹 서버의 아주 특수한 부분에 의해 생긴 문제가 전체적으로 확대되어 발생하다는 것이다. 이것은 고속도로에서 흔히 보는 병목 현상과 마찬가지다. 도로 중간에서 사고가 났을 경우, 해당 도로는 마비되지만, 실제로 도로 전 구간이 마비된 것은 아니다. 이런 병목 지점에서 외부의 급격한 리퀘스트를 받게 될 때, 웹 서버는 자기가 처리할 수 있는 양 이상의 값을 받게 된다. 일단 시스템 구조상 이 값은 큐에 삽입된다. 그리고, 큐보다 많이 들어오는 값들은 튕겨 나간다. 이 튕겨 나갈때 나타나는 에러는 Server Too Busy 라는 메시지이다. 그런데, 이 병목 지점이 형성되는 것은 사용 상황과 보조 서버들의 상황, 혹은 여타 외부적인 변수를 매우 많이 받는다. 따라서, ASP ..
Server.CreateObject 구문을 단속하지 않으면 대용량 시스템에 문제가 많다는 사실은 오래 전부터 있어 온 이야기이다. 그러나, 실제 저 문제에 의해 죽는 시스템은 생각보다 많지 않다. 웹 사이트 성능을 측정하면서 많은 부분 간과하는 것이 바로 CPU와 메모리에 지나칠 정도로 집착하는 것이다. 실제로 죽는 웹 서버는 메모리 소요량이 많아서도 아니며, CPU 점유율이 많아서도 아니다. 간혹 CPU 점유율이 많은 서버가 존재할 수는 있겠지만, 이는 데이터베이스 등에서 병목을 일으키는 예가 된다. 따라서, 죽는 웹 서버는 일반적으로 성능 모니터링을 하지 않아도 죽는 것을 감을 잡는다. 노련한 엔지니어라면, 시스템이 돌아가는 상황을 조금만 보더라도 "이 시스템은 언제쯤 죽을 것인지" 판단이 서기 마련..
최근댓글