응용 프로그램이 느리게 실행됩니까? 정확한 시간

으로 Techopedia 직원, 2016 년 8 월 31 일

테이크 아웃 : 호스트 Rebecca Jozwiak가 분석가 Eric Kavanagh 및 Dez Blanchfield와 IDERA의 Bill Ellis와 함께 데이터베이스 문제 해결 및 효율성 문제에 대해 논의합니다.

현재 로그인하지 않았습니다. 비디오를 보려면 로그인 또는 가입하십시오.

Rebecca Jozwiak : 신사 숙녀 여러분 안녕하세요, 2016 년 Hot Technologies에 오신 것을 환영합니다. 오늘의 주제 인 "응용 프로그램이 느리게 실행됩니까? 정확한 시간을 얻을 수 있습니다." 그리고 우리는 물건이 느리게 실행될 때 발생할 수있는 문제를 너무 잘 알고 있지 않습니까? 저는 레베카 요 즈윅입니다. 저는 오늘 여기서 새로운 역할을하고있는 에릭을 채우고 있습니다. 예, 올해는 매우 뜨겁습니다. 제가 말했듯이 기술과 관련하여 정말로 원하지 않는 한 가지는 시스템의 일부를 느리게 실행하는 것입니다. 그리고 소비자의 예를 들자면, 식당이 있다면 음식의 맛이 중요하지 않습니다. 서비스가 느리면 다시 돌아 가지 않을 것입니다. 이제 식당에서 왜 무언가가 느리게 실행되는지 알아내는 것이 쉽습니다. 주방의 인원이 부족하거나 장비에 문제가 있거나 대기 직원이 약간 게으른 경우가 많으며 식별 및 고정이 용이합니다.

그러나 데이터 센터에 대해 생각할 때는 완전히 다른 이야기입니다. 네트워크 문제, 문제를 일으키는 잘못된 쿼리, 응용 프로그램 성능 또는 케이블 결함으로 인해 일부 문제가 발생할 수도 있습니다. 그리고 이러한 유형의 복잡성으로 인한 문제 해결은 최선의 방법이 아닙니다. 그것이 우리가 오늘 이야기 할 내용의 종류입니다. 에릭 카바나 흐 (Eric Kavanagh)는 오늘 분석가로 활동하고 있습니다. 데이터 과학자 인 Dez Blanchfield가 있고 IDERA의 Bill Ellis가 있는데, 이 회사는 응용 프로그램 성능 관리를 돕는 회사의 솔루션에 대해 이야기 할 것입니다. 그리고 그걸로 공을 에릭에게 넘길 것입니다. 에릭, 바닥은 네 꺼야

에릭 카바나 흐 : 좋습니다. 실제로 문제를 해결할 수있는 어려움이나 어려움에 대해 이야기하고 문제를 바로 잡을 수 있기 때문에 이는 매우 유사합니다. 성능 문제는 항상 네트워크에있는 어떤 종류의 문제로 인해 발생합니다. 예를 들어, 예를 들어 기존 하드웨어만큼 간단 할 수 있지만 결론은 문제 해결과 같은 상황입니다. 이것이 제가 오늘 이야기 할 내용입니다. 계속해서 여기 슬라이드로 넘어 갑시다.

문제가 왔습니다. 문제 해결 – 좋아하는 사람들에게는 재미 있고 멋진 일입니다. 문제 해결을 좋아하는 사람을 찾으면 그 사람을 붙잡고 작업을 수행하는 데 필요한 도구를 얻습니다. 무언가의 맨 아래에 도달하여 작업을 수행 할 수있는 사람을 찾을 수 있다면 정말 좋은 일이기 때문입니다. 그러나 결론은 문제 해결에 문제가 있으며 항상 그래 왔고 항상있을 것입니다. 문제 해결에 대해 이야기하기 시작하면 실제로 근본 원인 분석이 이루어집니다. 문제의 원인은 무엇입니까?

글쎄, 그냥 앉아서 메인 프레임 일에 대해 잠깐 생각하면 모든 종류의 문제가 발생할 수 있습니다. 그리고 그 당시에는 문제 해결을위한 훌륭한 도구조차 없었기 때문에 실제로 자신의 지식을 아는 사람들이 있어야했기 때문에 명령 프롬프트를 알아야했고, 잠시 후에 그것에 대해 이야기 할 것입니다. 그리고 저는 제가 가장 좋아하는 슬라이드 중 하나를 넣는 것을 잊었습니다. 오늘 우리가 쇼에있는 동안, 아마도 Dez의 프리젠 테이션 중에 그것을 찾을 것입니다. 그러나 나는 그것을 보지 못한 사람에게 가장 재미있는 영국 TV 쇼 중 하나 인 "IT 크라우드"를 보여주고 싶었습니다. 문제 해결 측면에서 두 사람 중 한 명인 아일랜드 인 전화가 시작될 때마다“회사의 전원을 껐다 켜 보셨습니까?”라고 회사 전체가 항상 똑같이 말합니다. 그 간단한 일이 몇 가지 문제를 해결할 수있는 빈도에 놀랄 것입니다.

집에서 문제를 해결 한 사람은 부모님이나 친구와 함께 할 수 있습니다. 자녀가해야 할 일을 알고 경향이있어 전원을 껐다가 다시 켜는 경향이 있기 때문일 수 있습니다. 그러나 문제 해결이 쉽지는 않지만 결코 쉽지는 않지만 오늘은 쉽게 할 수있는 몇 가지 작업에 대해 이야기 할 것입니다. 따라서 명령 프롬프트 – 예, 실제로 여러분이 가진 모든 것이 DIR, Enter를 수행하는 명령 프롬프트 일 때 컴퓨팅의 초기 시절을 기억할만큼 늙었습니다. 그것이 파일 디렉토리와 실제로 어떤 명령을 수행했다고 긍정적이라고 생각합니까? 물론 데이터 과학자 인 Dez는 명령 프롬프트 사용법을 알고 있습니다. 그리고 명령 프롬프트를 사용할 수 있다면, 대부분의 필사자들은 일종의 GUI, 그래픽 사용자 인터페이스를 사용하지만 항상 무언가가 있기 때문에 항상 GUI와 명령 줄 사이에 약간의 연결이 끊어지기 때문입니다. 그리고 임의의 예를 들기 위해 요즘 문서에 포함 된 일부 기본 프로그램의 코드 양을 알고 싶다면 최신 버전의 Microsoft Word로 이동하여 "hello world"를 입력 한 다음 "다른 이름으로 저장" 그런 다음 결과 문서를 텍스트 편집기에서 열면 태그 페이지와 페이지가 표시 될 것입니다. 이를 코드 부풀림이라고하며 코드 부풀림은 실제로 문제 해결에 적합하지 않으며 무딘 것입니다.

물론, 클라이언트-서버가 등장했고 그것은 대단했습니다. 그리고 우리는 그 방향으로 되돌아가는 방식으로 상황에 따라 발생하는 복잡성에 대해 생각해보십시오. 이제 문제는 어디에 있습니까, 클라이언트에 있습니까, 서버에 있습니까, 네트워크에 있습니까? 어 Where 어? 바이러스에 대해서만 생각하고 바이러스가 네트워크에서 바이러스에 감염 될 수있는 사이트는 어떻게됩니까? 어디든 갈 수 있습니다. 데이터 유출은 요즘 미친 짓입니다. 성능 문제가 발생합니다. IP 주소로 식별 할 수있는 러시아 해커가 있습니다. 우리는 그들이 러시아인이거나, 매우 근접하거나 프록시를 사용하여 매우 영리한 우크라이나 인, 폴란드 인 또는 심지어 미국인이라고 확신합니다. 그러나 우리는 해커가 몇 년 동안 작은 오래된 사이트 인 Inside Analysis에 들어와 모든 종류의 문제를 일으켰습니다. 물건이 작동을 멈추고 물건을 얻을 수 없습니다. 작동하던 것들이 작동하지 않습니다. 당신은 어떻게 알 수 있습니까? 그것이 무엇인지 어떻게 알 수 있습니까? 여기에 또 다른 예가있는 것처럼 매우 복잡한 환경이므로 잡초에 들어가서 일이 어떻게 진행되고 있는지, 특히 플러그인이 많이있는 경우에 우리를 위해 일하는 방식을 이해하기가 매우 어렵습니다. 물건은 꽤 빨리 미쳐 갈 수 있습니다. 나는 나 자신보다 앞서 가고있다.

나는 여기에 던졌고 항상 업그레이드에주의하십시오. 업그레이드는 항상 나에게 일광을 두려워합니다. 확실히 운영 체제. Microsoft가 실제로 운영 체제를이 버전에서 해당 버전으로 업그레이드 할 수 있다고 제안했던 시절을 기억합니다. 글쎄, 나는 몇 번 시도했지만 결코 효과가 없었습니다. 환경이 클수록 복잡할수록 상황이 더 어려워 질 것입니다. 그리고 가상화가 있습니다. VMware가 IT에 어떤 역할을했는지 생각해보십시오. IT에 혁명을 가져 왔지만이 추상화 계층도 만들었습니다. 그 기초 수준에서 레이어 추상화가 있다면, 그것은 완전히 새로운 공 게임이고, 그것은 완전히 새로운 왁스 공이며, 당신이하고있는 일을 실제로 재평가해야하며, 모든 오래된 도구는 바뀌어야했습니다. 물론 지금은 클라우드입니다. 고객에게는 클라우드가 훌륭합니다. 매우 간단하기 때문에 사용자 인터페이스가 매우 간단하지만 물론 클라우드를 많이 제어 할 수는 없습니다. 그러나 무대 뒤에서 사람들을 위해, 그들은 요즘 알고 이해해야 할 많은 것들이 있습니다. 환경은 훨씬 더 복잡해졌습니다. 그리고 확실히 전자 상거래와 함께, 당신은 요즘 거래하는 모든 돈을 생각합니다. 그렇기 때문에 언제라도 현금없는 사회를 선호하지 않을 것입니다. 결론은 그날 상황이 점점 더 문제가되고 있다는 것입니다.

