응용 프로그램 가속화 : 최종 사용자를위한 더 빠른 성능

작성자 : Techopedia Staff, 2016 년 11 월 2 일

테이크 아웃 : 호스트 Eric Kavanagh가 Dr. Robin Bloor, Dez Blanchfield 및 IDERA의 Bill Ellis와 함께 애플리케이션 성능과 효율성을 개선하는 방법에 대해 설명합니다.

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

Eric Kavanagh : 신사 숙녀 여러분 안녕하세요, Hot Technologies에 다시 오신 것을 환영합니다. 네 확실합니다! 제 이름은 Eric Kavanagh입니다. 오늘 브리핑 룸 시리즈를 칭찬 한이 재미 있고 흥미 진진한 시리즈에서 다른 웹 캐스트의 호스트가 되겠습니다. 제목은“응용 프로그램 가속화 : 최종 사용자를위한 더 빠른 성능”입니다. 누가 원하지 않습니까? 내가 응용 프로그램을 더 빨리 실행하도록 도와주는 사람이라면 퇴근 후 바에서 맥주를 ​​사주는 사람이라고 생각합니다. 들어가서 다른 사람의 응용 프로그램 속도를 높이는 것은 매우 멋진 일입니다.

당신의 진실에 대한 슬라이드가 있습니다. Twitter @Eric_Kavanagh에서 저를 치십시오. 나는 항상 뒤를 따라 가려고 노력하며, 당신이 나를 언급하면 ​​항상 리트 윗합니다.

이 쇼의 전체 목적은 엔터프라이즈 기술의 다양한 측면에 초점을 맞추고 원하는 경우 특정 분야 또는 특정 얼굴을 정의하는 데 실제로 도움이됩니다. 벤더는 특정 마케팅 용어를 선택하여 어떻게 이러한 일이나 다른 일을하는지 이야기 할 것입니다. 이 쇼는 실제로 청중이 소프트웨어 분야의 리더가되기 위해 필요한 소프트웨어 도구를 이해하도록 돕기 위해 고안되었습니다. 이 형식은 두 명의 분석가입니다. 벤더가 먼저가는 브리핑 실과 달리 각각이 먼저 진행됩니다. 각각은 특정 종류의 기술에 대해 알기 위해 중요하다고 생각하는 것을 취합니다.

오늘 우리는 애플리케이션 가속화에 대해 이야기하고 있습니다. 우리는 Dez Blanchfield와 Dr. Robin Bloor (오늘날 전세계에 있음)의 의견을 듣고 Bill Ellis는 버지니아 지역에서 전화를 겁니다. 이를 통해 첫 발표자 인 Dr. Bloor에게 전달할 것입니다. 우리는 #podcast의 해시 태그를 트윗 했으므로 자유롭게 트윗하십시오. 멀리 가져.

로빈 블로어 박사 : 좋습니다. 소개해 주셔서 감사합니다. 응용 프로그램 성능 및 서비스 수준 – 이것은 일종의 영역입니다. 실제로 수년간이 영역에서 많은 작업을 수행했습니다. 실제로 성능을 모니터링하고 하나에서 작업하는 데 많은 작업을 수행했습니다. 방법 또는 다른 방법, 그 수준을 시도하고 계산하는 방법. 우리는 사람들이 사일로에 시스템을 구축했던이 시대를 가졌었다. 기본적으로 시스템이 사일로에있는 경우 시스템 성능을 합리적으로 향상시키기 위해 실제로 수행해야하는 작업의 양은 고려해야 할 매우 적은 양의 변수가 있기 때문에 실제로 너무 어렵지 않았습니다. 우리가 제대로 네트워크를 구축하자마자 대화식 서비스 지향이 등장했습니다. 조금 어려워졌습니다. 성능은 1 차원 일 수 있습니다. 특정 코드 경로를 반복적으로 실행하는 응용 프로그램을 생각하면 합리적으로 적시에 수행하면 1 차원적인 것처럼 느껴집니다. 서비스 수준에 대해 이야기를 시작하자마자 실제로 컴퓨터 리소스와 경쟁하는 여러 가지에 대해 이야기하고 있습니다. 매우 빠르게 다차원이됩니다. 비즈니스 프로세스에 대해 이야기하기 시작하면 여러 프로세스에서 비즈니스 프로세스를 함께 스레드 할 수 있습니다. 서비스 지향 아키텍처에 대해 이야기한다면 주어진 응용 프로그램이 실제로 여러 응용 프로그램의 기능에 액세스 할 수 있습니다. 그러면 매우 복잡한 일이됩니다.

저는 오래 전에이 다이어그램을 그렸습니다. 이 다이어그램은 20 세 이상입니다. 기본적으로 IT 환경에 존재하는 모든 것을 볼 수있는 방법이므로 Diagram of Everything이라고합니다. 실제로 사용자, 데이터, 소프트웨어 및 하드웨어의 네 가지 부분입니다. 물론 시간이 지남에 따라 바뀌지 만 실제로는 이러한 각 부분이 계층 적으로 폭발한다는 것을 알 때 알 수 있습니다. 하드웨어는 그렇습니다. 하드웨어는 서버가 될 수 있지만 서버는 여러 개의 CPU, 네트워킹 기술 및 메모리로 구성 될 수 있습니다. 실제로 이걸 보면 모두 조각으로 나뉩니다. 하드웨어 변경 등으로 인해 변경되는 데이터, 소프트웨어의 성능 변경 등과 관련하여 실제로 모든 것을 조정하려는 경우 실제로는 매우 어려운 다변량 상황을보고 있습니다. 이것이 복잡성 곡선입니다. 물론 그것은 거의 모든 것에 대한 복잡성 곡선이지만 컴퓨터에 대해 이야기 할 때마다 반복되는 것을 보았습니다. 기본적으로 한 축에 노드를 배치하고 다른 축에 중요한 연결을 설정하면 복잡성 곡선이 생깁니다. 노드와 연결이 무엇인지는 거의 중요하지 않으며 전화 네트워크의 볼륨 증가를 나타내려면 그렇게 할 것입니다.

실제로 컴퓨터 환경에서 노드에 대해 이야기 할 때는 서로를 관심을 갖는 개별적인 것에 대해 이야기하고 있습니다. 복잡성, 그것은 다양한 구조와 당신이 순종하려는 다양한 제약의 문제로 밝혀졌습니다. 또한 숫자. 숫자가 올라가면 미쳐 버립니다. 어제 흥미로운 대화를 나 someone습니다. 누군가와 이야기하고있었습니다. 그가 누구인지 언급 할 수는 없지만 실제로는 중요하지 않습니다. 그들은 4 만, 4 만, 4 개의 데이터베이스 인스턴스에 대해 이야기하고있었습니다. 사이트에서. 40, 000 개의 서로 다른 데이터베이스를 생각해보십시오. 물론 우리가 가진 유일한 것은 분명히 수많은 응용 프로그램을 가지고있었습니다. 우리는 매우 큰 조직에 대해 이야기하고 있지만 이름을 지을 수는 없습니다. 당신은 실제로 그것을보고, 실제로 어떤 방식 으로든, 여러 다른 사용자들이 원하는 여러 기대에 따라 전반적으로 적절한 서비스 수준을 얻으려고 노력하고 있습니다. 그것은 복잡한 상황이며, 제가 말하고자하는 것은이 것들이 복잡하다는 것입니다. 숫자는 항상 증가합니다. 제약 조건은 비즈니스 프로세스 및 비즈니스 목표에 따라 결정됩니다. 기대치 변화에 주목할 것입니다.

Gmail, Yahoo 메일 및 Hotmail과 같은 모든 메일 시스템이 등장하자 사람들은 조직 내부의 내부 메일 시스템에 대한 기대를 가지기 시작했습니다. 조직은 그런 모든 일이 일어나도록 압력을 가하기 시작했습니다. 실제로 서비스 수준 계약은 한 가지이지만 기대는 또 다른 것이며 조직 내에서 서로 싸우는 것은 어색합니다. 여기에 비즈니스 관점이 있습니다. 일부 시스템에서 최적의 응답 시간은 1 초의 인간 응답 시간의 1/10입니다. 1/10 분의 1은 코브라가 당신을 물 때까지 걸리는 시간입니다. 코브라 앞에 서서 당신을 물기로 결정하면 너무 늦습니다 .1 / 10 초 안에 응답 할 수 없기 때문입니다. 1/10 분의 1은 공이 투수의 손에서 방망이로 남자에게 도달하는 데 걸리는 시간에 관한 것입니다. 기본적으로, 그는 공이 던져지는 것을보고 정확히 그 시점에 반응해야합니다. 인간의 반응, 흥미로운 것. 소프트웨어 대 소프트웨어는 분명히 더 높은 기대치를 가질 수 있습니다.

