문제

이것은 이전 Classic ASP 사이트에서 완벽하게 작동하므로 매우 이상한 문제입니다.기본적으로 데이터베이스를 쿼리하고 Response.Write를 통해 약 2200줄의 텍스트를 텍스트 파일로 내보내 대화 상자에 출력하고 사용자가 파일을 저장할 수 있도록 합니다.

response.clear () response.clearContent () response.clearheaders ()

    Dim fileName As String = "TECH" & test & ".txt"

    Response.AddHeader("Content-Disposition", String.Format("attachment; filename={0}", fileName))
    Response.ContentType = "text/plain"

    Response.Write(strHeader)

    Dim sw As New IO.StringWriter()

    Dim dtRow As DataRow
    For Each dtRow In dt3.Rows
        sw.Write(dtRow.Item("RECORD") & vbCrLf)
    Next

    Response.Write(sw.ToString)
    Response.Write(strTrailer & intRecCount)
    Response.End()

StringWriter를 사용하거나 간단히 Response.Write(dt.Rows(i).Item("RECORD").toString을 사용할 수 있습니다.

어느 쪽이든 내보내기로 인해 우리 개발 사이트가 엄청나게 중단되었습니다.내 로컬 컴퓨터는 중단을 일으키지 않으며 거의 ​​즉각적입니다.레코드세트는 그다지 크지 않으며, 기록 중인 줄도 작습니다.

이것이 왜 걸려 있는지 아는 사람이 있습니까?결국에는 파일을 저장하고 표시할 수 있지만 3~4분이 훨씬 넘습니다.

도움이 되었습니까?

해결책

원격 디버거를 연결하고 중단된 위치를 찾으시겠습니까?

문자열 작성기 루프인지 실제 쿼리 코드(여기서는 제공되지 않음)인지 파악해야 합니다.

다른 팁

출력 버퍼가 오버플로된 것 같습니다.아마도 거기에 카운터를 추가하여 수백 줄마다 플러시할 수도 있습니다.

또한 Response 개체는 기본적으로 StringWriter에 대한 대부분의 작업을 수행합니다.StringWriter를 중개자로 사용하는 것은 아마도 중복될 수 있습니다.

StringWriter와 DataTable을 사용하는 것은 모두 과잉입니다.

SqlReader를 직접 사용하여 데이터베이스에서 결과를 가져오고 판독기를 읽는 동안 출력 스트림에 직접 쓰는 것은 어떨까요?훨씬 빠르고 메모리 소모도 훨씬 적습니다.

두 번째 질문(ASP가 제대로 작동하는 이유)에 대한 답변으로, 동일한 내용을 출력하기 위해 메모리에 3번 저장했는지 의심됩니다(DataTable, StringWriter 및 출력 버퍼).내 ASP는 약간 녹슬었지만 일종의 데이터베이스 리더를 사용하고 있는 것 같습니다.

또한 일부 로깅 인프라(NLog, log4net)를 더 잘 사용하면 원격 디버거를 연결하는 대신 어떤 작업이 얼마나 지연되는지에 대한 타이밍을 출력할 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top