그리고 성능을 최적으로 유지하려면 항상 일부 문제 해결 요소가 필요합니다. 나는 누군가가 당신에게 말하는 것을 신경 쓰지 않고, 완벽한 도구가 없으며, 총알이 없으며, 여기 또 다른 흥미로운 관점에서 우리는 여전히 실리콘을 배우는 법을 배우고 있기 때문에 결코 없을 것입니다. 우리는 여전히 네트워킹조차도 아주 중요한 수준에서 어떻게 작동하는지 이해하는 법을 배우고 있습니다. 시스템 관리 소프트웨어를 살펴보면 요즘 꽤 좋아지고 있습니다. 그러나 여전히 위아래로 움직이는 선을보고 있으며 현실의 표현을보고 있습니다. 무슨 일이 일어나고 있는지 알고있는 사람이 최적의 도구를 응시할 수있는 단서가 무엇인지 알 수 있습니다. 작동하는 것과 작동하지 않는 것을 이해하고 많은 시행 착오를 겪습니다. 그것으로, 나는 그것을 Dez Blanchfield에게 넘겨 주겠다. 그리고 우리는 그의 지식으로 우리를 부끄러워하게 할 IDERA의 Bill Ellis로부터들을 것이다. 그걸로 데즈, 빼앗아

Dez Blanchfield : 안녕하세요, Eric 감사합니다. 감사합니다. 내 작은 segue로 멋지게 이끌었다. 저의 제목 인 "Performance Art"는 공연 예술에 대해 생각할 때 많은 방식으로 춤과 음악 및 기타 창조적 인 것들에 대해 생각하기 때문에 오늘날 우리가 이야기하는 내용에 매우 적합하다고 생각합니다. 솔직히 말해서, 우리가 문제를 해결하고 대규모 IT 환경과 비즈니스 시스템에 실제로 예술 요소와 종종 검은 예술이있는 경우가 있습니다. 25 년 이상 내 경험의 상황은 최신 앱 스택은 이전에는 볼 수 없었던 속도로 복잡성을 매우 빠르게 증가시키고 있습니다. 우리는 솔직히 노력하고 있으며 Uber와 같은 조직과 Pokémon Go 개발 팀이 있으며 천문학적 인 속도로 성장과 복잡성 및 복잡성이 증가하고 있음을 의미합니다. 우리가 그 수준의 성장을 생각하지 않았기 때문에 그것에 대해 쓰여진 책조차 없습니다. 내 관점은 응용 프로그램 스택의 핵심 정의가 기하 급수적으로 변형되었다는 것입니다. 그 이유를 생각한 다음 당면 과제로 이어질 것입니다 .IDERA의 좋은 친구가 해결할 솔루션이있는 것으로 보입니다. .

아주 간단히 말해서, 우리는 모두 이것들을 알고 있지만, 그것들을 간단히 요약하기 위해 초기에는 애플리케이션 아키텍처, 버전 1.0이라고 불렀습니다. 서버 컴퓨터였습니다.이 경우 많은 수의 터미널이 연결되어있는 메인 프레임입니다. 터미널에서 물건을 볼 수없는 경우 문제를 진단하기가 비교적 쉽습니다. 터미널과 서버 컴퓨터 사이의 케이블을 추적 할 수 있습니다, 케이블이 없거나 케이블이 없거나 커넥터 또는 터미널과 관련이없는 경우 문제가 발생했습니다. 화면에 문제가있는 경우 문제를 일으킨 물건이 기계 자체. 또한 하드웨어에서 소프트웨어 계층 및 사용자 인터페이스까지 스택의 어느 위치에 서서히 진단 할 수 있습니다. 내가 버전 1.1이라고 부르는 것에서 우리는 조금 더 복잡하게 만들었습니다. 더 많은 터미널을 배치 할 수 있도록 디바이스를 중간에 배치했습니다. 그리고 그들은 일종의 통신 장치였으며 종종 멀티플렉서 나 멀티플렉서였으며 전용 회선이나 전화 접속 회선을 통해 갔기 때문에 먼 곳에 메인 프레임이있었습니다. SMA 링크 또는 일종의 WAN 연결을 통해 연결되어 있으며 해당 터미널은 여전히 ​​동일한 방식으로 작동합니다. 그러나 문제가 터미널과 통신 장치 또는 통신 장치와 메인 프레임 사이에 있는지 여부를 파악해야했기 때문에 조금 더 복잡해졌습니다. 그러나 스택은 메인 프레임에서 비교적 유사하게 유지되었습니다.

버전 1.2는 이제 더 많은 장치를 추가하고 프린터 및 기타 항목을 추가 한 후 이러한 것들을 클러스터링하여 로컬로 장치의 모든 문제를 처리 할 프론트 엔드 프로세서에 대해 생각하기 때문에 조금 더 복잡해졌습니다. 그리고 먼 끝에 메인 프레임을 가진 터미널 등등. 조금 더 복잡합니다. 그러나 메인 프레임의 일관된 주제는 로컬에서 실행되는 앱이었습니다. 따라서 문제 해결은 애플리케이션 스택 내에서 상당히 유사하게 유지되었습니다. 그리고 터미널과 프린터, 클러스터 컨트롤러와 관련된 문제를 해결하는 기술을 가진 사람들이있었습니다. 그러나 우리는 복잡한 것들을 만들고 네트워크를 구축했으며 갑자기 같은 종류의 아키텍처가 네트워크 계층을 도입했습니다. 갑자기 우리는 네트워크 스위치를 가지고 있었고 워크 스테이션은 훨씬 더 복잡했습니다. 그리고이 아키텍처 버전은 종종 워크 스테이션에서 그래픽으로 사용자 인터페이스 앱을 사용했습니다. 앱 스택을 실행하는 서버가있을뿐만 아니라 로컬로 실행되는 다른 애플리케이션 스택과 서버에 연결하는 동일한 기본 장치 모델도있었습니다. 그런 다음 우리는 2.1이라고 부르는 최신 모델로 양자 도약을했습니다.이 앱 스택을 가져와 진단하기가 훨씬 더 어렵습니다. 또한 프론트 엔드, 웹 브라우저, PC 및 모바일 장치 등에서 훨씬 더 많은 장치를 도입했습니다. 그리고 여기서 애플리케이션 스택은 운영 체제 및 하이퍼 바이저와의 통합에 대해 조금 더 깊이 들어가기 시작했습니다.

여기 오른쪽에있는이 이미지는 네트워크 인프라, 스토리지 서버, 가상 머신, 운영 체제 및 기존의 3 단계 데이터베이스 메탈웨어 애플리케이션 등을 포함하여 전체 스택을 전면 오른쪽에 가지고 있습니다. 이 모델의 응용 프로그램 문제 및 성능 문제를 진단하는 것이 훨씬 어려워졌습니다. 더 많은 움직이는 부분이 있으며 그 스택을 뚫고 내려 가려고 노력하는 것은 단지 악몽이되었으며, 이를 처리하기 위해 추가 기술 세트와 조직이 필요했습니다. 이제는 애플리케이션 팀이 아니 었으므로 이제 갑자기 인프라 스트럭처 직원, 데이터베이스 전문가, 데이터베이스 작업 등 데이터베이스 전문가가 아닌 데이터베이스 프로그래머와 달리 데이터베이스 전문가 만있었습니다. 이제 우리는 IT 부서가 "서비스로서"의 훨씬 더 복잡한 복잡성을 처리해야하는 시나리오를 갖게되었으며, 이로 인해 세상이 폭발적으로 폭발하고 문제 해결 과제가 악몽에서 거의 참기 어려운 것으로 바뀌 었습니다. 어떤면에서.

그리고 이것은 해결 가능한 규모로, 우리는 서비스를 제공하려고 노력하고 있습니다. 응용 프로그램 스택으로 간주되는 버전 3 – 서비스 모델로 소개했습니다. 서비스 모델은 왼쪽에있는 기존 모델, 엔터프라이즈 IT 스택으로, 소비자와 공급 업체로서 모든 것을 관리해야했습니다. 애플리케이션 보안 데이터베이스, 운영 체제, 가상화 서비스 스토리지, 네트워킹 데이터 센터 등 모든 서비스를 관리해야했지만 모든 기능에 액세스 할 수 있었으므로 기능과 기술 수준을 확장하고 바로 드릴 다운 할 수있었습니다. 그 스택을 통해 우리는 물건을 찾을 수 있습니다. 그러나 인프라 서비스 및 플랫폼 서비스와 소프트웨어 서비스 모델이 등장함에 따라 갑자기 백엔드 인프라에 대한 액세스, 플랫폼에 대한 액세스 및 서비스를 제공하는 도구 등이 우리에게서 멀어졌습니다. 인프라 서비스를 사용하기 시작하면서 운영 체제, 데이터베이스, 보안 환경 응용 프로그램 스택 등 상위 4 개 항목 만 실제로 사용할 수있었습니다. 그 아래의 모든 것은 흑 마법이었다. 또한 응용 프로그램 스택을 관리하기 때문에 플랫폼 서비스로 이동할 때 훨씬 더 흥미로워집니다.