그런 다음 시장 상황이라고 생각되는 상황에 처할 수 있습니다. 비즈니스 가치가 가장 먼저있는 곳입니다. 예를 들어 주식 시장에서 특정 주식을 팔고 싶을 때와 비슷할 것입니다. 예를 들어, 하락할 것이라고 생각하고 다른 사람들이 하락할 것이라고 생각하기 때문에 시장에 먼저 도착하면 최고의 가격을 얻을 수 있습니다. 많은 상황, 광고 게재 및 이와 유사한 상황이 있습니다. 매우 유사한 상황입니다. 서비스 수준 기대 측면에서 이러한 움직임이 있습니다. 인간의 반응을위한 유리 천장과 같은 것이 있습니다. 소프트웨어 대 소프트웨어가되면이 상한 상황이 발생하면 최상의 서비스 수준이 없습니다. 다른 사람보다 빨리 최고입니다.

좋아, 이것은 내가 생각한 마지막 슬라이드이지만, 일단 조직의 요구 사항, 서비스를 실제로 본다면 복잡성에 대한 큰 그림을 제공하는 것입니다. 여기 왼쪽으로 올라가면 서비스 관리를 위해 서비스 수준을 관리하려고하는 일련의 소프트웨어 인 시스템 관리가 있습니다. 그 위에는 비즈니스 성과 관리가 있습니다. 서비스 관리 자동화 영역의 하단을 살펴보면 표준화 된 서비스로 진화하는 단편화 된 서비스를 얻게됩니다. 실제로 이런 종류의 것에 투자하고 통합 서비스로 진화하여 최적화 된 서비스로 진화하는 경우 . 대부분 사람들이 한 일은 왼쪽 하단에만 있습니다. 약간의 서비스 관리가있을 수 있습니다. 비즈니스 성과 관리는 매우 드 rare니다. 거의 모든 부분이 조각났습니다. 완벽한 세상이 그 그리드를 채울 것입니다. 계측 – 하위 최적화 문제에 대해 언급했습니다. 시스템의 일부를 최적화 할 수 있으며 전체 시스템에 좋지 않습니다. 심장을 최적으로 만들면 혈액이 장기의 나머지 부분에 비해 너무 빨리 순환 될 수 있습니다. 이는 대규모 조직 및 서비스 수준의 문제입니다. 변수가 막 나왔기 때문에 정교한 도구 없이는 아무 것도 달성 할 수 없습니다. 시도하고 최적화 할 변수가 너무 많습니다.

그렇게 말하면서, 나는 다른 것에 대해 완전히, 희망적으로 이야기 할 Dez에게 넘어갈 것입니다.

Dez Blanchfield : 감사합니다, Robin. Dr. Robin Bloor와 마찬가지로, 매우 복잡한 시스템의 성능을 매우 큰 규모로 생각하는 데 너무 오랜 세월을 보냈습니다. 아마도 로빈과 같은 규모는 아니지만 성능은 일상적인 주제이며 성능을 원하는 것은 DNA의 일부이며 모든 것을 최대한 활용하십시오. 사실, 나는 전 세계에서 내가 좋아하는 것 중 하나 인 그래픽 I 자동차 경주를 사용하여 지구 전체가 잠시 동안 앉아 있고 자동차가 매우 빠르게 원형으로 움직이는 것을 보았습니다. 모든 단일 측면에서 성능을 얻는 것과 관련이없는 공식 I의 측면은 없습니다. 많은 사람들이 돈을 낭비한다고 생각하기 때문에 스포츠를 똥똥으로 나눕니다. 우리가 매일 주말과 학교에서 축구에 아이들을 떨어 뜨리기 위해 매일 운전하는 자동차가 성능 기반 개발 및 연구에서 파생 된 것으로 나타났습니다. 그것은 포뮬러 I 자동차 경주의 삶의 종류입니다. 일상 기술, 일상 과학은 종종 고성능에만 중점을 둔 것에서 비롯됩니다.

그러나 현실은 로빈이 앞서 언급 한 것처럼 100 % 가동 시간을 요구하는 새로운 "항상 켜져있는"세계에서 지속적인 공간에서 당연한 웹 메일 및 기타 서비스의 도입과 같은 것들을 기대하고 있습니다. 우리의 기업과 업무 환경. 현실은 항상 서비스 수준 계약을 충족한다는 의미는 아닙니다. 지난 10 년 동안 애플리케이션 성능 및 가용성 서비스 수준 계약을 관리해야 할 필요성이 대두되었습니다. 우리는 더 이상 한 시스템의 성능에 대해 걱정하지 않습니다. 세계가 조금 더 단순 해지면 여러 서비스를 실행하는 단일 서버를 실시간으로 모니터링 할 수 있고 지원하기가 비교적 쉬운 상황이있을 수 있습니다. 우리는 몇 년 전에 예를 들어 제가 시스템 관리자였던 것에 대해 걱정했던 것들을 볼 수있었습니다. 일반적으로 서비스는 정상적으로 작동하고 있습니까? 예를 들어 터미널에 로그인 할 수 있습니까? 운영 체제가 응답하고 명령을 입력 할 수 있습니까? 응용 프로그램이 시작되어 실행 중입니까? 네트워크 등에서 작업 및 I / O를 수행 할 때 프로세스와 메모리를 볼 수 있습니까? 메인 프레임 시대에는 테이프가 지퍼로 들어가고 종이가 빠지는 것을들을 수있었습니다.

앱이 응답하고 있으며 로그인하여 작업을 수행 할 수 있습니까? 사용자가 해당 서버 중 일부에 연결할 수 있습니까? 계속됩니다. 그것들은 상당히 기본적입니다. 그렇다면 재미있는 몇 가지 – 헬프 데스크는 녹색입니까? 그렇지 않다면 모든 것이 잘 돌아가고 누가 도넛을 얻을 수 있습니까? 그 당시 인생은 정말 단순했습니다. 그 당시에도 20 ~ 30 년 전에 이야기했지만 복잡성은 여전히 ​​높았습니다. 비교적 간단한 방식으로 서비스 수준 계약을 관리하고 성능을 주시 할 수 있습니다. 로빈이 언급했듯이 더 이상 손으로 할 수 없습니다. 도전은 너무 큽니다. 사실 몇 가지 훌륭한 앱, 관리자, 시스템 네트워크 및 데이터베이스가 관리자가 성능 SLA를 모니터링하고 충족시킬 수있는 시간입니다. SLA는 이제 너무 어려워서 지난 밤에 매우 복잡한 스택의 시스템을보고 그것을 이해하고 이해하고 심지어 무엇을 이해했는지에 대한 마지막 노트를 작성했을 때 어려움을 겪었습니다. 후드 아래에서 진행하고 있으며, 나는 매우 기술적 인 배경에서 왔습니다. 나는 오늘날 행정적인 방식으로 매일 직면하는 것이 어떤 것인지 상상할 수 없습니다.

어떻게 된 거예요? 1996 년에 데이터베이스 중심 앱이 인터넷 붐으로 변모했습니다. 우리 중 많은 사람들이 그것을 겪었습니다. 인터넷 붐이 아니더라도 일상 생활에서 모든 것을 인터넷에 연결한다는 것을 쉽게 둘러보고 알 수 있습니다. 토스터가 인터넷에 연결되어 있지 않아도 우스꽝스러운 Wi-Fi 옵션이 제공되는 토스터가 있다고 생각합니다. 2000 년대 초반, 특히 2000 년대 초반, 우리는 닷컴 컴 붐에서 서비스 성능을 제공하는 복잡한 라운드의 엄청난 성장을 처리해야했습니다. 그런 다음 웹 2.0에서 또 다른 어색한 불꽃이 발생했습니다. 웹 2.0에서는 스마트 폰이 등장했으며 이제는 응용 프로그램이 24/7 상태에 있으며 항상 켜져 있습니다.

2016 년 현재 클라우드와 빅 데이터 및 이동성 형태의 또 다른 문제에 직면하고 있습니다. 이것들은 너무 커서 시스템을 이해하고 이해하기 어려운 시스템입니다. 우리가 이야기하는 큰 유니콘 중 일부는 수백 페타 바이트의 데이터를 가지고 있다는 사실을 생각할 때. 이메일, 이미지 및 소셜 미디어를 보관할 수있는 디스크 공간과 저장 공간의 전체 층입니다. 또는 경우에 따라 운송 및 해운 물류 분야에서는 모두 은행 업무, 돈이있는 곳, 우편이있는 곳 또는 eBay에서 구매 한 물건이있는 곳 등이 있습니다. 우리가 직면하게 될 다음 큰 물결은 사물 인터넷에 대한이 매우 어려운 도전입니다.