서비스 형태의 소프트웨어를 이용할 때 웹 메일 또는 인터넷 뱅킹의 전통적인 모델을 사용하면 웹 브라우저에 액세스 할 수 있기 때문에 뒤에 숨은 것을 진단하는 것은 참을 수없는 일입니다. 그리고 이것을 시간대, 시간대 또는 시간대로 나누었습니다. 왼쪽에서 오른쪽으로, 우리는 2000 년대 이전과 액세스 할 수있는 전통적인 스택에서 벗어났습니다. 전체 환경에 적용 할 수 있습니다. 그러나 시간이 지남에 따라 점점 더 복잡해졌습니다. 2000 년대 초부터 2000 년 중반까지, 2000 년 후반에서 현재까지 인프라 서비스, 플랫폼 서비스, 소프트웨어 서비스에서 현재 비즈니스 서비스를 언급하고 있습니다. 그리고 복잡성이 크게 증가했습니다. 움직이는 부분이 너무 많습니다. 그러나 기술의 가용성은 점점 더 어려워지고 점점 더 어려워집니다. 올바른 기술을 가진 사람을 찾아 올바른 도구에 대한 올바른 액세스 권한을 가지고이 스택에 들어가 다이빙을하는 곳을 찾아보십시오. 내 랩톱 또는 데스크톱, 내 휴대폰 또는 태블릿, 3G 또는 4G를 통한 연결 또는 ADSL 또는 ISDN과의 전용 링크입니까? 요즘에는 전화 접속이 더 적지 만 전화 접속도 가능합니다. 웹 서버가 끝났습니까? 웹 서버 내부에 있습니까? 앱 서버입니까? CPU의 메모리 및 디스크와 응용 프로그램 서버의 네트워크 성능에 문제가 있습니까? 데이터베이스가 거기에서 실행되고 있습니까?

그리고 당신은 상상할 수 있습니다, 당신은 빅뱅 이미지와 같은 종류의 확장을 시작하는 복잡성, 우리가 팔을 잡고 뛰어 들기 위해 노력하는 기술이 끊임없이 증가하는 거품에 대해 매우 빠르게이 그림을 그립니다. 지식과 해부 및 분리의 위치. 그리고 지금 우리는 데이터베이스 환경을 분리하고 그 데이터베이스를 분리하여 다이빙 할 수있는 능력을 가지고 있더라도 인간이 물리적 규모에 대처할 수없는 시대에 아주 많이 있습니다. 해당 데이터베이스 내의 세부 사항. 지금 관리해야하는 데이터베이스의 수가 급격히 증가하고 있습니다. 이제 모든 것이 데이터베이스에 의해 구동됩니다. 요즘에는 데이터베이스로 구동되지 않는 응용 프로그램이 거의 없습니다. 그리고 데이터베이스 유형도 빠르게 성장하고 있습니다. 더 이상 전통적인 SQL 데이터베이스 일뿐 아니라 때로는 SQL, 때로는 비 SQL, 때로는 그래프 데이터베이스, 때로는 문서 데이터베이스이기도합니다. 그리고 이러한 서로 다른 유형의 데이터베이스에는 이러한 서로 다른 유형의 함수가 있으며 결과적으로 각각의 성능 문제와 성능 기준이 다릅니다. 로깅 데이터베이스와 문서 데이터베이스는 기존 ACID 호환 ANSI 92 호환 SQL 데이터베이스와는 매우 다르게 수행되며 다른 기능을 수행합니다. 그리고 우리가 거기에 저장 한 것들의 유형.

우리는 내 생각에 에릭이 이것을 암시 한 것으로 생각합니다. 인간이 우리가 만들고있는 것의 복잡성과 우리가 만드는 속도, 그리고 우리의 속도를 따라 잡기 위해 고군분투하고 있다고 생각합니다. '이 인프라를 관리 할 수있는 유일한 방법이며 현재 직면하고있는 문제를 모니터링하고 해결하는 유일한 방법은 도구와 올바른 유형의 도구입니다. 그런 다음 항상 올바른 도구 생성 도구가 필요합니다. 실제로 백엔드 인프라를 이해하는 도구 더 이상 SQL 모니터 또는 SQL 쿼리 도구를 던지고 쿼리를 분리하여 작동하는 것을 확인하는 것은 더 이상 괜찮습니다. 실제로 쿼리의 형성과 쿼리를 구성하는 적절한 방법, 쿼리가 백엔드의 인프라와 통신하는 적절한 방법 및 수행 방식을 이해하는 도구가 필요합니다. 이러한 상호 작용의시기와 발생 순서를 살펴 봅니다.

그리고 그것은 훨씬 더 복잡한 도전이며 저를 반올림 질문으로 인도합니다. 즉, 우리가 개발하는 앱 스택의 복잡성이 증가함에 따라 성능 도구와이를 관리하는 데 필요한 도구가 필요합니다. 점점 더 똑똑해지고 더 많은 것을 볼 수있게됩니다. 또한 백엔드에서 실행되는 항목과 검색 할 수있는 대상, 상호 작용 및 성능이 전달되고 있음을 이해하기 위해이를 수행 할 수있는 분석 방법에 대해서도 훨씬 똑똑합니다. 왜 느리거나 빠른 성능을 발휘합니까?

그런 다음 IDERA에서 빌 엘리스 (Bill Ellis)의 사랑하는 친구에게 전달하여 오늘이 문제를 해결하는 방법에 대해 그가 무엇을 말해야하는지 살펴 보겠습니다. 빌, 너에게

빌 엘리스 : 좋습니다. 제 이름은 빌 엘리스이며 대단히 감사합니다. 우리는 내 응용 프로그램이 느리게 실행되고 정확한 시간을 얻을 수있는 시간에 대해 이야기 할 것입니다. IDERA 제품인 Precise가 무엇을 할 수 있고 어떻게 도움이되는지 살펴 보겠습니다. 많은 경우 최종 사용자가 전화를했기 때문에 성능 문제가 있음을 알게됩니다. 실제로 그 자체로는 큰 문제입니다. IT의 모든 사람들 중에서 전화가 울릴 때까지 아무도 몰랐습니다. 다음으로 큰 문제는 어떻게 우리가이 특정 개인을 돕는가하는 것입니다. 그것은 사소한 문제가 아닙니다. 이것에서 하나의 테이크 아웃이 있습니다. 그것은이 슬라이드 위와 그 너머에 있습니다. 그리고 나는 그것이 무엇인지 알 수 있기를 바랍니다. 그러나 앞에서 언급했듯이 응용 프로그램은 많은 다른 기술을 필요로하며 응용 프로그램 스택이 커지고 성장하고 있습니다. 그리고 많은 사람들이 브라우저를 통해 응용 프로그램에 액세스하고 놀랍게도 스크립트 등을 사용하여 브라우저에서 점점 더 많은 처리가 진행되고 있으며, 물론 네트워크, 웹 서버, 비즈니스 논리 코드 및 데이터베이스가 있습니다. 내가 고려해야 할 것은 모든 중요한 비즈니스 트랜잭션이 시간 카드보고, 재고 조회, 구매 주문, 데이터베이스 업데이트 여부에 관계없이 데이터베이스와 상호 작용한다는 것입니다. 따라서 데이터베이스는 실제로 성능의 기초가됩니다. 물론 데이터베이스는 스토리지의 다운 스트림에 의존하거나 켜질 수 있습니다. 이러한 각 기술은 밀접하게 연결되어 있으며 무슨 일이 일어나고 있는지 확인할 수 있습니다. 무엇을 측정 할 수 있는지 알아야합니다.

이제 우리가 찾은 한 가지는 많은 고객이 도구를 가지고 있고 각 기술에 대한 도구를 가지고 있지만 고객이 가지고 있지 않은 것은 컨텍스트라는 것입니다. 컨텍스트는 기본적으로 응용 프로그램 스택의 모든 계층간에 도트를 연결하는 기능이며 실제로는 비교적 간단합니다. 우리는 12 개의 계층으로 제한을 받았지만 기본적으로이를 변경하고 무제한의 계층을 가지며 혼합 환경을 지원하므로 기본적으로 정확한 솔루션으로 매우 복잡해질 수 있습니다.

이제, 이것은 높은 수준에서 문제를 해결하는 방법이며, 최종 사용자 트랜잭션 (click-to-disk)에 중점을 둔 트랜잭션에 중점을두고 있으며, 느리게 실행되고있는 리소스와 리소스를 소비하는 트랜잭션을 알려줍니다. – 전체 거래 시간뿐만 아니라 각 단계에서 소요되는 시간을 사용자의 위치와 수령 할 수 있습니다. 시간은 성능의 통화이며 리소스가 소비되는 위치도 표시합니다. 문제의 위치를 ​​미리 알지 못하므로 문제의 위치와 문제를 진단 할 수 있도록 각 계층에 적절한 메트릭스와 분석이 필요합니다.

오늘 프레젠테이션에서이 영역에 초점을 맞출 것입니다. 기본적으로 응용 프로그램 스택의 모든 계층에서 동일한 수준의 가시성을 제공하고 중요한 것은 이것이 누구인지를 알려주는 것입니다. 무엇을, 어디서, 그리고이 부분에서, 이것은 왜 우리에게 말할 것입니다. 그리고 그것이 문제를 아는 것만이 아니라 문제를 해결하는 데 절대적으로 중요한 이유입니다. 프레젠테이션에서 매우 분명하게 나온 또 다른 것은 불가능합니다. 자동화가 필요합니다. 그리고 자동화 란 사용자가 경고를하고 최종 사용자 커뮤니티 이전에 추세가 진행 중이며 추세 경고와의 편차가 발생했음을 알려주는 것을 의미합니다. 그리고 우리는 또한 모래에 라인을 제공합니다, 당신은 실제로 SLA를 위반합니다. 이제 여러분은 많은 다른 정보를 제공합니다 – 모든 사람이 뷔페를 소비 할 필요는없고, 어떤 사람들은 가벼운 간식을 먹고 싶어합니다. 이것은 샐러드입니다. 따라서 우리는 정보를 업로드 할 수있는 포털을 제공하므로 특정 사용자 만 있으면됩니다. 또는 성능에 관한 특정 커뮤니티의 정보가 필요합니다. 응용 프로그램이 느리게 실행되고 있습니다. 우리는 실제로 네 가지에 초점을 맞출 것입니다. 하나는 최종 사용자를 입력하는 위치입니다. 다시 한 번, 점들을 연결하는 컨텍스트와 연구의 세 번째 부분은 거의 90 %의 응용 프로그램 문제가 데이터베이스에 있음을 보여 주므로 대부분의 성능 솔루션이 하나의 SQL 문을 말할 수 있다는 것은 정말 비참한 일입니다. 그러나 그들은 왜 SQL 문이 느리게 실행되는지 알려주지 않습니다.