이것이 나쁘지 않은 경우, 인공 지능과인지 컴퓨팅을 거의 모든 것에 구축하려고합니다. 요즘 시리와 구글 엔진과 대화를 나눈다. 나는 아마존 자체의 것을 알고 있습니다. Baidu는 이러한 장치 중 하나를 사용하여 일반 시스템으로 들어가는 텍스트로 변환하고 데이터베이스가 쿼리를 수행하여 프로세스를 되돌립니다. 그 복잡성에 대해 생각하십시오. 오늘날의 표준 응용 프로그램 스택의 복잡성은 인간의 능력을 훨씬 뛰어 넘습니다. 스마트 폰 장치 또는 태블릿의 버튼을 누를 때 발생하는 모든 일에 대해 생각할 때, 말을하고, 텍스트로 변환하고, 인터넷에서 백엔드 시스템으로 연결하여 프런트 엔드를 수신합니다. 즉, 쿼리로 변환하고, 애플리케이션 스택을 통해 쿼리를 실행하고, 데이터베이스를 통과하고, 디스크를 치고, 다시 나오고, 중간에 캐리어 네트워크가 있고 LAN (Local Area Network) 상태 센터가 있습니다. 복잡함은 미쳤다.

이를 하이퍼 스케일로 효과적으로 주장합니다. 하이퍼 스케일의 복잡성과 속도는 눈에 물을주는 것입니다. 응용 프로그램과 데이터베이스가 너무 커지고 복잡 해져서 성능 관리는 실제로 과학 그 자체입니다. 많은 사람들이 그것을 로켓 과학이라고 부릅니다. 우리는 온 사이트 기술, 오프 사이트 기술, 다양한 데이터 센터 옵션을 보유하고 있습니다. 물리적 및 가상. 우리는 물리적 서버와 가상 서버, 클라우드, 서비스와 인프라를 서비스로, 서비스와 소프트웨어를 서비스로 제공하는 것은 당연한 일입니다. 후자는 서비스 소프트웨어로서 몇 년 전 CFO와 조직의 일부가 신용 카드를 수령하고 물건을 사서 CIO를 돌아 다닐 수 있다는 것을 깨달았을 때 무서워졌습니다. IT”와 CIO는 이제이 문제를 해결하고 통제력을 회복하려고합니다.

인프라 스트럭처에는 소프트웨어 정의 네트워킹, 네트워크 기능 가상화가 있으며, 그 아래에는 아마도 마이크로 서비스와 활성 서비스 앱이 있습니다. URL을 클릭하면 해당 URL의 끝에 실제로 전달하는 데 필요한 것을 설명하는 비즈니스 로직이 있습니다. 반드시 사전 빌드 된 논리를 기다릴 필요는 없습니다. 한쪽에 아주 큰 규모로 확장되는 기존 데이터베이스가 있습니다. 우리는 다른 스펙트럼에서 하둡 인프라 스트럭처와 생태계를 좋아합니다. 사람들이 지금 말했듯이 사람들은 수백 페타 바이트의 데이터에 대해 이야기하고 있습니다. 우리는 이동 장치, 랩톱 및 전화 및 태블릿을 운반하는 한 복잡한 이동성을 가지고 있습니다.

Y 세대는 경험이 많은 사람들이 자신의 기기를 가져오고 있기 때문에 일부 밀폐 된 환경에서 BYOD를 얻었으며 점점 더 커지고 있습니다. 우리는 그들에게 웹 인터페이스에 대해 이야기하게했습니다. 인터넷이나 Wi-Fi를 통해 아래층 카페에서 커피를 마시면서 무료 Wi-Fi를 이용할 수 있습니다. 또는 내부 Wi-Fi. 기계 대 기계는 이제 항상 존재합니다. 그것은 사물 인터넷의 일부가 아니라 관련이 있습니다. 사물 인터넷은 복잡하게 떠오르는 완전히 새로운 게임입니다. 인공 지능, 지금 우리가 놀고있는 모든 Siri 및 기타 관련 장치가 복잡하다고 생각되면 3D 인 Olli라는 것이 보일 때까지 기다리십시오. 약 6 명을 수용하고 도시를 돌아 다니며 인쇄 할 수있는 버스는 일반 영어를 구사할 수 있습니다. 교통 체증이 발생하면 교통량이있는 주요 지역에서 좌 / 우로 회전하기로 결정합니다. 방향이 바뀌면서 왜 도로에서 좌회전 또는 우회전을했는지 걱정이되자“걱정하지 마십시오. 좌회전을하려고합니다. 앞으로 나아갈 교통이 있고 나는 갈 것입니다.”

거기에있는 모든 시스템의 성능과 모든 복잡성을 관리하고, 데이터가 어디로 가는지 추적하고, 데이터가 데이터베이스로 이동하는지, 모든 인터커넥트 및 모든 관련 비트를 추적해야합니다. 실제로 오늘날의 속도와 규모로 성능과 SLA를 관리하려면 도구와 시스템이 필요하지만 기본적으로 더 이상 도구가 있으면 좋을 것이라고 생각하는 곳이 아닙니다. 이는 전제 조건입니다. 절대적으로 필요합니다. 다음은 간단한 예입니다. 오픈 소스 소프트웨어 정의 클라우드 인 OpenStack에 대한 고급 애플리케이션 설계 다이어그램 목록입니다. 이것은 단지 큰 덩어리입니다. 이것은 단지 서버와 데이터베이스가 아닙니다. 여기에서 각각의 작은 파란색 얼룩이 사물의 클러스터를 나타냅니다. 어떤 경우에는 파일과 서버 또는 수백 개의 데이터베이스 또는 물론 수만 개의 작은 응용 프로그램 논리가 실행됩니다. 작은 버전입니다. 이것에서 발생하는 복잡성에 대해 생각하기 시작할 때 정말 마음이 흔들립니다. 오늘날에는 빅 데이터 공간에서도 브랜드의 스크린 샷 만 추가하겠습니다. 우리가 여기서 관리해야 할 모든 부분에 대해 생각할 때 반드시 하나의 브랜드에 대해서만 이야기하는 것이 아니라, 모든 작은 작은 하나 또는 오픈 소스뿐만 아니라 빅 데이터 환경과 최상위 브랜드의 모든 브랜드입니다. 당신은보고 당신이 생각이 매우 놀라운 차트라고 생각합니다.

몇 가지 카테고리 만 살펴 보겠습니다. 예를 들어 마케팅을하자. 다음은 비슷한 차트이지만 마케팅 기술에서만 사용할 수있는 기술 스택입니다. 2011 년 그래프입니다. 2016 년판입니다. 생각하십시오. 이것은 마케팅 기술과 관련하여 기술을 위해 실행할 수있는 제품 브랜드의 수에 불과합니다. 내부의 시스템의 복잡성이 아니라 다른 앱 및 웹, 개발 및 네트워크 및 기타 시스템이 아닙니다. 그냥 브랜드. 5 년 전과 지금이 있고 오늘입니다. 더 나빠질 것입니다. 우리는 지금 현실이있는 지금, 인간은 단순히 모든 서비스 수준 계약을 보장 할 수 없습니다. 우리는 충분히 자세하고, 빠르며, 필요한 규모로 뛰어들 수 없습니다. 다음은 모니터링 콘솔의 모습에 대한 예입니다. 이것은 거의 스물 여덟 개의 스크린이 서로 붙어 붙어서 작은 조각 하나 하나를 감시하는 하나의 크고 큰 투영 된 스크린 인 것처럼 보입니다. 여기서 흥미로운 점은 브랜드에 대해서는 언급하지 않지만이 모니터링 플랫폼은 물류 및 배송 환경에서 단일 애플리케이션을 모니터링하는 것입니다. 하나의 앱입니다. Robin이 현재 프로덕션 환경에서 4 만 개의 데이터베이스를 보유 할 수있는 위치에 대해 이야기 한 것을 생각해보십시오. 하나의 응용 프로그램을 모니터링하는이 화면 모음의 4 만 버전을 시각화 할 수 있습니까? 우리가 살고있는 매우 용감한 세상입니다. 로빈이 말했듯이 절대 100 %는 적절한 도구가없고 도구를 사용하여 테이블에 대한 적절한 지원과 인력이 없으면 응용 프로그램 성능은 인간에게있어 손실 된 게임이며 도구와 소프트웨어로 수행해야합니다.