따라서 왜 항상 중요한 요소이며 Precise는 모든 계층 및 특히 데이터베이스에 대한 이유를 보여주고 SQL Server, Sybase, DB2를 지원하는 지원 매트릭스에 대해 약간만 공유합니다. 및 / 또는 벌크. 솔루션의 모양과 느낌은 매우 유사하므로 여러 응용 프로그램을보고 있지만 약간 다른 아키텍처를보고 있다면 여기서 공유하는 정보에는 모양과 느낌, 접근 방식이 있으며 사용중인 기본 기술이 무엇이든 관계없이 동일합니다. 정확한 웹 사용입니다. 우리는 들어 와서 Precise를 인증하고, 우리가 들어가면서 가장 먼저보고 싶은 것은 위치 별 성능입니다. 사람들이 실제로 그들의 처형에 접근하고있는 다른 장소들을 실제로 볼 수 있습니다. 누군가가 페이지를 완전히 렌더링하기 전에 페이지를 포기했는지 또는 오류가 있는지 확인할 수 있습니다.

이제 이러한 응용 프로그램의 한 가지는 네트워크 또는 응용 프로그램 서버와의 거리가 달라진다는 것입니다. 여기에는 어느 정도의 네트워크가 있다는 것을 쉽게 알 수 있습니다. 사람들이 바쁠 때, 또 다른 흥미로운 점을 알 수 있습니다. 브라우저 내에서 처리되는 방법에 대해 이야기했습니다. 실제로 다른 브라우저 유형 중 일부는 빠른 처리를 위해 더 나은 환경을 제공한다는 것을 알았습니다. 따라서 사람들이 Chrome 또는 IE를 통해 액세스하는지 또는 무엇이든지간에 알면 실제로 한 브라우저 유형 반전이 실제로 다른 브라우저 유형보다 우수하다는 것을 알 수 있습니다. 때로는 공개적으로 직면하고 브라우저를 제어하지 않으며 때로는 응용 프로그램이 내부 사용자를 대상으로 최종 사용자 커뮤니티에 브라우저 유형을 추천 할 수있는 경우가 있습니다. 정확한 제공 할 수 있습니다. 이제 응용 프로그램을 살펴 보겠습니다.

너희들이 내 포인터를 볼 수 있는지 확실하지 않지만, 나는 최고의 그래프 인 당신에게 설명하고 싶었다. y 축은 평균 응답 시간을 보여줍니다. x 축은 하루의 시간입니다. 실제로 누적 막대 그래프와 누적 막대 그래프가 있습니다. 총계에는 성능이 무엇인지 표시 한 다음 각 개별 단계 또는 응용 프로그램의 개별 계층에서 소요되는 시간의 계층이 표시됩니다. 클라이언트에서 웹 서버를 통해 녹색은 Java이며, 여기서 우리는 Tuxedo를 사용하고 데이터베이스로 내려갑니다. 이제 화면의 아래쪽 절반에는 액세스중인 다양한 웹 메뉴가 표시되며 작은 녹색 화살표가 아래쪽을 향하도록 분류되었습니다. 내림차순으로 맨 위로 올라가면 웹 메뉴에 표시됩니다. 우리는 실제로 각 개별 기술의 실행 시간과 응답 시간을 보여준 다음 실제로 각 웹 메뉴에 대한 막대 그래프를 보여 주므로 진행 상황에 대한 아이디어를 얻습니다. 이제이 모든 것을 최종 사용자가 호출 할 것으로 정렬했지만 최종 사용자를 어떻게 찾을 수 있습니까? 여기로 들어 와서 특정 사용자를 필터링 할 수있는 메뉴를 열었습니다. 따라서 해당 사용자를 Alex Net으로 설정하고 확인을 클릭 한 다음 Alex Net의 활동에만 집중합니다. 이제 이것이하는 일은 IT 및 IT 관리가 최종 사용자에게 직접 응답 할 수있게하고 특히 응답 시간이 3 초 정도 인 6 회 실행되는 컨텐츠 관리를보고 있다는 것입니다. 글쎄, 3 초는 꽤 좋지만, 끔찍하지는 않지만, 아마도 느릴 수 있습니다.

내가 할 수있는 일은이 정보를 다른 방법으로 썰어 죽일 수 있다는 것입니다. 나는이 거래가 모두에게 느리다고 말할 수있다. Alex의 어제보다 오늘이 더 느립니까? 특정 위치 내의 모든 사용자에 대해 속도가 느립니까? 또는 그것이하는 일은 제가 일종의 슬라이스와 주사위를 사용하여 무슨 일이 일어나고 있는지, 문제가 얼마나 보편적이며 최종 사용자를 식별 할 수 있는가에 대한 아이디어를 얻을 수있게하는 것입니다. 인프라, 또한 최종 사용자가 응용 프로그램을 실행하는 방법에 관한 것입니다. 종종 새로운 직원이나 새로운 직무를 가진 사람이있을 수 있으며 특정 SAP 화면이나 특정 PeopleSoft 패널에 익숙하지 않고 작은 포인터가 필요합니다. 필드를 비워 두거나 와일드 카드를 넣을 수 있습니다. 큰 결과를 데이터베이스에서 강제로 반환합니다. 그러나 사용자 ID가 있으면 실제로 전화하기 전에 전화를 걸 수 있습니다. 우리가 찾은 또 다른 사실은 사용자 커뮤니티가 IT가 자신이하는 일을 알고 있다는 사실을 알게되면 많은 시간과 문제가 생겨 났으며, 많은 문제가 있었으며, 사람들은 행동하기 때문에 조금 더 조심스럽게 운영해야합니다. 그들은 시스템을 더 세 심하게 사용합니다.

최종 사용자 식별은 필수적입니다. 결국 IT 부서가 특정 최종 사용자를 도울 수 있어야합니다. 이제 우리가 한 일은 "Flow"탭으로갔습니다. 왼쪽 상단에서 볼 수 있습니다. 우리는 웹 메뉴의 특정 구성 요소에 중점을 두었습니다. 그리고 오른쪽에는 특정 트랜잭션에 대한 분석이 있습니다. 맨 위에는 실제로 브라우저와 뷰가 있습니다. GUI 내의 작은 아이콘에 익숙해지는 것은 웹 서버에 대한 것입니다. 속성 포인트를 볼 수 있습니다. 그리고 "J"는 Java를위한 것이고 "T"는 Tuxedo를위한 것이고 자연스럽게 "Q"는 SQL입니다. 현금 가치는 기본적으로 특정 SQL 문을 식별합니다. 이것이 무엇을하는지 고려하십시오. 개별 SQL 문을 포함하여 트랜잭션, 기본 애플리케이션 코드에 대한 사용자를 식별했습니다. 이제 개별 SQL 문을 살펴보면 총 응답 시간을 확인할 수 있으며 각 응답 시간은 약 6 %이며 상위 4 개의 SQL 문을 추가하면 트랜잭션의 1/4이 소요됩니다. 시각.

이제 데이터베이스는 조작하기 가장 쉬운 경우가 많습니다. 일반적으로 저렴하고 훨씬 우수한 성능을 얻는 것이 가장 쉽습니다. 이제 무슨 일이 일어나고 있는지, 무엇을하는지 알아 내기 위해 조금 더 깊이 들어가야합니다. 예제를 통해 실제로 개별 SQL 문을 공개하고 싶습니다. 라인의 모든 샷으로 거의 보장 할 수 있다는 것을 알고 있습니다. 어떤 종류의 데이터베이스 도구와 데이터베이스 도구의 기능을 가지고 있지만 하나의 기술 만 따로 살펴보면 기술의 건강에 초점을 두는 것입니다. 그리고 많은 사람들이 톱 10리스트를 봅니다. 이제이 SQL 문은 매우 빠르며 상위 10 개 목록에 포함되지는 않지만이 트랜잭션이 의존하는 SQL 문입니다. 그리고 그 맥락에서 다시 할 수있는 것은 이제이 내용을 개별 SQL 문의 맥락에서 깊은 시선에 집중시킬 수 있다는 것입니다.

이제 해당 개인이 개별 SQL 문의 컨텍스트에서 Precise를 열 수 있으며 Precise는 실제 실행 계획을 캡처합니다. 실행 시간은 DBA에게 중요한 사항 인 실행 시간을 실제로 보여줍니다. 저장 대기 시간이 소요됩니다. 50 %의 시간이 CPU에서 사용되므로 시간이 소비되는 위치, 시간을 어떻게 줄일 수 있는지에 대한 아이디어를 얻기 시작하고 아이디어에 따라 비용과 위험이 다르므로 사람들에게 옵션을 제공하는 것이 좋습니다 . 이상적으로는 문제에 대한 저비용 저비용 솔루션을 따르는 것입니다. 이제 SQL 문은 해시 값으로 추적되며 화면의 왼쪽 가운데에는이 작은 "Tune"버튼이 있으며, 수행 할 작업은 SQL 작업으로 이동하는 것입니다. 그리고이 SQL 작업은 일종의 사전 구축 된 워크 벤치이며이 작업은 실행 계획으로 시작하는 SQL 문에 어떤 영향을 미치는지 구체적으로 분석 할 수있게 해줍니다. 실행 계획은 명령문이 구문 분석 될 때 옵티마이 저가 선택합니다. 즉, 음식 비유로 돌아가서 SQL 문을 해결하기 위해 따르는 레시피입니다.

그리고 일부 레시피는 다른 레시피보다 복잡하므로 결과를 제공합니다. 실제로 여기에 표시됩니다. 특정 인덱스에서 순차적 I / O를 수행하는 데 많은 시간이 걸립니다. 이제 산소로 돌아 가면이 지수를 따르십시오. 해당 인덱스가 최근에 조각 모음 되었습니까? if의 상태는 어떻습니까? 어떤 테이블 스페이스에 있습니까? 테이블 스페이스가 참조하는 테이블로부터 분리되어 있습니까? 그리고 문제 해결 방법에 대한 모든 종류의 아이디어를 제공하기 시작합니다. 분명히, 우리는 인덱스를 구축하고 있습니다. 하나의 테이블 스페이스에서 다른 테이블 스페이스로 인덱스를 이동하는 것보다 훨씬 낮은 위험을 감수 할 수 있습니다. 따라서 우리가 원하는 것은 일종의 빌드 옵션으로, 가장 낮은 비용으로 가장 낮은 위험 옵션을 배포 할 수 있습니다 문제를 해결하기 위해.

Precise는 SQL 문에 캐스트되는 바인드 변수 캡처와 같은 작업도 수행 할 수 있습니다. 캐스트 된 변수는 결과 집합의 크기를 제어 할 것입니다. 또한 SQL 문을 실행하는 데 걸리는 시간과 Java, .NET을 통해 응용 프로그램에서 웹 서버 캐스트와 네트워크로 최종 데이터를 최종 사용자 브라우저로 전달하는 데 얼마나 많은 데이터를 전달하고 처리해야하는지 제어합니다. . 데이터베이스에서 발생하는 일은 해당 브라우저 시간에 직접 영향을줍니다. 따라서 현재 상황을 정확히 파악하고 DBA에 가장 많은 옵션을 제공하여 특정 상황에서 가장 적합한 옵션을 선택할 수 있도록이 수준의 가시성을 확보하는 것이 중요합니다.

자, 이것들은 몇 가지 인용문이며 이것들은 전 세계적으로 배포 된 PeopleSoft 상점에서 나왔습니다. Precise는 PeopleSoft 및 SAP, Siebel, Oracle, E-Business Suite, 자체 개발 Java 및 .NET 애플리케이션을 지원합니다. Java에서 .NET으로, 다시 Java로 여러 JVM에 대한 웹 서비스 호출을 수행하면 모든 것을 추적 할 수 있습니다. 온 프레미스 일 수도 있고 클라우드에있을 수도 있습니다. 중요한 것은 사물을 계측해야한다는 것입니다.

따라서 고객 중 한 사람으로부터 몇 가지 인용 만하면됩니다.“정확하게 말하자면, DBA는 OEM을 사용하고있었습니다.”– 데이터베이스 전용 도구이며 기본적으로는“인스턴스가 훌륭해 보입니다.”라고 말했습니다. 특정 거래 관련 문제를 말하거나 해결하는 데 도움이됩니다. 정확한 가시성을 제공했습니다. 따라서 SQL 문에 대한 정보를 확보하는 것은 DBA에게 데이터베이스에서 성능을 완전히 끌어낼 수있는 가시성을 제공하는 데 중요했습니다. 그래서 정말 좋았습니다. 당신이보고있는 몇몇 도구의 위와 그 이상.

그리고 IT 관리는 Precise가 복잡한 URL을 패널 이름으로 변환 할 수 있다는 사실을 정말 좋아했습니다. 그렇게하면 최종 사용자가 전화를 걸어 "이 문제가 있습니다"라고 말하면 해당 사용자가 누구인지, 실행 중인지, 어떤 종류의 성능으로 실제로 렌더링을 측정하는지 확인할 수 있습니다. 최종 사용자의 브라우저에서 시간. 최종 사용자 경험의 진정한 척도입니다. 또한 해당 사용자 ID를 갖는 것은 전화하는 특정 사람을 돕는 데 절대적으로 필요합니다.

Precise는이를 어떻게 수행합니까? 우리는 아키텍처를 공유하고 싶습니다. 정밀성은 자체 서버에 있어야하며 VM에 있어야하며 클라우드에있을 수 있습니다. 프런트 엔드에서 Precise는 대시 보드, 경고 인터페이스 또는 Expert GUI를 사용하든 웹에서 사용할 수 있습니다. 데이터 수집 측면에서 실제로 여러 가지 다른 기술에 대해 에이전트없는 작업을 수행 할 수 있습니다. 그러나 종종 에이전트가 필요하며 에이전트를 보유 할 때의 장점과 단점이 있습니다. 큰 장점은 수집 된 데이터가 LAN을 통해 전송되기 전에 사전 처리 될 수 있다는 것입니다. 따라서 모니터링 솔루션이 대상 환경에 미치는 총 영향을 최소화 할 수 있습니다.

이제 "에이전트없는"에이전트가있는 경우 대안으로 고려해보십시오. 여전히 데이터 수집기가 있으며 데이터 수집기는 어디에 있든지 문제가되지 않으며 LAN을 통해 대상 응용 프로그램에 대한 원시 데이터를 호출하고 전달합니다. 그리고 실제로 꽤 비쌉니다. 따라서 전처리를 통해 실제로 설치 공간을 최소화 할 수 있습니다. 실제 및 가상을 모두 모니터링 할 수 있습니다. 가상 기술에 대해 말하고 싶은 한 가지는 실제로 사용에 관한 것입니다. Precise가 중점을 둔 것은 경합입니다. VMware 기술이 실제로 게스트 VM에 대한 리소스를 최소화하는시기는 언제입니까? 정말 쉬워집니다. 게스트 VM 내에서만보고 있다면 그림의 일부만있는 것입니다. 경합을 자동으로 감지하고 경고 할 수 있기 때문에 정말 중요합니다.

Precise는 최대 500 개의 인스턴스를 모니터링 할 수 있으므로 대규모 배포에는 기본적으로 여러 개의 Precise 서버가 있습니다. 그리고 글로벌 배포의 경우 일반적으로 각 데이터 센터에 정확한 서버가됩니다. 또한, 가장 큰 배포의 경우 실제로 이들을 함께 연합하여 진행 상황을보고보고 등을 제공 할 수 있습니다. 지금까지 언급했듯이, 우리는 많은 기술적 분석을 수행했습니다. 모든 사람이 전문가 GUI에 들어 가지 않아도되므로 맞춤형 대시 보드를 제공합니다. 그리고이 포틀릿 또는 위젯 각각은 모두 선택적입니다. 그리고 누군가가 가고 싶을 수도 있습니다.“이봐, 우리 환경의 어떤 계층에 대해 어떻게 경고를 할 수 있습니까? 최종 사용자 그룹이 성능 관점에서 어떻게 수행하고 있습니까?”또는 어쩌면 Tuxedo 성능에 영향을 미치는 인프라에 대한 질문이있을 수 있습니다. 또는로드 밸런싱도 가능합니다. 이로드 밸런싱 부분에서 흥미로운 점이 있습니다. 왼쪽 중간에있는 포틀릿을보고 있습니다. 각 웹 서버간에 실행 수가 매우 비슷하다는 것을 알 수 있습니다. 그러나 응답 시간은 최상위 시간과 매우 다릅니다. 실제로 해당 웹 서버의 응답 시간이 다른 웹 서버의 응답 시간보다 훨씬 느린 이유를 정확히 파악하고 정확히 찾을 수 있습니다.

로드 밸런싱에 관한 한 가지는 매우 중요하며로드 밸런싱 정책은 모든로드 밸런싱 정책이 모든 애플리케이션에 적합한 것은 아닙니다. 실제로로드 밸런싱 정책의 유효성을 검사하는 것이 실제로 도움이됩니다. 실제로 새로운 PeopleSoft Fluid GUI와 같은 일부 응용 프로그램에서는 실제로 일부 웹 서버가 오프라인 상태가됩니다. 그리고 그것은 정말로 중요한 것입니다. PeopleSoft Fluid GUI를 배포하는 경우 문의하십시오. 우리는 다른 고객이 직면 한 것에 대한 많은 통찰력과 지식을 제공 할 수 있습니다. 이 포틀릿 각각은 매우 상세 할 수 있습니다. 파란색과 녹색이있는 가운데 오른쪽과 마찬가지로 실제로 검 끝 패턴이 표시됩니다. WebLogic 계층 내의 가비지 수집이 예상대로 실행되고 있음을 보여줍니다. 이 포틀릿 각각은 집중도가 높거나 레벨이 높을 수 있습니다. 그리고 그것이 중요하거나 중요 할 수있는 이유는 IT 내에이 정보를 두는 것만으로는 충분하지 않은 경우가 많으며, 때로는이 정보를 응용 프로그램 소유자 및 때로는 고위 경영진과 공유해야하는 경우가 있습니다. .

나는“데이터 센터에서의 성공”이라는 몇 가지 이야기를 여러분과 나누고 싶었습니다. 그리고 이것들은 데이터베이스에 중점을두고 있으며 다른 계층에 중점을 둔 이야기가 있습니다. 하지만 오늘은 데이터베이스 계층에 집중하고 싶습니다. 화면 정지를 살펴 보겠습니다. 이제이 특정 상점에는 비즈니스 SLA가 있었으며 오후 3 시까 지 주문을 받으면 그 날 주문이 배송됩니다. 따라서 그 기간 동안 창고는 매우 바쁩니다. 그리고 화면이 정지되면서 매우 실망 스러웠습니다. 그래서 감독자 (이것은 소규모 회사 임) – 감독자는 실제로 IT 부서에 들어 갔으며 물론 DBA로 올라가서“지금 ​​무슨 일이 일어나고 있습니까?”라고 말합니다. 그리고 우리가 한 일은 정확하게 보여줄 수있었습니다 무슨 일이 있었 니. 이제 이것은 다중 계층 응용 프로그램 인 JD Edwards이며 판매 주문 화면입니다. 비즈니스가 무엇인지, 기본적으로 적시에 재고에 대한 아이디어를 얻을 수 있으므로 기본적으로 창고 응용 프로그램을보고 있습니다. 이제 기본적으로 다양한 고객 사이트, 여러 상점에 배송하고 있습니다. 우리가 한 일은 Precise를 열었습니다.