그것으로 나는 IDERA의 친구들에게 넘어갈 것입니다.

에릭 카바나 : 빌.

빌 엘리스 : 감사합니다. 내 화면을 여기에서 공유하십시오. 누군가 내 화면을 볼 수 있는지 확인할 수 있습니까?

로빈 블로어 박사 : 네.

에릭 카바나 흐 : 괜찮아 보입니다.

빌 엘리스 : 감사합니다. 그가 언급 한 한 가지는 정말 기다릴 수없는 자율 주행 차였습니다. 아무도 이야기하지 않은 한 가지는 눈이 올 때 어떻게됩니까? 캘리포니아의 엔지니어들이 다른 지역에서는 눈이 많이 내린다는 것을 깨달았습니다.

Dez Blanchfield : 저도 그 점을 기억하겠습니다.

에릭 카바나 흐 : 전형적인 시속 1 마일.

Bill Ellis : 복잡한 환경에서의 애플리케이션 성능 관리에 대해 이야기합니다. 제가 이야기하고 싶은 한 가지는 많은 사람들이 성능에 대해 이야기 할 때 반응의 본질, 더 많은 서버, 더 많은 CPU, 더 많은 메모리 등입니다. 그 동전의 다른 쪽은 처리 효율성입니다. 실제로, 그것은 같은 동전의 양면이며 우리는 두 가지를 살펴볼 것입니다. 궁극적 인 목표는 비즈니스 트랜잭션에 대한 서비스 수준 계약을 충족시키는 것입니다. 궁극적으로이 기술은 모두 비즈니스에 존재합니다. 업계 최초의 성능 관리 데이터베이스를 갖는 것에 대해 이야기했습니다. 이상적으로는 이상적인 성능에 맞추고 애플리케이션 수명주기 초기부터이를 관리하는 것입니다.

주제는 실제로 네 가지로 요약됩니다. 하나는 성능 관리 프로세스입니다. 우리는 모든 사람에게 이야기했고 모든 사람은 도구를 가지고 있습니다. 도구가 없으면 스크립트 나 명령이 있지만 빠진 것은 컨텍스트입니다. 컨텍스트는 단순히 애플리케이션 스택에서 점을 연결하는 것입니다. 이 응용 프로그램은 브라우저 기반입니다. 그들은 계층에서 계층으로 매우 밀접하게 연결되어 있습니다. 계층이 상호 작용하는 방법도 중요합니다. 그런 다음 비즈니스 트랜잭션에 대해 이야기하고 있습니다. 기술 담당자뿐만 아니라 응용 프로그램 소유자 및 운영 관리자에게도 가시성을 제공 할 것입니다.

고객이 사용하는 방법을 당신과 공유하기위한 몇 가지 사례 연구가 있습니다. 이것은 프레젠테이션에서 매우 실용적인 부분입니다. 일반적으로 어떤 일이 일어나는지 살펴 보자. 저는 다이어그램을 좋아합니다 – 그것은 놀라운 기술의 콜라주와 같았습니다. 데이터 센터의 기술 수가 방금 성장하고 성장하고 성장했습니다. 한편, 최종 사용자는 신경 쓰지 않으며 신경 쓰지 않습니다. 그들은 단지 거래를 실행하고, 이용 가능하고, 빠르게 완료되기를 원합니다. 일반적으로 IT 전문가는 최종 사용자가 자체보고 할 때까지 최종 사용자에게 문제가 있음을 인식하지 못합니다. 시간이 오래 걸리고 속도가 느리며 종종 실망스러운 결과를 낳습니다. 사람들은 도구를 열고 응용 프로그램 스택의 하위 집합을 살펴 봅니다. 이 하위 집합을 사용하면 가장 간단한 질문에 대답하기가 매우 어려워집니다. 문제가있는 것이 보통입니까? 어떤 거래입니까? 응용 프로그램 스택의 병목 현상은 어디에 있습니까? 이 질문에 답할 수없는이 모든 것을 계층별로보고이 질문에 대답 할 수 없게되면 많은 시간과 에너지, 많은 직원, 자금 및 에너지 종류를 알게됩니다.

이 문제를 해결하기 위해 더 나은 방법을 제공하기 위해 Precise가 실제로하는 일은 실제로 최종 사용자 추적 트랜잭션을 가져 와서 메타 데이터를 캡처하고 네트워크를 통해 트랜잭션을 따라 웹 서버에서 비즈니스 로직 계층으로 이동하는 것입니다. 우리는 .NET 및 ABAP, PeopleCode 및 E-Business Suite를 지원하며, 궁극적으로 모든 트랜잭션이 레코드 시스템과 상호 작용할 수있는 멀티 티어 애플리케이션입니다. 재고 조회이든, 보고 시간이든 상관없이 항상 데이터베이스와 상호 작용합니다. 데이터베이스는 비즈니스 성과의 기초가됩니다. 데이터베이스는 차례로 스토리지에 의존합니다. 트랜잭션에 대한 메타 데이터가 응답하는 대상, 누가, 어떤 트랜잭션, 애플리케이션 스택의 위치 및 실행중인 항목을 보여주는 심도있는 코드 수준 가시성이 있습니다. 이 정보는 지속적으로 캡처되어 성능 관리 데이터베이스에 저장되어 모든 사람이 진행중인 작업을 볼 수있는 단일 음악 시트가됩니다. 기술 전문가, 응용 프로그램 소유자, 궁극적으로는 비즈니스 자체와 같은 일을 처리하는 사람과 조직이 다릅니다. 문제가 발생하면 해당 거래에 대한 정보를 추출 할 수 있기를 원합니다.

투자 거래를 살펴보기 전에 조직의 다른 사람들에게 어떻게 보일 수 있는지 보여 드리고자합니다. 관리 계층에서는 여러 응용 프로그램에 대한 개요를 원할 수 있습니다. SLA 준수 및 가용성으로 계산 된 상태에 대해 알고 싶을 수 있습니다. 그 건강이 모든 것이 100 % 완벽하게 작동한다는 것을 의미하지는 않습니다. 이 경우 투자 거래가 경고 상태에 있음을 알 수있는 여지가 있습니다. 이제는 비즈니스 영역에서 조금 더 깊어지면 SLA, 트랜잭션 수 등을 위반할 때 개별 트랜잭션에 대한 추가 세부 정보를 원합니다. 운영 팀은 일부에 대한 경고를 통해 이에 대해 알림을 받고자합니다. 종류. 성능 알림 기능이 내장되어 있습니다. 실제로 최종 사용자의 브라우저에서 성능을 측정합니다. Internet Explorer, Chrome, Firefox 등 어떤 것이 든 감지 할 수 있습니다. 이는 첫 번째 질문에 대한 답변입니다. 최종 사용자에게 문제가 있습니까?

잠수하고 그것에 대해 우리가 무엇을 보여줄 수 있는지 봅시다. 성능에 관심이있는 사람들은 Precise를 열 것입니다. 그들은 거래를 평가할 것입니다. SLA를 준수하지 않은 트랜잭션을 식별하기 위해 SLA 열을 살펴 봅니다. 그들은 영향을받은 최종 사용자뿐만 아니라 해당 트랜잭션이 응용 프로그램을 통과하면서 수행 한 작업을 볼 수있었습니다. 이 상형 문자를 해독하는 방식은 브라우저, URL, U는 URL, JVM의 진입 점입니다. 이제이 특정 JVM은 웹 서버가 두 번째 JVM을 호출하여 SQL 문을 실행하도록합니다. 이 SQL 문이 응답 시간의 72 %를 담당했기 때문에 이것은 데이터베이스 문제입니다. 우리는 시간에 집중합니다. 시간은 성과의 통화입니다. 최종 사용자가 느리게 실행되는지 여부를 경험하는 방식이며 리소스 소비의 척도입니다. 매우 편리합니다. 성능을 평가하는 데 가장 중요한 일종의 단일 메트릭입니다. 이 문제가 DBA에 전달되면 이는 단순한 데이터베이스 문제가 아니라이 SQL 문입니다. 이것이 제가 이야기하고있는 맥락입니다.

이제이 정보로 무장하고, 무슨 일이 있었는지 분석 할 수 있습니다. 우선, y 축은 하루 종일 시간입니다. 실례합니다. y 축은 응답 시간이고 x 축은 하루 종일 시간입니다. 데이터베이스 문제가 있음을 알 수 있습니다. 두 가지 경우가 있습니다. 해당 흐름으로 돌아가서 SQL 문을 가져 와서 전문가보기로 이동하십시오. 정확한 상황에서 발생하는 상황, 제어, 코드 소요 시간을 보여줄 수 있습니다 실행하십시오. 데이터베이스 계층에서는 실행 계획입니다. Precise는 실행 시간에 사용 된 실제 실행 계획을 선택했습니다. 계획은 실행 시간이 아닌 계획이 제공된시기 인 예상 계획과는 다릅니다. 데이터베이스가 실제로 수행했음을 반영하거나 반영하지 않을 수 있습니다.