이 경우 Oracle을 살펴보기 전에 SQL Server를 살펴 보았습니다. 이제 절반은 SQL 문이 실행하는 동안 시간을 ​​보내는 위치를 나타내는 막대 그래프를 보여줍니다. 모든 약한 상태는 y 축에서 설명됩니다. 물론 x 축은 시간이 지남에 따라 누적 막대 그래프가 실행중인 내용과 시스템 사용 방법에 따라 시간 조각에서 변경되는 것을 볼 수 있습니다. 이 특별한 경우에 우리는 위에서부터 세 번째 SQL 시퀀스에 중점을 두었습니다. PS_PROD에 SELECT FROM이라는 텍스트가 있으며 해당 열에서 실제 실행 계획을 캡처 한 것을 확인할 수 있습니다. 그리고 당신은 실행 횟수를 통해 볼 수 있습니다. 이 특정 SQL 문이 우리가보고있는이 시간 동안 리소스 소비의 9.77 %를 차지했다는 사실 – 정확한 시점 인 정확한 시간은 정확한 기록을 유지하므로 기본적으로 전화를 걸 수 있습니다. 특정 시점 또는 시간에 어떤 일이 있었는지 확인하십시오. 트렌드를 볼 수 있습니다.

이제이 SQL 문에서 스택 막대 그래프가 진한 파란색임을 알 수 있습니다. 그것은 우리가 모든 CPU를 사용하고 있다고 말합니다. 계속해서 특정 SQL 문에서“TUNE”버튼을 클릭하여 초점을 맞추십시오. 우리가하는 일은“이 특정 SQL 문에 대해 DBA가 무엇을 알게 될까요?”라고 말하는 사전 제작 된 워크샵에 해당 워크샵을 가져가는 것입니다. 그리고 오른쪽에“라는 탭이 있습니다. 히스토리”가 선택되었습니다. 그리고 여러분이 지금하고 싶은 것은 왼쪽으로 넘어 가서 "Changes Duration Duration Average"라는 평균 지속 시간입니다. 그리고 각 막대는 하루의 이벤트를 나타냅니다.

수요일, 목요일, 금요일에 실행 시간을 알 수 있습니다. 2 점으로 반올림합니다. y 축은 포인트 4 초를 나타내므로 포인트 2입니다. SLA에서 화면 정지가 거의없고 작업이 크게 진행되고 있습니다. 불행히도 2 월 27 일에 실행 계획이 변경되어 실행 시간이 즉시 변경되었습니다. 갑자기 실행 시간이 길어지고 4 X, 아마도 5 X가되고 실제로는 제대로 작동하지 않습니다. 이제 저장소의 Precise는 실제로 동작에 영향을 줄 수있는 모든 변경 사항을 저널링합니다. 여기에서 실제로 축 평면 변화를 포착 한 것을 볼 수 있습니다. 중간에있는 테이블에 "테이블 볼륨이 변경되었습니다"라고 표시되어 테이블이 커지고 있으며 SQL 문을 구문 분석 할 때 옵티마이 저가 하나의 실행 계획 또는 다른 실행 계획을 선택합니다.

운 좋게도 이번 주 월요일 월요일에 튀어 나와서 좋은 시간을 보냈습니다. 불행히도 다시 플립 플롭하고 최종 사용자가 화면 정지를 예상하고 해당 화면을 다시 제출하기 시작하고 실행 카운트를 올리거나 올리는 것을 알 수 있습니다. 우리는 많은 세부 사항을 가지고 있지만이 문제를 해결하고 나중에 피하기 위해서는 하나의 추가 정보가 필요합니다. 그리고 그것은 그 실행 계획을 비교하여 나에게 보여졌습니다. 빠르고 효율적인 3 월 5 일 왼쪽에는 실행 계획이 표시됩니다. 3 월 12 일에 느리고 비효율적이었을 때 필터 조인이 수행되고 있음을 알 수 있습니다. 필터 조인은 훨씬 더 많은 CPU 소비를 강요하여 더 많은 작업을 수행합니다. 결과는 동일하며 더 많은 작업을 수행하고 있습니다. 식료품 저장실에 가서 모든 재료를 한 번에 얻는 것이 아니라 한 번에 한 가지 재료 만 가져가는 것과 같습니다. 그리고이를위한보다 효율적인 방법이 있습니다. 일반적으로 DBA는 쿼리 계획을 사용하여 이러한 느린 실행 계획을 피하고 빠르고 높은 성능으로 고정 할 수있었습니다.

다음 번의 전쟁 이야기는“보고서는 늦었습니다.”라고 생각합니다. 많은 사람들이이 시나리오를 통해 확인할 수 있습니다. 임시보고가 있거나 NVISION과 같은 도구를 사용하거나 타사보고 도구가있을 수 있습니다. 그리고 도구는 SQL을 개발합니다. 그리고 종종 SQL은 실제로 잘 코딩되지 않습니다. 그리고 이것은 또한 당신이 알다시피, SQL이 사내에서 작성되지 않은 일부 타사 응용 프로그램이 있고 DBA로서“나는 SQL을 제어하지 않습니다. Well Precise는 다른 데이터베이스 도구가 제공하는 것을 알지 못하는 객체 뷰를 제공합니다. 권장 사항 및 모델링과 결합되었습니다. 우리가 할 수있는 것은 실제로 가시성을 머리에 돌리는 것입니다. 단순히 활동을 보지 말고 시스템에서 가장 무거운 물체를 조사해 봅시다. 화면 하단에는 주문 라인 SQL이 표시되고“in MS-SQL”열이 표시됩니다. 그리고 주문 라인 테이블은 시스템의 다른 테이블보다 10 배 더 바쁩니다. 상반기에 주목할 사항, 공간 할당이 증가하고 있으며 서버에서 실행중인 소프트웨어 버전을 확인할 수도 있습니다. 정확한 경우 실제로 기본 설정에 대한 추적 된 변경 사항을 확인합니다. 다시 한번, 원인과 결과.

이제 주문 라인 테이블에 중점을 둔 세부 히스토리 저장소로 수행 할 수있는 작업은 실제로 주문 라인 테이블에 대한 SQL 문을 상관시킬 수 있다는 것입니다. 그리고 해당 SQL 문에서 where 절을 살펴볼 수 있습니다. 그리고 where 절은 다른 SQL 문 사이에서 매우 유사하다는 것을 알기 시작합니다. 그리고 녹음 시스템에서도 같은 것을 찾을 수 있다고 제안합니다. 비즈니스 사용자는 비즈니스 분석가가 마지막 날, 지난 주, 지난 달, 지난 분기, 지난 해에 걸쳐 총체적인 비즈니스 활동을 수행하려고합니다. 매우 유사한 where 절, order by, group by를 볼 수 있으며 이는 해당 SQL 문에 적합한 특정 인덱스가 있음을 의미합니다.

Precise에는 추천 엔진이 있습니다. 오른쪽 상단에서 실제로 볼 수있는 것은 추천을받는 것입니다. “이봐 요, 모든 SQL 문을 실행하고 있는데, 어떤 인덱스가 이들을 처리합니까?”라고 말합니다. 인덱스가 제공되며 실제로 DBL을 볼 수 있습니다. 이제 Precise는 읽기 전용이며 버튼을 클릭하고 인덱스를 생성하는 기능을 제공하지 않지만 Precise 외부에서 수행하는 것은 쉽습니다. 그러나 여기에 중요한 것은 Precise를 사용하여 변경 사항을 평가하고 모델링 할 수 있으므로 화면 왼쪽 하단에이 평가 버튼이 있다는 것입니다. 그리고 그것이하는 것은 전과 후의 SQL 문을 보여줍니다.

이 SQL 문을 보자. 이 열에“MS-SQL에서”라고 표시되어 있고 1 시간 4 분이라고 표시되어 있습니까? 이 최상위 SQL 문은 약 64 분 분량의 리소스를 실행하거나 소비합니다. 예상되는 개선율은 98 %입니다. 이러한 변경으로 처리 시간을 절약 할 수 있습니다. 다음 SQL 문은 27 분이며 기본적으로 1/3을 저장합니다. 약 10 분의 처리 시간입니다. 함께 요약하면 이러한 제안 된 변경 사항으로 처리 시간과 시간을 절약 할 수 있습니다. 그리고 이것을 미리 알 수 있고, 이것을 모델링 할 수 있습니다. "가정 (what-if)"기능을 사용하여 "글쎄, 색인을 만들고 싶지 않거나 열 순서를 변경하면 어떻게됩니까?"라고 말할 수도 있습니다. 따라서이 모델링 기능을 사용할 수 있습니다. 정확히 무슨 일이 일어날 지 알아 내야합니다.

중요한 또 다른 사항은 변경을 할 때 실제로 개별 SQL 문을 측정 할 수 있다는 것입니다. 이전 예제에서 SQL 문 히스토리를 보았으며 모델링 된 절감 효과를 실제로 달성했는지 확인할 수 있습니다. 따라서 피드백 루프를 완성하는 것이 절대적으로 중요합니다.

좋아, 여기 내가 너에게 줄 마지막 예가있다. 이것은 SAP 상점이며, 주요 업그레이드를 위해 갔고, 사용자 정의 트랜잭션으로 몇 가지 작업을 수행했으며, 최종 사용자는 기본적으로 성능에 만족하지 않았습니다. 우리가 한 일은 최종 사용자가 경험 한 것에 집중할 수 있다는 것입니다. 목록 상단에서“CHOUSE”를 볼 수 있으며 응답 시간이 61 초가 조금 넘습니다. 이 작업을 실행하는 데 1 분이 걸립니다. 이제 SAP에 맞춰진 누적 막대 그래프가 있습니다. 오른쪽에는 클라이언트 시간, 대기 시간이 표시됩니다. 파란색은 응용 프로그램 시간이며 SAP 환경에서 ABAP 코드이고 데이터베이스입니다. 데이터베이스는 Oracle 일 수도 있고 SQL 일 수도 있고 HANA 일 수도 있습니다. 우리는 기본적으로 그것을 보여줄 수 있습니다.

이제 Precise로하는 일은 해당 트랜잭션과 해당 사용자에 대해 SQL 문이 나오는 것에 집중하는 것입니다. 다시 한번, 그 맥락은 점들을 연결합니다. 이제이 최상위 SQL 문에서 원이 표시되어 2 밀리 초 안에 실행됩니다. 데이터베이스가 너무 빨리 실행되면 데이터베이스를 탓할 수 없습니다. 실행 횟수가 매우 높습니다. 실제로 우리는 ABAP 코더로 돌아가서“이봐, 무슨 일이야?”라고 말할 수 있습니다. 우리는 실제로 데이터베이스의 코드가 잘못된 위치에 있고 루프 내의 잘못된 위치에 중첩되어 있음을 발견했습니다. 변경 후 우리는 측정 할 수 있습니다. 실제로 성능이 무엇인지 확인할 수 있습니다. SQL 문 레벨뿐만 아니라 사용자 정의 코드 레벨에서도. 그래서 그들은 4 초 반의 실행 시간으로 살 수있었습니다. 그리고 이것은 Precise가 어떻게 활용 될 수 있는지에 대한 몇 가지 예일뿐입니다. 빠른 요약과 마찬가지로 Precise는 위치 별, 최종 사용자 ID별로 성능을 보여 주므로 응용 프로그램 스택을 통해 컨텍스트를 제공합니다. 근본 원인을 파악할 수 있습니다. 그리고 가장 큰 차별화 요소 중 하나는 SQL 문뿐만 아니라 SQL 문이 왜 느리게 실행되고 있으며 경합을 식별하고 기본적으로 문제 해결을위한 더 많은 옵션을 제공 할 수 있어야한다는 것입니다. 이것이 바로 Precise가 제공하는 것이므로, 가벼운 방법으로 또는 매우 깊고 매우 어려운 문제가있는 경우에도 당사를 이용할 수 있습니다.

에릭 카바나 흐 : 좋아, 나는 그것이 환상적인 세부 사항이라고 말해야한다. 빌. 모든 스크린 샷을 보여 주셔서 감사합니다. 그리고 내 관점에서 당신은 내가 시간의 맨 위에 설명하는 것을 정말로 성취했습니다. 첫째, 당신은 올바른 도구를 가져야합니다. 누군가가 영화에서 한 번 말했듯이 방정식의 모든 요소를 ​​식별하는 데 필요한 컨텍스트 양을 허용하는 도구가 있어야합니다. 그러나 그가 당신에게 몇 가지 질문이 있고 내 생각에 시각적 사탕을 위해 슬라이드를 하나 더 밀고 싶기 때문에 Dez에게 넘겨 주겠습니다. 사실, 잠시만 기다려주세요. 하지만 데즈, 당신은 몇 가지 질문이 있으리라 확신합니다.

Dez Blanchfield : 그래, 와우. 이 도구는 처음에 알고 있었기 때문에 먼 길을 갔으며 실제로 실제로 스택에 너무 깊이 들어가는 것을 알지 못했습니다. 그것은 꽤 마음이 흔들리는 것입니다. 정말 빨리, 몇 가지. 배포 모델은 1 ~ 2 분 안에 기존 또는 일반적인 배포 모델을 간략하게 설명 할 수 있습니다. 가상 머신으로 사용 가능하다고 언급했습니다. 클라우드에서 실행할 수 있습니다. 그리고 아마도 제기 될 질문 중 하나를 추측하고 Q & A 섹션에 몇 가지 질문이 있다고 생각합니다. 간단히 요약하면 일반적인 배포 모델과 필요한 축 유형은 전통적으로 온 프레미스 또는 호스팅 또는 클라우드에 배포됩니까? 일반적으로 표시되는 배포 모델 유형은 무엇입니까? 그리고 그것을 작동시키기 위해서는 어떤 축이 필요합니까? 네트워크 액세스 등의 보안 수준에서 사항을 변경해야합니까? 아니면 최종 사용자처럼 행동 할 수 있습니까?

Bill Ellis : 예. 현재 대부분의 설치가 온 프레미스입니다. 점점 더 많은 사람들이 애플리케이션 스택의 구성 요소를 클라우드에 배치하고 있으므로이를 처리 할 수 ​​있습니다. 배포 할 서버가 필요하면 특정 사양을 충족해야합니다. 히스토리 저장소를 저장할 데이터베이스가 필요하므로 이러한 전제 조건을 충족시키는 것이 첫 번째 단계입니다. 다음은 응용 프로그램 자체에 대한 지식이 필요하며 설치는 마법사 기반이며 기본적으로 공백을 채우는 것입니다. 우리가 얻는 정보의 깊이 때문에 웹 프로세스 수준에서 실행되는 코드에 이르기까지 몇 가지 권한이 필요합니다. 에이전트는 트랜잭션 등에 대한 메타 데이터를 사용하는 사람과는 완전히 다른 자격 증명으로 에이전트를 실행하기 때문에 보안 데이터 모델 또는 보안 모델이 있습니까? Precise는 TCP over IP를 통해 통신하므로 특정 포트가 열려 있어야합니다. 간단한 예로, 기본 포트는 2702입니다. 사람들이 관심이 있다면 이러한 유형의 세부적인 내용은 좀 더 자세하게 알아볼 수 있습니다. 그러나 일반적으로 가치가 매우 빠릅니다. 누군가 큰 문제에 직면하고 있다면, 우리는 종종 물건을 설치하고 몇 시간 안에 상황에 밝은 빛을 비출 수 있습니다.

Dez Blanchfield : 그래, 나도 그런 의미가있다. 배포 모델에서는 매우 큰 규모와 최대 500 개의 인스턴스 및이를 페더레이션 할 수있는 방법에 대해 설명했습니다. 바로 엔트리 레벨에서 누군가가 원한다면 어떻게 생겼는가 – IDERA가 무료 평가판, 무료 데모에 대한 액세스를 제공하는 데 매우 큰 것을 알고 있기 때문에 웹 사이트에서 거의 모든 종류의 게임을 볼 수 있음을 기억합니다. 여기에있는 사람들을 위해, 나는 이전에 그것을 놓쳤다 고 생각하지만, 전형적인 사이트는 어떻게 생겼으며 사람들이 이것에 접근하여 게임을 시작하고 그 유형을 얻는 방법에 관한 질문이 있다고 생각합니다. 성능 문제를 해결할 수있는 방법이 있는지를 알 수있는 경험이 있습니까? ODS를 다운로드하여 하이퍼 바이저, Hyper-V 또는 랩톱에서 작동시킬 수 있습니까? 아니면 ODS를 실행할 전용 시스템이 필요합니까? 예를 들어, 개념을 증명하기 위해 엔트리 레벨 배포에서 아키텍처가 어떻게 되었습니까?

Bill Ellis : 예, 우리 모델은 IDERA 도구와 약간 다릅니다. 영업 담당자에게 문의하려는 Embarcadero 시나리오에 더 적합합니다. 우리는 당신에게 도전 과제에 대해 논의하고 싶습니다. 그리고 우리는 일반적으로 SE 중 하나가 할당되고 기본적으로 누군가와의 설치를 통해 작동 할 것입니다. 일반적으로 랩톱에서 Precise를 실행하지 않습니다. 콜렉션을 수행하기 위해 애플리케이션이 상주하는 데이터 센터 내에 VM 또는 서버가 있어야합니다. 그러나 우리는 그 모든 단계를 통해 당신을 도울 것입니다. 그것을 추구하고 싶은 사람이 있다면, IDERA에 연락하고 싶을 것입니다.

Dez Blanchfield : 저를 강타한 다른 것 중 하나는 오늘 우리가 다룬 것은 성능 문제에 대한 반응이라는 것입니다. 그러나 사람들이 사용하는 라이브 환경에서 첫 번째 슬라이드 쇼와 같이 누군가 전화를 들고“응용 프로그램이 느리게 실행되고 있습니다.”라고 말한 것 같습니다. 그러나 응용 프로그램의 시험판 또는 업그레이드 또는 새로운 패치 및 수정을 통해 여러 용량 계획 및 스트레스 테스트를 수행하고 전체 환경을 정확하게보고 최종 사용자를 환경에 배치하기 전에 실제로 문제를 찾을 수 있습니다. 그게 당신이 전에 보았던 사람들의 유스 케이스입니까, 아니면 사람들도 그렇게하고 있습니까?

Bill Ellis : 당연히 애플리케이션 개발 수명주기 나 업그레이드 수명주기 동안 Precise를 사용하고 싶을 것입니다. Precise는 확장 성보기를 제공하며 응답 시간과 겹쳐진 실행 횟수를 보여줍니다. 분명히, 실행 횟수와 응답 시간이 함께 커지면 확장 할 수 없으며 무언가를해야합니다. 이런 종류의 일이 엄청나게 도움이되었습니다. 지금은 좀 덜 사실이라고 생각하지만, 사람들이 VMware에 프로덕션 애플리케이션을 배치하기 시작했을 때 약간 주저했고 처음에는 다음과 같이 생각했습니다. 우리가 실제로 할 수있는 것은 리소스 소비가 무엇인지 보여 주므로 애플리케이션을보다 효율적으로 만들 수 있습니다. 응용 프로그램 수명주기의 모든 단계에서 정확하게 Precise를 사용하려고합니다. 그러나 프로덕션은 실제로 성능이 가장 중요한 부분이며 Precise는 연중 무휴 프로덕션 모니터링을 목표로하고 있으므로 가시성없이 프로덕션 애플리케이션을 실행하고 싶지는 않습니다.