이제 아래에 SQL 문에 대한 응답 시간 분석이 있습니다. 스토리지에서 소비 한 시간의 90 %; CPU에는 10 %가 사용되었습니다. SQL 보고서의 텍스트와 결과 보고서를 볼 수 있습니다. SQL 문의 텍스트는 실제로 일부 코딩 문제점을 나타 내기 시작합니다. 별표입니다. 모든 행을 반환합니다-반환 된 행의 모든 ​​열을 실례합니다. 애플리케이션이 필요하거나 필요하지 않은 추가 열을 다시 사용하고 있습니다. 이러한 열은 처리하기 위해 공간과 리소스를 소비합니다. SAP를 실행하는 경우 HANA 데이터베이스가 기둥 형이기 때문에 큰 변화 중 하나는 기본적으로 선택 스타를 선택하지 않도록 SAP를 다시 작성하여 리소스 소비를 크게 줄일 수 있다는 것입니다. 이것은 기본적으로 Java, .NET 등 자체 개발 응용 프로그램에서도 많은 시간이 걸리는 것입니다.

이 화면에는 누가, 무엇을, 언제, 어디서, 왜 보여줍니다. 문제를 해결할 수있는 SQL 문 및 실행 계획과 같은 이유가 있습니다. Precise는 지속적으로 실행되기 때문에 실제로 SQL 문 수준, 트랜잭션 수준에서 전후로 측정 할 수 있으므로 응용 프로그램 소유자 및 관리를 통해 자신을 위해 측정하여 문제를 해결할 수 있습니다. . 그 문서는 정말 도움이됩니다. 이 애플리케이션 스택에는 많은 복잡성이 있습니다. 실제로 많은 애플리케이션 중에서 우리가 이야기 한 모든 사람이 VMware에서 애플리케이션 스택의 적어도 일부를 실행합니다. 이 경우 고객 서비스 응용 프로그램을보고 거래 시간을보고이를 가상화 이벤트의 둔화와 연관시킵니다. 정확한 모든 가상화 이벤트를 추적합니다. 이를 위해 vCenter에 플러그인이 있습니다.

또한 경합을 감지 할 수 있습니다. 경합은 활용도와 다릅니다. 실제로 고객 서버의 응용 프로그램과 관련하여 시끄러운 이웃이 게스트 VM에 영향을 미치는 경우를 보여줍니다. 이제 정보를 얻을 수 있고 실제로이 경우 CPU 리소스에 대해 경쟁하는 두 개의 VM을 볼 수 있습니다. 이를 통해 일정을 볼 수 있도록 가시성을 확보 할 수 있습니다. 게스트 VM을 다른 물리적 서버에 둘 수 있습니다. 응답 할 수있는 모든 유형의 항목뿐만 아니라 실제로 CPU 효율성을 높이기 위해 코드 효율성을 볼 수 있습니다. 나는 누군가가 어떻게 CPU 소비를 몇 배나 줄일 수 있는지에 대한이 프레젠테이션에서 꽤 좋은 예를 가지고 있다고 생각합니다.

VMware였습니다. 응용 프로그램 코드 인 코드 자체를 살펴 보겠습니다. Precise는 Java, .NET, ABAP 코드, E-Business, PeopleCode 등에서 발생하는 상황을 보여줄 수 있습니다.이 경우 WebLogic에 대한 진입 점입니다. 여기 아래에는 EJB가보고 있어야한다는 사실을 알려주는 결과 보고서가 있으며이 시스템에서도 잠금이 발생했음을 알려줍니다. 다시 한 번, 비즈니스 로직 계층 내에서 드릴 다운하여 진행 상황을 보여줍니다. 이 경우 특정 사례를보고 있습니다. 클러스터링도 지원합니다. 다수의 JVM이 실행중인 경우 클러스터를 전체적으로 보거나 개별 JVM 내에서 병목 현상을 볼 수 있습니다.

잠그면 예외가 발생할 수 있습니다. 예외는 성능 문제와 약간 다릅니다. 일반적으로 예외는 매우 빠르게 실행됩니다. 논리 오류가 있고 일단 해당 논리 오류에 부딪 치면 종료됩니다. 예외 상황에서 스택 추적을 캡처 할 수 있었으므로 진행 상황을 파악하는 데 많은 시간을 절약 할 수 있습니다. 스택 추적 만 있으면됩니다. 또한 메모리 누수도 캡처 할 수 있습니다. 이 솔루션에는 데이터베이스 계층도 포함되어 있습니다. 데이터베이스 인스턴스를 평가할 수 있습니다. 다시 한번, y 축은 시간이 소비 된 곳이고 x 축은 하루 종일 시간입니다. 시스템에서 발생하는 상황과 내가 볼 수있는 것을 자동으로 알려주는 결과 보고서가 있습니다.

Precise의 조사 결과 보고서 중 하나는 로그 또는 대기 상태 만 보는 것이 아니라 CPU를 포함한 모든 실행 상태를보고 스토리지에서 정보를 반환하는 것입니다. 스토리지는 애플리케이션 스택에서 매우 중요한 부분이며, 특히 솔리드 스테이트가 등장합니다. 해당 라인을 따라 정보를 얻는 것이 매우 도움이 될 수 있습니다. 특정 저장 장치의 경우 실제로 개별 장치 수준에서 발생하는 상황을 드릴 다운하고 표시 할 수 있습니다. 이러한 유형의 정보 – 다시 한 번, 깊은 가시성입니다. 그 범위는 광범위합니다. 응용 프로그램 성능 전문가로 끌어 올릴 수있는 충분한 정보를 제공하여 응용 프로그램을 엔드 투 엔드로 최적화하여 해당 비즈니스 트랜잭션을 충족시킬 수 있습니다.

귀하와 공유하고 싶은 몇 가지 사례 연구가 있습니다. 우리는 꽤 빨리 순항합니다. 나는 괜찮은 속도로 가고 있기를 바랍니다. 스토리지에 관해 이야기하면 시간이 지남에 따라 모두 하드웨어가 바뀝니다. 하드웨어 보증이 있습니다. 벤더가 말한 내용을 실제로 전달 했습니까? 이를 Precise로 평가할 수 있습니다. 들어 와서 여기서 일어난 일은 기본적으로 새로운 저장 장치에 넣었지만 저장 관리자가 저장 장치 수준을 살펴보면 많은 경합을 보았고이 새로운 저장 장치에 문제가 있다고 생각했습니다. . 엔드 투 엔드 관점에서 더 많은 것을 살펴보면 실제로 일어날 위치를 정확하게 보여줍니다. 실제로는 초당 약 400 메가의 처리량에서 비롯된 것으로 응답 시간의 38 %를 스토리지가 담당했기 때문에 상당히 높습니다. 새로운 스토리지 장치를 사용하면 실제로 처리량을 초당 6 백 7 백 메가로 늘렸으므로 기본적으로 두 배가되었으며 트랜잭션 시간에 대한 스토리지 계층의 기여도를 절반으로 줄일 수있었습니다. 실제로 실제로 그래프를 그릴 수 있습니다. 이것은 컷 오버 기간입니다.

다시 한번, 하드웨어 투자가 그만한 가치가 있음을 증명하기위한 문서가 특정 벤더가 기대 한대로 제공되었습니다. 복잡성, 개수, 발생 가능한 모든 종류가 있기 때문에 모든 것이 있습니다. 이 경우, 실제로 모든 사람들이 DBA를 비난하는 상황에 처해 있었으며 DBA는 "잘 빠르지는 않습니다."와 같습니다. 여기서 우리는 실제로 SAP 응용 프로그램을보고 있습니다. . 그들은 사용자를위한 맞춤형 거래를 개발하고있었습니다. 사용자는“이것이 너무 느립니다.”SAP의 프로그래밍 언어 인 ABAP 코더는“이것은 데이터베이스 문제”라고 말했습니다. 그들은 최종 사용자를 60 초 동안 1 분에 걸쳐 측정했습니다. 백엔드에서 53 초가 소비되었습니다. 백엔드로 뚫고 실제로 내림차순으로 표시되는 SQL 문을 표시 할 수있었습니다.