Dez Blanchfield : 물론입니다. 깊이 테스트, 이민, UAT 등 그 사양에 대한 또 다른 빠른 질문-이 도구를 사용하는 것이 좋으며 앱 개발자가 개발 수명주기의 라이프 사이클을 통해 이에 액세스하는 것을 절대적으로 좋아한다고 상상합니다. . 현재보다 복잡한 아키텍처를 통해 전용 서비스에서 가상화 및 가상화로 전환했으며, 이제는 아웃소싱을 클라우드 호스팅으로 채택하고 전환하는 과정으로 전환하고 있습니다. 컨테이너화. 많은 사람들이 이것을 배포하고 일종의 지역이나 영역을 모델링하는 것을 보았으므로 누군가가 가질 수 있습니다. 호주에서는 개인 정보 보호에 대해 매우 큰 문제가 있으며 유럽에서도 같은 문제이며 더 많은 사건이되고 있다고 생각합니다 미국에서 저를 개인적으로 식별 할 수있는 데이터는 종종 실제 응용 프로그램 계층에서 웹 계층에 대해보다 안전한 환경에 있어야합니다. 따라서 우리는 사람들이 데이터베이스와 애플리케이션을 내부적으로 유지할 수있는 이러한 배치를 보유하고 있지만, Azure 나 Amazon Web Services 및 소프트웨어와 같은 클라우드 제공 업체에 웹 계층과 제공 종료 및 애플리케이션 등을 넣을 수 있습니다. . 일반 배포에서 어떻게 작동합니까? 이 지역에 다른 수집가 집합이 있고 더 많은 집합을 수집 한 경우입니까? Precise 세계에서 오래된 레거시 제품의 IT를 한 곳에서 실행하고 귀사의 상품이 클라우드에있는 경우에 대한 오늘날의 일종의 바이 모달 방식에서는 어떤 모습입니까?

Bill Ellis : 예, 혼합 환경을 지원합니다. 고려해야 할 한 가지는 클라우드 공급자와 다른 계약이 있다는 것입니다. 그들 중 일부는 클라우드 내에서 어떤 종류의 에이전트 나 외부 모니터링도 허용하지 않습니다. Precise를 사용하여 설치 및 모니터링하려면 해당 유형의 액세스를 허용하는 계약 유형이 있어야합니다. 때로는 우리가 해결해야 할 몇 가지 제한 사항이 있으므로 이러한 계약은 계약에 서명 한 다음 및 / 또는 Precise를 배포해야하는 경우 고려해야 할 중요한 종류의 기준입니다.

Dez Blanchfield : 예 . 기존 데이터베이스 환경에서도 서비스의 일부로, 특히 Azure와 같은 서비스를 제공하는 경우에도 HDInsight 또는 SQL과 같은 것을 조달하면서 여러 인스턴스를 보았습니다. 서비스로서, 플랫폼으로서, 일반적인 도구는 실제로 깊숙이 빠져 나가는 것을보고 싶어하지 않기 때문에 너무 깊게 잠수 할 수 있습니다. 그래서 당신은 당신이 감시 할 수있는 특정 수준이나 깊이로 끝나고 갑자기 마법 커튼 뒤에서 볼 수 없습니다. 셀프 서비스가 문제입니까? 이것은 전통적으로 기술 팀, CIO 직원이 액세스 할 수있는 네트워크 운영 센터 내에서 실행되는 것입니까, 아니면 최종 사용자에게 수준의 액세스를 제공 할 수있는 것입니까? 리셉션 데스크와 전통적인 HR 및 재무 담당자 일 필요는 없지만 데이터 과학자, 보험 계리사, 통계 학자, 실제로 많은 작업을 수행하는 사람들과 같이 더 정통한 사용자는 알고 있습니다. 이러한 무거운 쿼리를 실행할 때 발생하는 상황과 문제가 발생하는 위치를 확인하기 위해 일종의 셀프 서비스 액세스에 액세스 할 수있는 경우가 있습니까? 따라서 워크로드 실행 방식을 조정할 수 있습니까?

Bill Ellis : Precise에는 보안이 매우 뛰어나므로 액세스 수준이 다른 사용자를 설정할 수 있습니다. 매우 기본적인 수준에서는 대시 보드 만 감독을 제공합니다. 그리고 누군가가 전문가 GUI에 들어가기를 원한다면 그들이 볼 수있는 것과 그들이 할 수있는 것을 제한 할 수 있습니다. 그리고 건강 관리에서 모든 HIPAA 법규를 가지고 있으므로 확실히 고려해야 할 사항이 있으며 실제로 두 가지 환경에서 모두 사용할 수 있도록 몇 가지 배포 옵션이 있다는 이전 질문으로 돌아갑니다. 이 프레젠테이션에서 보았던 데이터로 고려해야 할 사항은 테이블의 내용이 아니라 성능에 관한 모든 메타 데이터이며, 실제로는 이러한 유형의 데이터에 들어 가지 않을 것입니다. 개인 정보 보호 문제.

Dez Blanchfield : 응, 그랬어. 화면 스냅의 네 번째 또는 다섯 번째 슬라이드에 대해 유레카 순간을 보냈으며 성능 데이터를 끌어내는 것뿐만 아니라 성능 데이터를 끌어내는 것, 메타 데이터에서 메타 데이터에서 스택의 다양한 수준에서 실제로 내용을보고있는 것은 아닙니다. 그리고 이것은 흥미로운 일이라고 생각합니다. 단기적으로 배포하고 환경에서 일어나는 일을 볼 수 있지만 데이터 자체에 액세스 할 필요는없는 도구 중 하나이기 때문입니다. 승무원이 달리는 모습을 볼 수도 있습니다. 마지막으로, 나는 신속하게 추측하고 에릭에게 손을 돌려서 질문이 있으시면 레베카를 마무리 시키십시오. 오버 헤드가 공칭이라고 전에 언급 한 경우입니다. 사물의 모니터링 측면에서 눈에 띄는 오버 헤드조차도 배경을보고 있거나 고려할 가치가없는 무시할만한 양의 오버 헤드입니까?

Bill Ellis : 예, 데이터베이스 계층에 대해 생각합니다. 각 기술은 약간 다릅니다. 데이터베이스 계층에서 Precise는 가장 낮은 오버 헤드를이기는 것으로 잘 알려져 있습니다. 중간 계층에는 일종의 밸런싱 행위가 있으며, 그것은 단지 정확한 것이 아니라 가시성과 오버 헤드 측면에서 모든 사람에게 적용됩니다. 그리고 그 중 하나는 오버 헤드가 무엇인지 제어 할 수있는 여러 가지 정교한 도구를 제공한다는 것입니다. 우리는 생산을 위해 설계되었으며 개발 및 QA에 대한 문제에서 많은 문제를 해결하는 것이 확실히 유용하지만 생산에서 무슨 일이 일어나고 있는지 아는 것 외에는 아무것도 없습니다.

데즈 블랑 필드 : 에릭, 마지막 질문이 있습니까?

에릭 카바나 흐 : 네, 저는 여러분이 그 맥락이 정말로 핵심이라는 점을 지적하는 훌륭한 일을했다고 생각합니다. 그리고 사물 인터넷의이 시대로 나아가면 모든 것이 계측되기를 원합니다. 그리고 현재 제조업의 표준은 그렇게하는 것입니다. 좋은 소식입니다. 맞습니까? 서로 다른 모든 환경에서 정보를 가져 와서 모두 함께 연결할 수 있기를 원하기 때문입니다. 하지만 후속 의견을 위해 당신에게 넘겨 줄 것입니다. IT 분석가 인 일부 분석가는이 복잡한 환경에서 발생하는 상황을 모니터링하고 분석 한 다음 변경해야 할 사항을 파악할 수있는 시각적 인터페이스를 제공하는 데 중점을두고 있습니다. 도구가 아니기 때문입니다. 도구가 있어야하지만 세부 사항을 파고 답을 찾는 사람이 필요합니까?

빌 엘리스 : 예, 나는 그것이 정상까지 올라가고 가장 많은 환매가 어디에 우선 순위를 둔다고 생각합니까? 모든 문제가 데이터베이스에있는 것은 아니기 때문에 다른 상황입니다. 데이터베이스가 10 분의 1 초 안에 실행되고 있지만 애플리케이션 티어에서 3 초가 걸리는 경우가 가장 많은 환매입니다. 그리고 문제 계층을 분리 한 다음 계층 내에서 일어나는 일을 실제로 환매 지점에 집중할 수 있습니다. 그것은 실제로 응용 프로그램의 해상도와 최적화를 가속화하고 사람들이 회의실에 모인 것보다 훨씬 더 빠르고 훨씬 더 즐겁습니다.“저는 그렇지 않습니다.

에릭 카바나 흐 : 그렇습니다 . 나는 다른 날에“단지 의견이 아니라 정보를 얻으십시오.”와 같은 말을 들었습니다. 회의에 들어가서 정보를 얻었습니다. 데이터를 가리킬 수 있습니다. 그것이 핵심이며 우리는 그곳에 도착합니다. 자, 우리는 계속해서 마무리 할 것이지만 나중에 볼 수 있도록 모든 웹 캐스트를 보관합니다. 언제든지 확인하십시오. Techopedia.com의 모든 Hotcast 시리즈 및 브리핑 룸 시리즈를 웹 캐스트에 모두 나열하여 온라인으로 이동하여 해당 사용자를 확인하십시오. 그것으로 우리는 작별 인사를 할 것입니다. 시간 내 주셔서 감사합니다, 빌 당신과 모든 노고에 감사합니다, Dez. 그리고 우리는 다음에 당신에게 이야기 할 것입니다. 조심해 안녕.