리소스 소비의 25 %를 담당하는이 최상위 SQL 문은 평균 실행 시간이 2 밀리 초입니다. 당신은 데이터베이스를 비난 할 수 없습니다. 아시다시피, 그렇게 빠르지는 않습니다. 문제는 왜 그렇게 많은 처형이 있는가하는 것입니다. 글쎄, 그들은 그것을 ABAP로 반송했고, 그는 들어갔고, 루프의 중첩을 조사했고, 그들이 잘못된 장소에서 데이터베이스를 호출하고 있음을 발견했으며, 기본적으로 변경을 수행하고 변경을 테스트했으며 이제 새로운 응답 시간은 다음과 같습니다. 5 초 조금 느리지 만 그것들과 함께 살 수 있습니다. 60 초보다 훨씬 낫습니다. 때때로, 단지 문제가되는 것은 응용 프로그램 코드입니까, 데이터베이스입니까, 저장 장치입니까? 이는 정확한 거래를 통해 정확한 위치에있는 정확한 위치입니다. 당신은 기본적으로 그런 것들을 끝냅니다.

나는 시간을보고 있는데, 우리는 여전히 몇 가지를 더 살펴볼 시간이 약간있는 것처럼 보입니다. 나는 이것을 통해 스트리밍하고 있습니다. 이 응용 프로그램은 1 년 이상 개발되었습니다. 고객이 QA에 들어갔을 때 웹 서버가 최대 100 %를 초과했으며 애플리케이션이 VMware에서 실행될 수없는 것처럼 보였습니다. 모든 사람들이 가장 먼저 말한 것은“이것은 육체에 두십시오. VMware에서는 실행할 수 없습니다.”정확한 정보를 통해 실제로 문제를 해결하는 추가 방법을 제공했습니다. 우리는 트랜잭션을 살펴보고 웹 서버 호출을 보았습니다. IIS.NET에서 ASMX로 제공됩니다. 실제로 기본 코드를 공개했습니다. 내가 가리키는 곳이 보입니까? 23 일 11 시간입니다. 와우, 어떻게 가능해? 각 호출은 9.4 초가 걸리며이 작업은 215, 000 회 호출됩니다. 모든 호출에 대해 6 초의 CPU를 사용합니다. 이것이 이유입니다.이 코드는이 일이 결코 확장 될 수없는 이유입니다. 실제로 물리적으로는 확장 할 수 없었습니다.

그들이 한 것은 개발자에게 돌아가서“누군가가 변화를 일으킬 수 있습니까?”라고 말한 것입니다. 그들은 일종의 경연 대회를 가졌으며 다른 제안을 테스트하고 많은 제안을 할 수있었습니다. 더 효율적으로. 새로운 1 초는 CPU에서 2 분의 1 초로 1 초만에 완료되었습니다. 이제는 확장이 가능하며 VMware 팜에서 실행될 수 있습니다. 기본적으로 코드 수준과 트랜잭션 수준에서 모두 문서화 할 수있었습니다. 이것은 일종의 전과 후입니다. 이제 웹, .NET 및 데이터베이스를 보여주는 스택 막대 그래프에서 볼 수 있으므로 이제 데이터베이스와 상호 작용하고 있습니다. 더 일반적으로 실행되는 응용 프로그램에 대해 예상되는 프로필입니다.

좋아, 내가 보여줄 수있는 다른 것들을 골라 고르고있다. 이것은 많은 상점을 놀라게하기 때문에 많은 사람들이 이것을 좋아합니다. 비즈니스 SLA를 충족 할 수없고 모두가“도움을주세요.”와 같은 경우, 이 상점은 비즈니스 SLA가 오후 3 시까 지 주문을받는 상황에 처해 그날 배송됩니다. 그들이 주문을받는 것이 매우 중요하며 창고는 매우 바쁩니다. 이 JD Edwards의 판매 주문 화면은 어려워졌으며 이는 적시에 소매 소매 재고 관리 시스템이라는 매우 좋은 아이디어를 얻을 수 있습니다. 빈 선반은 소매점에서 허용되지 않습니다. 상품을 팔려면 거기에 상품이 있어야합니다. 우리가 한 일은 SQL 서버 데이터베이스를 살펴 보는 것입니다. 모양과 느낌은 SQL, Oracle, DB2 또는 Sybase와 동일합니다.

우리는 PS_PROD에서 선택을 확인했으며 실행 시간을 포착 할 수있었습니다. 진한 파란색은 대기 상태 또는 로깅 또는 스토리지를 기다리지 않는다고 말하는 키와 일치합니다.이 것은 CPU에 의해 구속됩니다. 우리는 34301에 의해 SQL 문을 추적 했으므로이 명령이 실행될 때마다 카운터를 증가시켜 추적합니다. 즉, 자세한 내역이 있으며 해당 튜닝 버튼을 클릭하여 액세스 할 수 있습니다. 기록 탭은 다음과 같습니다. 이 화면에는 평균 지속 시간과 변경 사항이 표시됩니다. 수요일, 목요일, 금요일, 평균 지속 시간은 약 2/10 초입니다. 화면 정지가 거의 없으며 비즈니스 SLA를 충족 할 수 있습니다. 2 월 27 일이되면 뭔가가 바뀌고 갑자기 실행 시간이 다되어 실제로 시간이 초과되어 화면이 정지됩니다. 실행 계획 및 해당 SQL이 사용중인 경우 테이블 인덱스의 일반적인 변경 사항을 포함하여 자세한 히스토리를 유지하여 정확하게 작성하십시오. 우리는 2 월 27 일에 액세스 플랜이 변경되었다는 것을 알 수있었습니다. 월요일부터 금요일까지 나쁜 주. 3 월 5 일부터 액세스 플랜이 다시 변경되었습니다. 좋은 주입니다. 이 분홍색 별은 볼륨이 업데이트되었음을 ​​알려줍니다.

여기서 기본 테이블의 행 수가 증가하고 있으며 이는 비즈니스에서 일반적입니다. 당신은 당신의 테이블이 자라기를 원합니다. 문제는 명령문이 구문 분석되고 SQL 문이 들어 오며 옵티마이 저가 수행 할 작업을 결정하고 실행 계획이 빠를 때 선택하고 느릴 때 다른 실행 계획을 선택하여 화면을 정지시켜야한다는 것입니다. 심도 깊은 기술을 바탕으로 실행 계획이 무엇인지 알아야하며 정확한 날짜 및 시간 소인이 포함되어 있습니다. 이것은 빠르고 효율적이며 느리고 비효율적 인 것입니다. 이 필터 조인은이 특정 SQL 문을 수행하기 위해 훨씬 더 많은 CPU를 사용하여 조정합니다. 그것들은 여전히 ​​같은 궁극적 효과를 갖지만, 기본적으로 결과 세트를 전달하는 데 느리고 덜 효율적인 레시피가 있습니다. 그래서 우리는 단계별로 진행합니다. 이봐 요, 커플 더 시간 있어요?

에릭 카바나 흐 : 예, 가요.

빌 엘리스 : 알겠습니다. 건너 뛸 게요. 하드웨어에 대해, SAP에 대해, .NET에 대해, JD Edwards 및 Java-SQL Server 환경에 대해 이야기했습니다. 이것이 바로 SAP입니다. 여기에서는 PeopleSoft를보고 있습니다. 정확한 지원 매트릭스는 넓고 깊습니다. 응용 프로그램이있을 경우 이러한 가시성을 제공하도록 계측 할 수 있습니다. 현재 가장 큰 변화 중 하나는 이동성입니다. PeopleSoft는 Fluid UI로 이동성을 도입했습니다. Fluid UI는 시스템을 매우 다르게 사용합니다. 이 응용 프로그램은 진화하고 있습니다. Fluid UI – 관리 관점에서 볼 때 최종 사용자는 전화를 사용할 수있어 생산성이 크게 향상됩니다. 직원이 수백 또는 수천 명 이상인 경우 생산성을 1-2 % 향상시킬 수 있다면 급여 및 기타 모든 것에 큰 영향을 줄 수 있습니다. 이 특정 상점은 PeopleSoft Fluid UI를 출시했습니다. 이제 복잡성에 대해 이야기하면 이것이 PeopleSoft 스택입니다. 하나의 응용 프로그램, 최소 6 개의 기술, 수많은 최종 사용자. 어떻게 시작합니까?

다시 한 번 Precise는 이러한 거래를 수행 할 수있게됩니다. 여기서 보여 드리는 것은 클라이언트, 웹 서버, Java, Tuxedo 데이터베이스, PeopleSoft 애플리케이션 스택을 보여주는 누적 막대 그래프입니다. 초록색은 J2EE에 매핑되는데 이는 WebLogic을 표현하는 멋진 방법입니다. 이것은 컷 오버입니다. 최종 사용자는 Fluid UI를 사용하기 시작하고 응답 시간은 1.5 초에서 2 초에서 최대 9-10 초입니다. 이 한 화면에 표시되지 않는 것은“응답하지 않은”사람들의 수입니다. 실제로 응용 프로그램에서 화면이 정지되었습니다. Precise가이 고객에게 제공 할 수있는 가시성의 일부를 살펴 보겠습니다.

우선 PeopleSoft 트랜잭션을 살펴보면 기본적으로 볼 수 있습니다. 우리는 전반적으로 이러한 유형의 것을 보았습니다. 모든 거래뿐만 아니라 모든 위치에 영향을 미쳤습니다. 또한 이걸 보면 실제로 전세계의 위치를 ​​볼 수 있습니다. 아시아 태평양에서 유럽뿐만 아니라 북미까지. 성능 문제가 특정 트랜잭션이나 특정 지리적 위치에 있지 않은 것은 시스템 전체입니다. Fluid UI가 전 세계적으로 영향을 미쳤다는 것을 말하는 일종의 방법입니다. 확장 성 관점에서 볼 수 있듯이 사람들은 동일한 유형의 활동을 시도하지만 응답 시간은 기본적으로 저하되고 저하됩니다. 사물이 스케일되지 않는 것을 볼 수 있습니다. 상황이 매우 나 빠지고 있습니다. 여기에서 축 수와 동시 연결을 살펴보면 액세스 수와 연결 측면에서 매우 흥미로운 것을 볼 수 있습니다. 여기서는 최대 5, 000 개까지만 확장 할 수 있으며 현재보고있는 것은 100 개 동시 연결입니다. 이것은 후에 이루어집니다. 이것은 이전입니다. 따라서 시스템에 대한 나의 실제 수요는이 정도일 수 있다면 300, 000 범위에 있습니다. 예전에는 클래식 UI를 사용하여 30 개의 동시 연결을보고있었습니다.

이제 이것이 Fluid UI가 10 배 이상의 동시 연결을 사용한다는 것을 알려줍니다. PeopleSoft에서 다루고있는 일을 철회하기 시작하여 웹 서버에 미치는 영향, SLA가 위반되기 시작한 사실을 확인할 수 있습니다. 모든 것에 들어가지는 않지만 결국 일어나는 일은 기본적으로 메시징에 의존한다는 것입니다. 기본적으로 운동은 WebLogic이며 Tuxedo 내에서 큐잉을 유발합니다. 실제로 Fluid UI와 함께 나타나는 다 계층 종속성 문제가 있었지만 Precise는 다양한 요소를 통해 문제가 무엇인지에 집중할 수 있음을 보여줄 수있었습니다. 데이터베이스 자체에도 문제가 있음이 밝혀졌습니다. 실제로 메시징 로그 파일이 있으며 모든 동시 사용자로 인해 해당 로그 파일이 잠겼습니다. 기본적으로 응용 프로그램 스택 내의 모든 단일 계층에서 조정할 사항이있었습니다. 복잡성에 대해 이야기하십시오. 여기 실제로 Tuxedo 계층이 큐잉을 표시하고이 계층 내에서 성능이 저하되는 것을 볼 수 있습니다. 나는 과정을 볼 수 있었다. 도메인과 서버를 볼 수있었습니다. Tuxedo에서 사람들이이를 사용하려면 일반적으로 슈퍼마켓에서와 같이 추가 혼잡을 완화하기 위해 추가 대기열, 도메인 및 서버를 열어 대기 시간을 최소화하는 것입니다. 마지막 옵션 인 Precise에는 많은 정보가 표시됩니다.

앞서 언급했듯이 모든 중요한 거래는 레코드 시스템과 상호 작용합니다. 데이터베이스에 대한 가시성이 가장 중요합니다. Precise는 데이터베이스, WebLogic, Java, .NET, 브라우저 내에서 발생하는 상황을 보여 주지만 Precise가 실제로 탁월한 위치는 데이터베이스 계층입니다. 이것은 경쟁사의 약점입니다. Precise가이를 수행하는 데 도움이되는 방법 중 하나를 보여 드리겠습니다. 데이터베이스 최적화의 삼각 관계에 시간을 투자하지는 않지만 기본적으로 저비용, 저 위험, 광범위한 고위험, 고비용 유형 변경 사항을 검토하고 있습니다. 사람들이 시도해보고 싶다면 실제로이 슬라이드를 트윗 할 것입니다. 튜닝 문제에 대한 꽤 큰 안내서라고 생각합니다. Precise for Oracle 전문가의 견해는 다음과 같습니다. 결과 보고서에서 60 %의 영향은이 특정 SQL 문에 영향을줍니다. 이 활동 화면을 열면 화면에 표시됩니다. 이 select 문을 볼 수 있습니다. 하나의 실행 계획이 있습니다. 모든 실행에는 1 초 – 48, 000 회의 실행이 필요합니다. 따라서 최대 48, 000 시간의 실행 시간이 늘어납니다.

진한 파란색은 다시 한번 CPU입니다. 이것은 로그가 아니라 대기 상태가 아니라 CPU 바운드입니다. 경쟁사 중 일부는 대기 상태와 로깅 이벤트 만 보지만 일반적으로 말하면 CPU는 가장 바쁜 실행 상태이며 가장 많은 환매를 제공합니다. 이 전문가의 견해에 들어 서면 저는 매우 빠르게 가고 있습니다. 제가 한 일은 테이블, 100, 000 행, 37, 000 블록을 살펴 보는 것입니다. 우리는 풀 테이블을하고 있지만이 일에 대해 6 개의 색인이 있습니다. 무슨 일이야? where 절을 보면이 where 절이 실제로 수행하는 것은 실제로 열을 대문자로 변환하고 대문자와 같은 곳을 찾고 변수를 찾는 것입니다. 일어나는 일은이 일이 실행될 때마다 오라클은이 열을 대문자로 변환해야합니다. 거의 5 만 번이 아니라 함수 기반 인덱스의 대문자로 해당 인덱스를 작성하는 것이 훨씬 더 효율적이며 Oracle Enterprise 부서뿐만 아니라 표준 부서에서도 사용할 수 있습니다. 그렇게하면 할 수있는 일은 새로운 인덱스 사용자 파마를 발행하는 실행 계획을 확인하는 것입니다.

그런 다음, 전후 측정에서 1 초의 실행 시간을보고 동일한 SQL 문으로 최대 9 시간 54 분을 집계하지만 58, 000 회의 실행을 위해 해당 색인이 대문자로 작성되어 응답 시간은 1 밀리 초 미만으로 떨어지고 함께 집계되며 최대 7 초입니다. 기본적으로 서버에 10 시간의 CPU를 절약했습니다. 이것은 크다. 서버를 새로 고칠 예정이 아니라면 해당 서버에서 살 수 있기 때문입니다. 실제로 해당 서버 사용량을 20 % 줄이며 실제로 이전과 이후를 볼 수 있습니다. 이것이 Precise가 제공 할 수있는 가시성 유형입니다. 우리가 볼 수있는 몇 가지 추가 사항이 있습니다.이 색인을 사용하지 않으면 왜 모든 색인이 있습니까? 그들은 후속 조치를 취할 수 있습니다. 아키텍처가 있으며, 우리가 시간의 정상에 도달하고 있기 때문에 마무리하겠습니다. 저는이 솔루션의 진정한 신자이며 여러분이 진정한 신자가되기를 바랍니다. IDERA는 평가판을 통해 고객을 확보 할 수 있다고 생각하므로 관심이 있으시면 귀하의 사이트에서 평가를 수행 할 수 있습니다.

이것으로 비콘을 다시 전달하겠습니다.

에릭 카바나 흐 : 네, 여기에 당신이 보여준 엄청난 세부 사항이 있습니다. 정말 매력적입니다. 과거에 내가 당신에게 언급 한 것처럼 생각합니다 – 그리고 우리가 IDERA로 수행 한 다른 웹 캐스트 중 일부에서, 나는 언급했습니다 – 실제로 IDERA에 의해 인수되기 전부터 정확한 추적을하고 있습니다. 2008 년, 2009 년, 2009 년으로 거슬러 올라갑니다. 그 당시에는 그것에 매료되었습니다. 새로운 응용 프로그램 릴리스를 유지하는 데 얼마나 많은 작업이 필요한지 알고 싶습니다. SAP HANA는 실제로 HANA 아키텍처를 파헤쳐 서 문제를 해결할 수 있다는 점이 인상적이라고 생각했습니다. 얼마나 많은 사람들이 있습니까? 얼마나 많은 노력을 기울이고 있고 얼마만큼 동적으로 수행 할 수 있습니까? 즉, 도구가 배포되면 크롤링을 시작하고 다른 것을보기 시작합니까? 사람들이 복잡한 환경의 문제를 해결하는 데 도움을 줄 수 있도록 도구에 의해 동적, 정렬, 확인 가능한 양은 얼마입니까?

Bill Ellis : 많은 질문을했습니다.

에릭 카바나 흐 : 죄송합니다.

Bill Ellis : 코드를 살펴보면 악마가 상세하게 설명되어 있기 때문에 많은 세부 사항을 제공했습니다. 실제로 실행 가능한 무언가를 가질 수 있으려면 세부 수준이 필요합니다. 실행 가능한 메트릭이 없으면 증상에 대해서만 알 수 있습니다. 실제로 문제를 해결하지는 않습니다. IDERA는 문제 해결에 관한 것입니다. 새로운 릴리스와 자료를 유지하는 것은 큰 도전입니다. 이를 수행하는 데 필요한 문제는 실제로 제품 관리를위한 것입니다. 나는 기본적으로 우리를 최신 상태로 유지하는 팀에 대한 많은 가시성을 가지고 있지 않습니다. HANA의 관점에서 볼 때 이는 실제로 IDERA 제품군에 새로 추가 된 것입니다. 그거 정말 신난다. HANA의 장점 중 하나는 – 작업에 대해 잠시 이야기하겠습니다. 이 작업에서 SAP 상점은보고 목적으로 데이터베이스를 복제합니다. 그런 다음 사람들이 실제로 최신 상태로 조정하도록해야합니다. 서로 다른 데이터베이스가 있고 서로 다른 수준에서 동기화되지 않았습니다. 많은 시간과 노력이 필요하며 하드웨어, 소프트웨어 및 모든 것을 유지 관리하는 사람들이 있습니다.

HANA의 아이디어는 기본적으로 중복 데이터베이스의 필요성을 피하기 위해 병렬 메모리 내 데이터베이스를 병렬화하는 것입니다. 우리는 하나의 데이터베이스, 하나의 진실의 원천을 가지고 있으며, 항상 최신 상태이므로 모든 화해를 수행하는 데 필요한 것을 피할 수 있습니다. HANA 데이터베이스의 성능의 중요성이 커지고 있습니다. 저는 다른 모든 데이터베이스, 하드웨어, 리소스가 구매할 수있는 모든 것의 합보다 10 배 이상 가치가 있다고 말씀 드리겠습니다. HANA를 관리 할 수있게되었으므로 이제 구성 요소가 실제로 베타 테스트 중이므로 곧 GA로 전환 될 것입니다. 따라서 IDERA에게는 기본적으로 SAP 플랫폼을 지원하는 것이 매우 흥미 롭습니다. 귀하의 질문에 다른 부분이 무엇인지 잘 모르겠지만 –

에릭 카바나 : 아니요. 나는 당신에게 한 번에 모든 무리를 던졌습니다. 죄송합니다. 나는 단지 매료되었습니다. 정말로, 이것은 매우 간단한 응용 프로그램이 아니라는 것을 의미합니다. 당신은이 도구들에 대해 깊이 파고 들고 그들이 서로 상호 작용하고 당신의 요점을 어떻게 이해하고 있는지 이해하고 있습니다. 실제로 발생하는 문제와 문제를 일으키는 원인을 이해하려면 약간의 정보를 결합해야하므로 문제를 해결할 수 있습니다.

한 참석자가 묻습니다. 정확한 구현이 얼마나 어려운가요? 또 다른 사람이 물어 보았습니다. 사람들은 누구입니까? 명백히 DBA는 아니지만이 도구를 사용할 조직의 다른 역할은 누구입니까?

Bill Ellis : Precise는 배포하기가 조금 더 복잡합니다. 응용 프로그램 환경에 대한 지식이 있어야합니다.이 응용 프로그램은이 데이터베이스에서 실행되고 필요하거나 중간 계층 웹 서버 등이 필요합니다. 실제로 비교적 쉽습니다. 웹 서버를 데이터베이스까지 인스트루먼트 할 수 있다면 엔드 투 엔드를 수행 할 수 있습니다. 내가 최종 사용자 클라이언트를 계측하는 것에 대해 아무 말도하지 않았으며, 우리가하는 일은 실제로 동적으로 포함되기 때문에 코드 나 다른 것을 변경할 필요가 없습니다. JavaScript는 응용 프로그램 페이지 프레임으로 들어갑니다. 사용자가 전 세계 어디에 있든지 응용 프로그램에서 URL에 액세스하여 해당 페이지를 가져 오면 Precise와 함께 제공됩니다. 이를 통해 최종 사용자 브라우저 내에서 각 페이지 구성 요소 스크립트 실행 시간의 첫 번째 바이트 렌더링 시간과 사용자 ID, IP 주소를 선택할 수 있습니다.

트랜잭션 측면에서 트랜잭션은 밀접하게 연결되어 있기 때문에 매핑 할 필요가 없습니다. 이 URL은 JVM의 시작점이되고이 메시지를 호출하여 데이터베이스에서 JVC를 포착했습니다. 기본적으로 이러한 자연적인 연결 지점을 파악한 다음 거래 화면에 표시하여 각 단계에서 소요 된 시간 또는 시간 비율을 계산 한 위치를 보여줍니다. 이 모든 것이 자동으로 수행됩니다. 일반적으로, 우리는 기본적으로 Precise 코어를 설치하고 애플리케이션 구현을 시작하기 위해 90 분을 할애합니다. 응용 프로그램에 대한 지식에 따라 전체 응용 프로그램을 계측하는 데 몇 가지 추가 세션이 필요할 수 있습니다. 많은 사람들이 Precise의 데이터베이스 구성 요소 만 사용합니다. 괜찮아. 기본적으로 이것을 분해하여 사이트에서 필요하다고 느끼는 구성 요소로 나눌 수 있습니다. 전체 애플리케이션 스택을 인스트루먼트 한 컨텍스트가 계층 간 종속성이 실제로 개별 계층 모니터링의 가치를 확대한다는 것을 알 수 있습니다. 누구든지 애플리케이션 스택을 추가로 계측하려는 경우 웹 사이트를 방문하십시오. 추가 정보를 요청하는 가장 쉬운 방법 인 것 같습니다. 조금 더 자세히 설명하겠습니다.

Eric Kavanagh : 한두 가지 간단한 질문을하겠습니다. 시간이 지남에 따라 개별 클라이언트 및 전체 기업 엔티티로서 다양한 응용 프로그램과 다양한 데이터베이스 간의 상호 작용에 대한 저장소를 수집하고 구축하고 있다고 생각합니다. 다시 말해, 시나리오 모델링은 내가 암시하는 것입니다. 그 경우입니까? 실제로 특정 상황이 발생할 때 최종 사용자에게 제안 할 수 있도록 일종의 공통 시나리오 저장소를 유지합니까? 이 버전의 E-Business Suite, 이 버전의 데이터베이스 등 – 그 중 많은 부분을 수행합니까?

Bill Ellis : 글쎄, 그 유형의 정보는 결과 보고서에 내장되어 있습니다. 결과 보고서는 성능 병목 현상이 무엇이며 실행 시간을 기반으로합니다. 그 결과 보고서의 일부는 더 많은 것을 배우고 다음에 무엇을하는지에 대한 것입니다. 고객의 정보 또는 경험 등은 기본적으로 권장 라이브러리에 통합됩니다.

에릭 카바나 흐 : 좋습니다. 여러분, 오늘 환상적인 프리젠 테이션입니다. 빌, 나는 당신이 거기에 얼마나 많은 세부 사항을 가지고 사랑했다. 방금 이것이 환상적이고 칙칙하고 세분화 된 정보라고 생각했습니다. 특정 시점에서 그것은 거의 흑마 법과 같지만 실제로는 그렇지 않습니다. 응용 프로그램이 느리게 실행될 때 아무도 좋아하지 않기 때문에 매우 복잡한 환경을 이해하고 사람들을 행복하게 만들기 위해 함께 사용하는 매우 구체적인 기술입니다.

여러분, 이 웹 캐스트를 보관하겠습니다. Techopedia 또는 insideanalysis.com에 온라인으로 접속하여 시간 내 주셔서 감사합니다. 다음에 연락 드리겠습니다. 잘 가세요