복잡한 peoplesoft 환경의 성능 관리

작성자 : Techopedia Staff, 2017 년 9 월 6 일

테이크 아웃 : 호스트 Eric Kavanagh는 이번 Hot Technologies 에피소드에서 Matt Sarrel 및 Bill Ellis와 PeopleSoft 성과 관리에 대해 논의합니다.

에릭 카바나 흐 : 좋아, 신사 숙녀 여러분. 다시 한번 환영합니다. 동부 표준시로 4시 방향에 수요일이며 지난 몇 년 동안 IT와 대기업 및 데이터의 세계에서 핫 테크놀로지가되었습니다. 네, 사실 저는 Eric Kavanagh입니다. 오늘 행사의 중재자가 되겠습니다.

우리는 비즈니스를 운영하는 시스템에 대해 이야기 할 것입니다. 우리는 PeopleSoft, 복잡한 환경의 성능을 관리하는 방법에 대해 이야기하고 있습니다. 나는 항상 언급하고 싶습니다.이 행사에서 당신은 큰 역할을하므로 부끄러워하지 마십시오. 언제든지 질문하십시오. 채팅 창이나 Q & A를 사용하여 대화를 진행할 수 있습니다. 나는 당신이 알고 싶은 것을 듣고 싶습니다. 그것이 최선의 방법입니다. 당신은 당신의 시간에 가장 적합한 가치를 얻습니다. 나중에들을 수 있도록 이러한 웹 캐스트를 모두 보관하므로 명심하십시오.

시스템이 느리게 작동하는 경우 수명이 어땠는지 명심하십시오. 이 사진은 실제로 Danelle이라는 여성의 호의로 1968 년부터 발간 된 것입니다. 세계는 훨씬 더 복잡해졌으며 물론 비즈니스 요구와 사용자 경험이 밀접한 관련이 있습니다. 그러나 요즘에는 약간의 연결이 끊어졌습니다. 우리가 자주 말하듯이, 불일치가 있으며, 사실 비즈니스 사람들은 항상 더 빠르고 더 빨리 물건을 원하고, 제공해야하는 IT 팀은 업무를 완수해야하는 압박을받는 사람들이며, 세계는 강렬한 세상입니다.

말할 것도없이, 경쟁은 어느 곳에서나 뜨거워졌습니다. 모든 산업을 살펴보면 요즘 아마존이 Whole Foods를 구입하는 등 주요 개발이 진행되고 있음을 알 수 있습니다. 당신은 식료품 산업이 그 것을 열심히보고 있다는 것을 확신 할 수 있습니다. 우리는 이것을 모든 곳에서보고 있습니다. 따라서 비즈니스 리더는 디지털 전환, 기존 배전반을 넘어 훨씬 더 새롭고 강력한 시스템으로 전환하는 방법 (그리고 요즘 유행어)을 파악해야합니다. 그것이 우리가 오늘 이야기 할 내용입니다.

많은 조직이 직면 한 문제 중 하나, 특히 오래 전부터 있었던 문제는 이러한 레거시 시스템입니다. 예전의 IBM 메인 프레임입니다. 사방에 레거시 시스템이 있습니다. 농담 중 하나는 레거시 시스템이 생산중인 시스템이라는 점입니다. 즉, 생산에 들어가는 순간, 기술적으로는 레거시 시스템입니다. 항상 새로운 일을하는 방법이 있습니다.

그리고 지난 몇 년 동안 한 시스템의 성능을 향상시킬뿐만 아니라 성능을 처리하기위한 일종의 오프 슈트 또는 오프로드 전술을 만드는 방법을 찾기 위해 시스템을 가상으로 조정하는 방법을 찾는 데있어 매우 흥미로운 발전이있었습니다. 다른 방법으로. 오늘 우리는 PeopleSoft와 같은 시스템의 성능을 향상시키는 방법에 대해 더 이야기 할 것입니다. 물론 이것은 매우 복잡합니다. 그러나 제대로 수행되면, 로드 될 때, 구현 될 때, 잘 관리 될 때, 훌륭한 일을 할 수 있습니다. 그러나 제대로 관리되지 않으면 모든 종류의 문제가 발생합니다.

어떻게됩니까? 사용자가 원하는 것을 얻지 못하면 조만간 그림자 시스템으로 이동합니다. 항상 일어난다. 섀도우 시스템은 매우 생산적 일 수 있으며 사람들이 작업을 수행하도록 도울 수 있습니다. 그러나 물론 많은 문제가 있습니다. 규정 준수 및 규제의 전체 영역에서 섀도우 시스템은 큰 문제가되지 않습니다. 그러나 그들은 거기에 있고 시스템이 빠르게 작동하지 않거나 효율적으로 작동하지 않으면 조만간 해결 방법이 있으며 그 해결 방법이 매우 어려울 수 있다는 것을 기억하는 것이 중요하다고 생각합니다. 비즈니스에 결정적인 역할을하기 때문에 일몰하기 어려울 수 있습니다. 그것들은 통합하기 어려울 수 있으므로 밖에 있다는 것을 명심하십시오. 성능을 향상시키는 또 다른 이유입니다.

최근에 나는이 표현에 대해 들었고“긴급한 폭정”을 던져야합니다. 나는 당신이 아마도 내가 무엇에 관해 이야기하고 있는지, 그리고 대부분의 조직에서 일어나는 일을 알고 있다고 생각하는 것만으로도 워크로드가 임계 질량에 도달한다는 것을 듣고 사람들이 할 수있는 한 많은 일을하고 있으며, 무엇이든 바꾸는 것이 매우 어려워집니다. “긴급한 폭정”으로 고통을 겪습니다. 모든 것이 즉시 완료되어야합니다. 글쎄, 시스템 업그레이드는 즉시 일어나지 않습니다.

한 버전에서 다른 버전으로 ERP를 업그레이드 한 경험이있는 사람은 비교적 힘든 과정이라는 것을 알고 있으므로 다음 사항에 유의하십시오. 조직에서 볼 경우 인식하십시오. 바라건대 누군가에게 다가 갈 수 있거나 CIO 나 CTO 또는 CEO와 같은 상급자 인 경우 여덟 공을 받고 나면 뒤에서 나가기가 매우 어렵 기 때문에 이것이 매우 위험한 시나리오라는 것을 인식하십시오. 여덟 공.

마치 전체 마라톤 수수께끼와 같습니다. 어떤 종류의 경주에서 뒤쳐지고 모든 사람들이 당신보다 앞서 달리고 모두 계속 달리고 있다면, 너무 뒤쳐지면 따라 잡기가 정말 어려울 것입니다. 그러니 그걸 조심하고 명심하십시오.

이를 통해 Matt Sarrel에게 전달하여 PeopleSoft 환경의 복잡성을 처리하는 방법에 대한 통찰력을 제공 할 것입니다. 맷, 가져가

Matt Sarrel : 알겠습니다. Eric. 여러분 안녕하세요. 먼저, 제가 성과 관리에 관해 귀하와 대화를 나눌만한 사람이라고 생각하는 이유를 설명하겠습니다. 저는 30 년의 기술 경험이 있습니다. 실습, 네트워크 관리자, IT 담당 이사, 몇 명의 신생 기업 엔지니어링 담당 부사장을 통해 일을 시작했습니다. 그런 다음 PC Mag의 기술 책임자로 전환했습니다. 내 사진이 있지만 기본적으로 나는 어린 아이처럼 보입니다.

그런 다음 eWeek 및 InfoWorld와 같은 다양한 출판물에서 기자로 활동하고 Gigahome의 분석가, Bloor Group과 네트워킹하고 컨설팅을 진행했습니다. 저도 있습니다 : 왼쪽의이 사진은 제가 지금 보이는 모습입니다. 중간에있는이 그림은 내가 매우 기뻐하는 곳입니다. 전선과 깜박 거리는 조명으로 가득 찬 방에서 추운 곳은 매우 추워 야하고 다른 사람들도 편안한 온도를 느끼기 위해서는 불편해야합니다. 슬기로운. 후속 질문이 있으시면 제 연락처 정보가 있습니다.

Eric이 이야기 한 것처럼 여기서 무대를 설정하고 성능에 대해 이야기하고 싶습니다. 우리는 이제 사용자가 소비자 앱과 웹 사이트에서 설정 한 이러한 기대를 가지고있는 세상에 들어 왔습니다. 그리고 사람들은 기꺼이 일하고 그곳에 앉아 시스템이 필요하기 때문에 시스템을 기다렸습니다. 이제 사람들은 실제로 그 자리에 앉아 있지 않습니다. 그래서 그들은이 오토바이가 트랙 주위를 날고 싶어하는지에 대한 질문입니다. 그들은 아마도 자전거를 타고 딸을 학교에 데려 오는 사람을 원하지 않을 것입니다. 그러나 당신은 어느 것을 제공 할 것입니까?

실제로 1 ~ 3 초 정도는 관대했습니다. 사람들도 즉각적인 반응을 원하고 어디에서나 액세스하기를 원하기 때문에 어렵습니다. 건물의 어느 곳이든 캠퍼스의 어느 곳이든, 비즈니스가 얼마나 잘 운영되는지에 따라 언제 어디서나 세계의 어느 곳이든 될 수 있습니다. 그리고 제가 구축하고자하는 것은 성능에 대해 이야기 할 때 사용자 경험의 각도에서 성능에 대해 생각하는 것이 중요하다는 것입니다.

측정 및 조정 전에 성능 목표를 정의하는 것이 중요합니다. 튜너 그림과 튜너 그림이 있습니다. 튜너 인 실제 남자는 자신이 무엇을 튜닝하고 있는지 알아야합니다. 그렇지 않으면 실제로 피아노에 손을 대고 튜닝 할 필요가 없습니다. 미리 목표를 정의하면 현재 상황에 맞게 목표를 조정하는 대신 실제 목표를 유지하게됩니다. 시간이 지남에 따라 메트릭을 모니터링하고 리소스로드 및 사용 패턴의 영향을받는 사용자로드 응용 프로그램 성능에 따라 시스템이 어떻게 변경되는지 이해하는 것이 중요합니다.

이 모든 것을 사용자 경험 또는 지원 사건과 함께 연관시키고, 제공 할 것으로 예상되는 성능에 대한 기준을 설정하고, 기준과의 편차에 접근 할 때 사전 경보를 통해 조치를 취할 수 있어야합니다. "고래 고래"상태에 도달하기 전에. 그리고 성능 문제의 근본 원인을 매우 빠르고 쉽게 파악하고 해결할 수 있어야합니다. 그리고 다시, 이것은 더 빠르면 좋을까요?

과거의 역사에서 개발 노력을 살펴보면 성능 ​​문제를 더 빨리 찾아서 해결할 수있을수록 좋습니다. 성능 테스트를 시작하거나 문제를 발견하기 위해 모든 코드 또는 시스템이 가동 될 때까지 기다리는 경우 너무 늦었다 고 말하지는 않지만 이제 마라톤에서 나쁜 출발을 한 사람입니다. 지금 당신은 바로 뛰어 넘어 앞서가는 대신에 캐치 업을하고 있습니다. 어떻게 이러나요? 평균 및 최대 부하를 예상하십니까?

그리고 물리적 서버 나 가상 서버, 클라우드 인스턴스 또는 컨테이너와 컨테이너 리소스의 크기를 조정 한 다음 개념 증명을 실행하고 파일럿을 실행합니까? 이것들은 일종의 시간이며, 무언가를 잡으려는 곳의 끝이지만, 생산에서는 그것을 무시하는 것보다 생산에서 그것을 잡는 것이 낫습니다. 그러나 실제로 파일럿이 진행될 때까지 지속적인 모니터링 및 개선에 대한 방법론과 절차를 이미 설정해야합니다.

많은 회사들이 – 우리는 디지털 혁신에 대해 이야기합니다. DevOps 혁명에서 DevOps는 디지털 혁신에서 큰 역할을하고 있습니다. 그리고 이것은 절대 멈추지 않는 엔드 투 엔드 프로세스입니다. 두 손이 서로 그림을 그리는 것과 같습니다. 이것은 좋은 것입니다. 계획, 코드, 빌드, 테스트, 릴리스, 배포, 운영, 모니터링, 계획으로 돌아가는이 두 손 사이에 무한 루프입니다. 자체적으로 피드하고 자동화하여 빠르게 진행됩니다. 프로덕션 성능 모니터링 피드백 루프를 작성하고이를 사용하여 성능 문제를 사전에 발견하고 전체 사용자 기반에 영향을 미치기 전에이를 해결합니다.

IT 개발자와 운영 직원이 매우 빠르게 이동하고 조정하는 또 다른 일로, 이러한 노력을 비즈니스 직원과 쉽게 조정할 수도 있습니다. 엔터프라이즈 소프트웨어 성능은 복잡한 문제입니다. 방향을 잡는 칠판 앞에 앉아있는 축구 팀에 비유 할 수 있으며 모든 것이 개별적으로 작동하고 모든 것이 함께 작동합니다. 나는 항상 그것을 첫 번째 차를 샀을 때의 오래된 이야기로 생각하고 한 가지를 고쳤습니다. 에어컨을 수리 한 다음에 나머지 냉각 시스템에 문제가 발생했습니다. 그래서 당신은 당신의 고통 포인트를 가지고 있고 모든 것이 함께 진행되고 조정됩니다. 변경 사항을 만들 때 모든 것이 다른 모든 것에 미치는 영향을 이해할 수 있도록 모든 방식을 구성하고 프로세스를 구축해야합니다.

또한 조심하고 다시 확인하십시오. 테스트, 무효화, 구현 그리고 다시 우리는 지속적인 모니터링 및 성능 개선 프로그램을 구축하는이 문제에 도달합니다. 사실 이것은 마지막 슬라이드입니다. 우리는이 복잡성에 대해 이야기하지만, 이 시계의 내부와 마찬가지로 아름다운 복잡성에도 불구하고, PeopleSoft에게는 많은 부분이 있습니다. 각 것은 스택의 위 아래로 모든 것에 영향을 미칩니다. 또한 올바른 도구 없이도 올바른 프로세스없이 쉽게 길을 잃을 수있는 성능 문제의 핵심을 찾을 수있는 곳이 너무 많습니다. 그리고 우리가 배운 것으로 생각되는 많은 경우에도 인프라 문제를 해결할 수 있지만 큰 변수는 사용자 지정 응용 프로그램 코드가 될 것입니다. 따라서 응용 프로그램 코드를 테스트하고 지속적으로 개선하기위한 올바른 프로세스를 갖추는 것이 중요합니다.

그리고 이것이 저의 끝입니다. 그리고 저는 이것을 Bill에게 넘겨 줄 것입니다.

에릭 카바나 흐 : 좋습니다, 빌, 여기서 WebEx의 열쇠를 알려 드리겠습니다. 나는 그 아름다운 복잡성을 좋아합니다 – 그것은 좋은 것입니다. 거기에 정말 좋은 인용문이 몇 개 있었어요, 매트 알았어 빌, 가져가 화면을 공유하려면 "빠른 시작"으로 이동하십시오. 당신들 모두.

빌 엘리스 : 고마워, 매트 고마워, 에릭 확인하기 위해 지금 모두 내 화면을 볼 수 있습니까?

에릭 카바나 흐 : 그렇습니다.

Bill Ellis : 따라서 IDERA의 Precise for PeopleSoft 제품과 복잡한 애플리케이션 스택 관리에 도움이되는 가시성에 대해 이야기하겠습니다. 문제를 해결하는 방법은 하나의 응용 프로그램, 최소 6 개의 기술, 수많은 최종 사용자가 있으며 간단한 질문에도 대답하기가 매우 어렵다는 것입니다. 최종 사용자에게 문제가 있습니까? 최종 사용자는 누구이며, 무엇을하고 있으며, 근본 원인은 무엇입니까?

우리가 일반적으로 보는 것은 이러한 상황입니다. 이는 PeopleSoft뿐만 아니라 다른 응용 프로그램 또는 다른 응용 프로그램과 상호 작용하는 PeopleSoft에 적용될 수 있습니다. 데이터 세트 내에 있거나 요즘 클라우드 일 수 있습니다. 최종 사용자는 실제로 신경 쓰지 않습니다 그 복잡성. 그들은 거래, 접근 방식, 재고 조회, 보고 시간표, 이러한 유형의 것들을 완료하려고합니다. 상황이 느리거나 이용할 수없는 경우, 일반적으로 의도가 좋은 모든 지능적인 사람들은 최종 사용자가 불평 할 때까지 알지 못합니다.

그것은 가시성 격차입니다. 사람들이 도구를 열면 불행히도 응용 프로그램 스택의 하위 집합 만 볼 수있는 시간이 많이 걸리고 실망스러운 프로세스가 시작될 수 있습니다. 따라서 기본적인 질문에 대답하는 데 어려움이 남아 있습니다.

그리고 종종 문제가있을 수 있으며 WebLogic 관리자에게 가서“음, 메모리, 가비지 콜렉션은 모두 훌륭해 보입니다. 나는 그것이 WebLogic이라고 생각하지 않습니다.”당신은 DBA 관리자에게 가서“데이터베이스는 어제처럼 실행되고 있습니다. 톱 10이 좋아 보인다. 스토리지 관리자는 초당 I / O 또는 처리량 (프레임 수준 메트릭)과 같은 일부 메트릭을 사용하여 특정 응용 프로그램, 데이터베이스 또는 특정 프로세스에 훨씬 적은 영향을 줄 수 있습니다.”

그리고 그들은 모두 문제가 다른 곳에 있다는 것을 보여주는 것처럼 보이는이 메트릭스를 가지고 있지만, 이 최종 사용자는 문제가 있거나 문제를보고했지만이 문제를 어떻게 더 잘 해결할 수 있습니까? 더 좋은 방법은, 정확한 방법 또는 우리가 제공하는 방법 중 하나는 브라우저를 통해 네트워크, 웹 서버, Java Jolt, Tuxedo, DB2를 포함한 데이터베이스로 시작하는 사용자 트랜잭션을 측정하는 것입니다. 마지막으로 스토리지에 저장합니다.

그리고 이것이 보여주는 것은 총 시간에 "글쎄, 누가 문제를 겪고 있습니까?"라고 말한 다음 PeopleSoft에 로그인 한 방법으로 최종 사용자를 식별하고 PeopleSoft 패널이 실행중인 Tuxedo 번역을 통해 캡처 할 수 있습니다.

따라서 타이밍은 우리가 성능 관리 데이터베이스라고하는 역사적인 리포지토리에 공급되며 이는 사람, 무엇, 언제, 어디서, 왜 크게 단순화하는 단일 음악 작품이됩니다. 정확한 권장 사항도 포함되어 있습니다. 아마도 가장 중요한 것은 기술 IT 직원 수준에서 모든 정보를 항상 캡처하기 때문에 이전과 이후를 측정 할 수 있기 때문입니다. 따라서 측정 또는 식스 시그마 (Six Sigma)로 측정하여 전체 성능 작동을 수행 할 수 있습니다.

그리고“삶의 하루”처럼 보도록하겠습니다. 우선, 정확한 경고 화면을 열면 조기 경고를받을 수 있습니다. 가장 중요한 경고는 활동 경고가 있다는 것입니다. 따라서 사용자는 거래를하고 있으며 기본적으로 SLA를 충족하지 않습니다. 마찬가지로 가용성이있을 때 상태가됩니다. 이는 기본적으로 애플리케이션 인프라의 일부를 사용할 수 없음을 의미합니다. 따라서 드릴 인 할 수 있으며 실제로 Tuxedo 인스턴스의 형태를 볼 수 있으며 실제로는 인스턴스가 다운되었습니다. 모든 활동이이 하나의 사례로 추진되고 있으며이를 처리해야합니다. 기본적으로 병목 현상이 발생했습니다.

이제, 이것에서 실행중인 활동에 대해 실제로 전체 인프라 문제가 있지만 WebLogic의 특정 JVM 내에서 처리 효율성을 향상시킬 수있는 방법이 있다는 사실을 실제로 발견 할 수 있습니다. 그리고 이것이 정말로 중요한 부분입니다. 사람들이 클라우드로 이동하는 경우가 많으며, "잘 CPU와 메모리가 얼마나 필요합니까?"라고 말합니다.

용량으로 알려진 동전의 다른 측면은 처리 효율성입니다. 더 적은 메모리를 사용하고 더 적은 CPU를 사용하면 단순히 많은 양이 필요하지 않습니다. Matt가 앞서 말했듯이 모든 것은 일종의 관련이 있습니다. 이제 내가 할 수있는 일은 PeopleSoft 거래 화면을 열고 화면에서 y 축은 응답 시간이고 x 축은 하루 종일 시간입니다.

여기에는 클라이언트 시간을 보여주는 스택 막대 그래프가 있습니다. 그것은 실제로 브라우저, 웹 서버입니다. 녹색은 Java 시간이고 분홍색은 Tuxedo이며 진한 파란색은 데이터베이스 시간입니다. 이 프로필은 그 자체로는 발생하지 않았습니다. 특정 PeopleSoft 패널로 인해 발생했습니다. 실행되었으며 응답 시간에 따라 표시됩니다. 실제로 응용 프로그램 내의 모든 단계 타이밍과 응용 프로그램을 패널별로 표시하는 스택 막대 그래프가 있습니다. 또한 특정 사용자를 찾아서 찾거나 내 순위를 매길 수도 있습니다.

이 화면에서 로그인 이름으로 특정 사용자를 지정할 수 있습니다. 이것이 얼마나 놀랍거나 강력한 지 생각해보십시오. 많은 경우 인프라뿐만 아니라 설정 방식, 최종 사용자가 시스템을 사용하는 방식에 관한 것이 아닙니다. 신입 사원이 있거나 누군가 새로운 직무를 수행 할 수 있습니다. 애플리케이션을 올바르게 사용하는 방법을 모를 수 있습니다. 이것은 실제로 훈련 기회를 식별하는 데 도움이 될 수 있습니다.

코인의 다른 측면은 특정 사용자에게 집중할 수있는 경우입니다. 여기서는 특정 거래에서 해당 사용자를보고 그들이 경험 한 응답 시간을보고 있습니다 – 특정 사용자의 사용자 경험을 직접 처리 할 수 ​​있습니다 사용자. 더 이상 시스템 수준의 일반 메트릭에 관한 것이 아니라 최종 사용자 경험에 관한 것이며 매우 강력합니다. 환경의 일부는 내부, HR 등이 될 것입니다. 고객이 직면하고있는 다른 부분이있을 수 있습니다. 어느 쪽이든 가능한 가장 생산적인 고객 경험을 제공하고자합니다.

이제 특정 패널의 경우 질문에 답변하기 위해 드릴 인 할 수 있습니다. 그래서 이것은 우리가 어떤 일이 일어나고 있는지를 알아 내기 위해 할 수있는 심층 다이빙입니다. 그리고 최종 사용자에게 전화하기 전에 또는 최종 사용자가 당신을 호출 한 경우이 심층 다이빙을 할 수 있습니다. “근본 원인은 정확히 어디입니까?”라고 말하십시오. CPU 사용률과 재정의와 같지 않을 것입니다. 응용 프로그램 코드에서 실행됩니다.

자세히 살펴보면 해당 컨텐츠 관리를 살펴보고 실제로 해당 트랜잭션의 분석을 볼 수 있습니다. 브라우저 시작, 웹 서버의 Java Jolt 진입 점 및 실제로 실행되는 코드를 보여줍니다. Tuxedo 패널, 마지막으로 Precise에서이 특정 PeopleSoft 패널에 의해 실행되는 SQL 문의 텍스트를 표시하는 SQL 문으로 이동합니다.

우리가 이야기하는 모든 사람들은 도구를 가지고 있지만 도구가없는 것은 맥락입니다. 점을 연결하거나 브라우저에서 SQL 문까지 트랜잭션을 따르는 것은 컨텍스트입니다. DBA와 마찬가지로이 작업은 인스턴스 또는 데이터베이스 수준에서 일을 보는 것이 아니라 SQL 문 수준에서 조사 할 수 있습니다.

“개인 SQL 문의 병목 현상은 무엇입니까?”라고 말할 수 있으며 이는 매우 강력합니다. 이 트랜잭션은 SQL 문보다 빠르게 실행될 수 없으며 모든 중요한 비즈니스 트랜잭션은 레코드 시스템과 상호 작용합니다. 데이터베이스는 성능과 상관없이 성능의 기초이며, 비즈니스 트랜잭션에 중요한 개별 SQL 문에 집중할 수있을 정도로 세밀한 수준이되면 게임을 한 단계 발전시킬 수 있습니다.

여기서 알 수있는 또 다른 사항은 Precise가 제공하는 비율 기여도 계산입니다. 브라우저 자체는 실제로 응용 프로그램 스택의 중요한 부분입니다. JavaScript 실행, 렌더링 시간, 페이지 구성 요소, GIF, JPEG가 있습니다. 그리고 실제로 Chrome과 IE 및 다른 버전에서는 응용 프로그램이 매우 다르게 작동 할 수 있습니다. Precise는 사용자에게도이를 보여줄 수 있으며 브라우저 내에 실제로 병목 현상이나 경합이 발생하여 화면이 멈추는 등의 문제가 발생할 수 있습니다.

이를 식별 할 수 있으면 IT가 잘못된 트리를 사용하지 않고 발생할 수있는 다양한 문제의 근본 원인을 해결할 수 있습니다. 이제 내가 할 수있는 것은 특정 SQL 문에 대한 것이고, 그런 다음 해당 SQL 문에서 발생하는 일을 정확하게 분석 할 수 있습니다. 이제 데이터베이스 전문가보기로 넘어갔습니다.

데이터베이스 수준에서 Precise를 구별하는 것 중 하나는 1 초 단위로 샘플링한다는 것입니다. 이것은 10 분에 한 번, 15 분에 한 번만 보이는 경쟁사와 비교됩니다. 세분성 수준, 해상도 수준은 경쟁사보다 훨씬 뛰어납니다.

그리고 데이터베이스가 우리 재단의 일부이기 때문에 DBA가 실제로 다음 단계로 성능을 향상시킬 수 있도록하겠습니다. 따라서이 SQL 문이 저장된 서브 시스템에 액세스하는 데 시간이 50 %, CPU를 사용하는 시간의 50 %가 실제로 50 %를 소비했음을 알 수 있습니다. 조정 버튼을 클릭하면 실행 계획과 해당 사용 패턴을 정확히 유도 한 원인을 자세히 살펴볼 수 있습니다.

Oracle Shop에 있지 않은 고객은 OEM이라는 Oracle 도구를 사용했으며 OEM은 실제로 일종의 데이터베이스 또는 인스턴스 중심입니다. DBA는 지속적으로 상위 10 개 목록을보고 있습니까? 그러나 Precise를 사용하면 점을 개별 SQL 문에 연결할 수 있으므로 세분성을 통해 DBA는 훨씬 높은 데이터베이스 수준뿐만 아니라 트랜잭션 수준에서도 실제로 조정할 수 있습니다.

이 고객에게 정말로 중요한 두 번째 요점은 URL이 복잡한 것을 PeopleSoft 패널 이름으로 변환하여 정확한 것입니다. IT에 있고 트리 관리자, 컨텐츠 관리자, 특정 HR 페이지에 대해 이야기 할 수있는 경우, 그런 식으로 내가 도와 주려는 사람은 내가 실제로보고있는 것을 알고 있고 더 이상 상형 문자가 아니기 때문에 그들이보고있는 것을 이해한다는 것을 알고 있습니다.

우리가 묻는 질문 중 하나 – 항상 똑같아요. 그래서 나는 적극적으로 질문에 대답하고 싶었습니다. 어떻게 세상에서 PeopleSoft 사용자 ID를 캡처합니까? 몇 가지 단계를 거치도록하겠습니다. 다음은 PeopleSoft 사인온 화면입니다. 액세스하려면 웹 서버를 탐색해야하는데이 화면이 나타납니다. 응용 프로그램이 Precise로 계측되면이 화면에는 실제로 정확한 스크립트가 포함되어 있으며 마우스 오른쪽 버튼을 클릭하여 소스를 볼 수 있습니다. 그리고 이것은 실제로 저에게 기본 페이지를 구성하고 페이지 프레임에서 여기에있는 코드가 실제로 웹 코드를위한 정확한 코드임을 보여줄 것이며 이것은 사인온 화면, IP 주소, 브라우저 유형, 전체를 캡처 할 수있게합니다 렌더링과 실제 최종 사용자 경험에 대한 많은 정보. 사용자 이름을 입력하고 로그인을 클릭하면 Precise에서 내가하고있는 일을 측정 할 수 있습니다.

트리 관리자로 가서 검색 작업을하고 필드를 채우고 검색을 클릭합니다. 결과 집합이 나에게 표시되므로 전체 응용 프로그램 스택을 데이터베이스까지 완전히 통과했습니다. Precise는 이것을 어떻게 표시합니까? 계속해서 살펴 봅시다. Precise를 열고 들어가서 활동을 볼 수 있으며이 화면을 표시 할 활동 탭을 클릭 할 수 있습니다. 번역되지 않은 URL입니다. 사용자를 표시 할 수 있으며 여기에 방금 로그인 한 사용자 ID가 있고 여기 내 활동이 있습니다.

Firefox 버전 45를 사용하여이 기능을 사용하고 있음을 알 수 있습니다. 나는 응용 프로그램을 12 번 연습했으며 포기는 기본적으로 누군가 웹 페이지가 완전히 렌더링되기 전에 떠나는 것이므로 비즈니스 문제를 시사합니다. 이것이 우리가 최종 사용자 ID를 얻을 수있는 방법입니다. 아주 좋은 일입니다. 사람들은 무슨 일이 있었는지 정확히 알면 정말 감사합니다.

이제 기어를 조금 이상하게 바꾸고 싶습니다. 우리는 나중에 거래를보고있었습니다. 특정 트랜잭션에 대해 자세히 알아보고 SQL 문을 살펴 보았습니다. 이제 기어를 바꾸고 WebLogic부터 시작하여 PeopleSoft 애플리케이션 스택 내의 다른 기술을 살펴보고 싶습니다.

여기 WebLogic 인스턴스가 있으며 시간이 지남에 따라 활동을 볼 수 있습니다. 재무 보고서가 있습니다. 그것은 바로 박쥐에게 나에게 알려주고, 메모리는 거의 최대로 사용됩니다. 우리가 찾은 것 중 하나는 대부분의 사람들이 공유 환경에서 전체 애플리케이션 스택 또는 적어도 일부를 실행한다는 것입니다. 종종 VMware입니다. 요청한 자원의 양과 필요한 양의 균형을 유지해야합니다. 당신은 자원 돼지가되고 싶지 않습니다. 마찬가지로, 이 경우 충분한 메모리를 요구하지 않아서 처리 제한 조건을 적용하지 않으려 고합니다.

구성은 성능 관리에도 필수적입니다. 따라서 실제로 메모리 가비지 수집 및 모든 JMX WebLogic 카운터에 들어갈 수 있으므로 WebLogic 양식의 상태를 정확히 알 수 있습니다.

이제 턱시도에 많은 상점의 턱시도는 일종의 블랙 박스이며 PeopleSoft의 매우 중요한 부분입니다. 모든 것을 하나로 묶는 접착제의 일종이므로 거의 운영체제의 확장이라고 생각합니다. 매우 신중하게 사용하고 구성하는 것입니다. 에릭은“긴급한 폭정”에 대해 언급했으며, PeopleSoft 상점이 클래식 UI에서 유동적 UI 로의 전환을 고려할 때 실제로 효과가 있다고 생각합니다. 유동적 UI가 PeopleSoft 환경을 실행하는 방식으로 인해 곡선 뒤에 있음을 발견하십시오.

이제 HTML5가 엄청난 양의 메시징을 수행하기 때문에 WebLogic, Tuxedo, 데이터베이스 및 스토리지에 문제가 있습니다. 아마도 클래식 UI가하는 것의 10 배 이상이며 추가 메시징은 추가 트래픽을 의미합니다. 따라서 추가 트래픽을 수용 할 수 있도록 Tuxedo의 구성을 수정해야합니다. 이 화면에 대한 몇 가지 사항은 오른쪽에 있으며 가중 응답 시간, 평균 응답 시간 및 실행 횟수에 대한 초과 시간 그래프가 있습니다.

여기에는 환경 내의 모든 Tuxedo 도메인에 대한 정보가 있습니다. 우리는 서비스, 사용자, 서버 프로세스 및 IP를 나누었습니다. 이것을 실행 횟수로 옮기고 내림차순으로 표시하여 가장 많이 실행되는 것을 볼 수 있습니다. 또한 아래로 스크롤하여 도메인을 표시 할 수 있습니다. 대부분의 사람들은 기본적으로 활동을 퍼 뜨리기 위해 환경에 여러 도메인을 가지고 있으므로 SLA 준수를 설정할 수 있으므로 Tuxedo 레이어에 경고합니다.

대기중인 경우 구성으로 인해 다른 문제가 발생합니다. 전 세계적으로 영향을 미치기 때문에 일반적으로 즉시 변경하지는 않습니다. QA 프로세스의 일부로 시스템을 점진적으로 늘리고 싶기 때문에 Matt은 프로세스 초기에 성능 문제를 해결하기 위해 이전에 작성한 시점으로 되돌아갑니다. 프로덕션으로 이동하지 않고 프로덕션에 갈 때 구성이 사용 패턴과 일치하지 않는 것을 확인하는 것이 올바른 구성을 유지하는 것이 훨씬 좋습니다. 저는 Eric과 Matt가 오늘 제공 한 소개를 정말 좋아합니다. 나는 PeopleSoft 환경을 관리하고 발전시키는 데 직면 한 문제의 측면에서 실제로 목표에 있다고 생각했습니다.

이제, 나는 이것을 전에 한 번 말했습니다 – 다시 말해야 할 가치가 있다고 생각합니다 : 모든 중요한 비즈니스 트랜잭션은 데이터베이스와 상호 작용합니다. Precise가 추가 정보를 제공 할 수있는 방법을 살펴 보겠습니다. 여기에 특정 Oracle 인스턴스가 있습니다. 우리가 본 것과 똑같은 접근 방식 – y 축은 실행 시간이고 x 축은 하루 종일 시간이지만 이제 스택 막대 그래프는 Oracle 내의 실행 상태입니다. 이것은 시스템의 처리 제약 조건을 보여줍니다. 아래에는 실제로 리두 로그 버퍼가 높다는 것을 알려주는 결과 보고서가 있습니다.

또한 PSVersion에서이 선택 버전을보고 있습니다. 실제로 많은 리소스를 소비하고 있습니다. 또한 샘플링 중이며 실제로 시스템에서 발생하는 상황에 대한 고해상도보기를 제공하기 때문에 시스템에서 실제 리소스 소비자가 무엇인지 놀라게 될 수 있습니다. 10 분마다 만 보더라도 그렇지 않습니다. 그 자원 소비자가 무엇인지 보여줄 것입니다. 따라서 실제 리소스 소비자가 무엇인지 알면 실제로 병목 현상이나 시스템에서 실제 처리를 처리 할 수 ​​있습니다.

이제 우리는 활동 탭으로 넘어갔습니다. 이것이 활동입니다. CPU, 스토리지 서브 시스템, 애플리케이션 잠금, OS 대기, RAC, 커밋, Oracle 서버, 통신 및 내부 집계를 함께보고 있음을 알 수 있습니다. 이것은 y 축이며, 총 실행 시간입니다.

아래에는이 프로파일을 주도한 SQL 문과 2 밀리 초의 짧은 대기 시간이 있지만 거의 4, 500 회의 실행으로 SQL 문이 실제로 시스템에서 가장 많은 리소스를 소비한다는 것을 의미합니다. 알고있다. 또한 잠금 또는 대기를 기다리지 않습니다. CPU를 100 % 사용하고 있습니다. 내가 할 수없는 일이 없다는 것을 의미하지는 않습니다. 어떤 SQL 문과 객체에 액세스하고 있는지 알고 있다면 그것에 대해 할 수있는 일이 많이 있습니다. 그리고 이것이 우리가 도울 수있는 몇 가지 방법입니다.

이제 여기에는이 드릴 다운이 있으며, 이로 인해 개별 PeopleSoft 프로그램과 관련하여 각 프로그램이 PeopleSoft 내에서 다른 목적으로 사용됩니다. 실제로 응용 프로그램 사용 방법을 데이터베이스 수준에서 처리하기 시작할 수 있습니다.

그리고 특정 프로그램을 선택하면 해당 프로그램이 제출 한 SQL 문을 분리하여 기본적으로 데이터베이스 최적화 및 데이터베이스 구성을보고 볼 때 데이터베이스 기술보다는 응용 프로그램에 중점을 둘 수 있습니다. 나는 이것을 당신의주의를 끌고 싶습니다. 종종 많은 대기업이 인프라 DBA와 애플리케이션 DBA로 나뉩니다. 정확하게, 응용 프로그램과 리소스 소비를 보여줌으로써 실제로 우리는 격차를 해소 할 수 있으며이 솔루션은 시스템의 두 유형의 DBA 모두에 유용합니다.

이 부분은 데이터베이스 수준에서 수행 할 수있는 작업을 보여줍니다. 그리고 여기서 일어난 일은 화면이 멈추고 PS_Prod에서 선택한 것이 있고 우리가 한 것은이 튜닝 버튼을 클릭하는 것입니다. 그리고 이것이하는 것은이 SQL 작업 공간으로 우리를 가져옵니다. 이제 DBA가 아닌 사람들에게는 이것이 흥미로워 보이지 않을 수 있습니다. DBA 인 사람들에게는 이것이 매우 흥미로울 것입니다. 여기서 보여주는 것은이 특정 SQL 문의 지속 시간과 시스템의 변경 사항입니다. 그리고 이것은 수요일, 목요일, 금요일을 나타내며, 지속 시간은 약 2/10입니다. 토요일과 일요일이 회사는 작동하지 않습니다 – 운이 좋았습니다. 월요일에 와서 변경되었습니다 : 액세스 플랜이 변경되었습니다. 새로운 액세스 플랜이 갑자기 시작되었습니다. 실제로 화면이 정지되는 속도가 느립니다.

이제 DBA 인 경우 실제 근본 원인을 알기 위해 추가 정보가 필요합니다. 데이터베이스 옵티마이 저가 선택한 선택을 알아야합니다. 따라서 Precise는 이러한 비교를 통해 작업이 잘 진행될 때 빠르고 효율적인 실행 계획과 느리고 비효율적 인 실행 계획을 보여줍니다. 이 필터 조인은 PeopleSoft를 실행하는 DBA에 공통입니다. 필터는 한 테이블에서 모든 행을 찾고 결합 테이블에서 모든 단일 행을 찾습니다. 많은 CPU가 필요합니다. 필요한 행의 하위 집합 만 필터링하지 않고 SQL 문에 의한 필터링이 없기 때문에 매우 비효율적이며 비효율로 인해 실행 시간이 느려집니다. 따라서 결국 화면 고정에서 PeopleSoft 패널 속도가 느려지고 Precise는 응용 프로그램 코드, SQL 문 등을 드러내는 도구가 없으면 알 수없는 실제 근본 원인에 도달 할 수있었습니다.

그것은 일종의 깊은 잠수였습니다. 이제 뷰를 10, 000 평방 피트의 대시 보드 뷰로 끌어 올릴 것입니다. Precise에서 대시 보드는 실제로 기술 팀을위한 것이 아니라 운영, 응용 프로그램 팀, 명령 체인과 정보를 공유하는 데 사용하기위한 것입니다. 따라서 하나의 대시 보드 세트에 PeopleSoft 패널과 클라이언트 시간이 표시되어 최종 사용자 경험이 무엇인지 알 수 있습니다. 다른 대시 보드가 작업용으로 구성되었을 수 있으며이 대시 보드는 경고가 얼 었는지 볼 수 있습니까? 실제로 OS, 웹, WebLogic, Tuxedo 및 데이터베이스 수준에 대한 경고가 있습니다. 여기에 경고가 없습니다. 평균 응답 시간입니다. 우리는 2 분의 1 정도가 달리고 있음을 알 수 있습니다. 여기서 실제로 내 인프라에서 내 환경의 모든 VM을 보여줄 수 있으며 처리, 로드 밸런싱을 시작할 수 있으며 Tuxedo 도메인을 볼 수도 있습니다. 이 특정 환경에는 6 개의 도메인이 있으므로 해당 도메인을 볼 수 있으며 실제로 웹 밸런싱을 시작할 수 있습니다.

이제 성능 관리 데이터베이스 인 PMDB에 수많은 메트릭이있는 Precise의 역사적인 리포지토리입니다. 때로는 누군가 브라우저 액세스 수에 대해 알고 싶어하거나 브라우저 유형별로 액세스 횟수를 계산하거나 브라우저 유형별로 성능을 계산할 수 있습니다. 시스템에 대한 추가 가시성을 제공하기 위해 수행 할 수있는 많은 작업이 있습니다.

여기, 우리는 실제로 WebLogic 메모리 사용량을보고 있습니다.이 멋진 톱니 패턴 인 메모리 사용량을 볼 수 있습니다. 가비지 콜렉션이 있으며 참조 해제를 검색합니다. 다시 돌아가서보고 싶은 아주 좋은 패턴입니다. 따라서 이는 PeopleSoft 환경을 하위 시스템 모음으로 간주하며 이는 작업에 적합합니다. 가장 기본적인 질문은 "글쎄, 서버에서 무슨 일이 일어나고 있습니까?"입니다. 정확한 모든 가시성이 있습니다. 서버 메트릭도 제공합니다. 시스템에서 실제로 CPU, 메모리, I / O, 서버, 사용자를 측정 할 수 있으므로 전체 가시성을 확보 할 수 있습니다. 이것이 장기 추세와 결합 된 방식으로 사람들이 용량 계획에 Precise를 사용하는 방식입니다.

그리고 나는 거기에 약간의 메모를 던지고 싶습니다. 일반적으로 상점에는 하드웨어, 서버, 직원에 대한 예산이 너무 많습니다. 투자는 어떻게합니까, 베팅은 어디에 하시겠습니까? Precise를 사용하면 스토리지 서브 시스템이 어떻게 사용되고 있는지 알기 때문에 우위를 점하게됩니다. 임의의 I / O를 많이 수행하는 경우 Precise가이를 보여줍니다. 솔리드 스테이트 스토리지에 대한 투자를 정당화하는 데 도움이 될 것입니다. CPU 사용률이 낮 으면 추가 CPU를 구입하는 것보다 상점에서 더 중요 할 수 있습니다.

실제 처리 병목 현상이있는 위치, 실제로 지불 할 수있는 위치에 투자하려고합니다. 또한 응용 프로그램 코딩 처리 효율성에서 용량에 이르기까지 모든 것을 해결함으로써 정확한 요구 사항을 파악하고 문서화 할 수 있습니다.

이제 마지막 부분은 경고이며 경고는 실제로 이것이 시작된 방식입니다. 기억? 성능 SLA가 있다는 경고를보고 WebLogic 인스턴스가 다운 된 것을 보았습니다. 경고 인터페이스를 살펴 보겠습니다. 그리고 다시, 무슨 일이야? 이 관점에서 지적하고자하는 것 중 하나는 Precise에 이러한 성능 경고 및 가용성에 대한 상태 경고가있을뿐만 아니라 추세 경고도 있다는 것입니다. 트 렌딩 경고가 중요한 이유는 시스템이 유휴 상태이거나 한두 명의 사용자가있는 경우 문제가 발생하기 때문입니다. 사용자를 추가하기 전까지는 아니고 사용자가 Tuxedo 레벨, WebLogic 레벨, 네트워크 레벨, 데이터베이스 레벨에서 데이터, 자원에 대해 경쟁하기 시작하는 점점 더 많은 활동을 시작합니다. 그리고 그 경합으로 인해 성능이 저하되고 결국에는 성능이 저하 될 수 있습니다. 기본적으로 조직의 SLA 목표를 달성하지 못하고 있습니다. 따라서 이러한 경고 세트는 매우 좋습니다.

왼쪽에있는 웹 계층은 실제로 최종 사용자 경험을 측정 한 다음 기본 응용 프로그램 스택 내의 기술을 익 힙니다. 이것은 우리가이 모든 것을 어떻게 수행하는지에 대한 일종의 건축 화면입니다. 이상적으로는 모니터링되는 환경이나 환경과 독립적 인 정확한 서버를 갖고 싶습니다. 하나의 정확한 서버는 수많은 응용 프로그램을 처리 할 수 ​​있습니다.

PeopleSoft 및 Oracle 및 DB2 데이터베이스의 경우 로컬 에이전트가 필요합니다. PeopleSoft 환경이 SQL Server에 의해 백엔드 된 경우 에이전트없는 옵션이 있습니다. 또한 Sybase에 에이전트가 없습니다. 보안 모델의 핵심은 여기에 데이터가 수집되는 반면 Precise 사용자는 Precise를 인증한다는 것입니다. 완전히 별도의 프로세스, 별도의 자격 증명, 별도의 인증 등이 보안 모델의 일부입니다. 그리고 추가 정보가 있습니다.

나는 이것이 지금까지 아키텍처에 대한 충분한 소개라고 생각합니다. 에릭이 언급 한 것처럼 불타고있는 질문이 있으면 물어보십시오.

요약하자면이 솔루션은 프로덕션 환경에서 24 x 7 용으로 설계되었습니다. 품질 관리에서 Google을 사용하는 것이 좋습니다. 사내 개발을하는 경우 개발에 우리를 사용하십시오. 복잡한 URL, URI를 PeopleSoft 패널 이름으로 변환합니다. 프로덕션에 관해 이야기 할 때, 우리는 오버 헤드가 매우 낮아 가시성을 확보하고 있으며, 현재 상황을 알고 있으며 최종 사용자를 식별하고 있습니다.

브라우저에 들어가서 정의 할 필요는 없었습니다. 브라우저, URL, 진입 점, WebLogic에 대한 웹 서버 연결, SQL 문을 제공하는 초대 컨텍스트까지의 자연스러운 연결 지점 만 있습니다. 그런 다음 SQL 문과 그 작업을 캡처 할 수 있습니다. Precise는 데이터베이스에 지능적이며 이것이 우리에게 차별화 요소이며 DBA가 협업하여 애플리케이션 가시성을 향상시킬 수 있다고 생각합니다.

마지막 요점은 우리가 항상 켜져 있고, 항상 수집하고 있기 때문에, 항상 전후에 측정하고 개선을 정량화 할 수 있으며, 드문 경우에 성능을 변경했을 수도 있습니다. 즉시 다시. 대부분의 경쟁사, 경쟁 업체는 추가 정보를 볼 필요가있는 경우 추가 가시성을 설정해야하며 일반적으로 추가 가시성으로 인해 많은 오버 헤드가 발생합니다. Precise를 사용하면 항상 가시성이 있으며 문제를 항상 해결할 수 있습니다. 따라서 Precise 웹 사이트로 이동하려면 Precise for Oracle인지 여부에 관계없이 Precise 제품을 확인하십시오. 우리는 Precise Application Performance Platform으로 표시되어 있으며 데모를 요청하는 버튼이 있습니다.

사실, 내 화면을 공유하면 화면을 탐색하여 모양이 무엇인지 보여주기 때문에 바로 볼 수 있습니다. IDERA 웹 사이트입니다. 당신은 제품에 간다. 이 Precise 구성 요소 중 하나를 선택할 수 있으며 실제로 작동하고 싶습니다. 귀하의 사이트에 중요한 추가 정보를 공유하는 과정이 시작됩니다. 유동 UI로 마이그레이션하는 것에 대해 더 알고 싶으시면 언제든지 저희에게 연락하십시오.

그리고 에릭, 나는 배턴을 당신에게 돌려주고 싶습니다.

에릭 카바나 흐 : 좋습니다. 다시 한 번 말씀 드려야합니다 – Bill. 당신은 내가 묻고 싶은 모든 것들을 언급했습니다. 우리는 시간이 많지 않습니다 – 약 9 분 – 나는 Matt에게 몇 가지 질문을 할 기회를 갖도록하고 싶습니다.

그러나 Precise가 IT 팀의 조달을 어떻게 지원할 수 있는지에 관해 매우 흥미 롭다고 생각한 것을 언급했지만, 필요한 결정이 더 견고한 상태라는 결정을 내린 사람에게 사례를 만들 수 있습니다. 예를 들어 스토리지 또는 필요한 것은 네트워크의 개선 또는 사례가 무엇이든 관계 없습니다. 그러나 그것은 큰 문제입니다. 당신은 종종 그것을 인식하고 그것을 사용하는 회사를 보십니까, 아니면 더 전도하려고합니까?

Bill Ellis : 사실 둘 다 사용 패턴은 PeopleSoft와 같은 패키지 응용 프로그램의 경우에도 사용 패턴이 사이트마다 다르다는 것입니다. 은행에서 PeopleSoft 마이그레이션을 수행 할 수 있었으며 은행은 일반 원장 시스템을 대부분의 조직과 매우 다르게 사용합니다. 실제로 지점에서 개별 트랜잭션을 수행 할 수 있으며 모두 총계정 원장에 전기됩니다.

따라서 수십 또는 수백 명의 총계정 원장을 게시하는 대신 실제로 수십만 장을 게시하는 것입니다. 그래서 제가 Precise에 참여한 방식은 사용 패턴으로 인해 해결 될 수 있었지만 코드 수준, 구성 수준 및 인프라 수준 모두에서 응용 프로그램의 요구 사항을 해결할 수있었습니다. 절대적으로 저는 큰 신자입니다. 단순히 사용률을 기준으로 하드웨어 결정을 내려서는 안되기 때문에이를 전파하고 싶습니다. 환경의 요구에 기초해야합니다.

Eric Kavanagh : 참석자로부터 질문이 있습니다 . 그리고 Matt, 질문 하나 또는 둘을 위해 당신에게 넘겨 드리겠습니다. 글쎄, 이것은 좋은 것이고 그것은 당신이 줄 수있는 크고 긴 대답이기 때문에 재밌습니다. 참석자는 다음과 같이 묻습니다. "배포 후 및 테스트 중에 사용자 끝에서 성능 지표를 어떻게 수집합니까?"

나는 당신이 그 성능 지표가 얼마나 깊고 풍성한 지에 대해 꽤 잘 다이빙했다고 생각합니다. 당신은 매 5 분 또는 10 분과 비교할 때 이들 중 일부에 대해 1 초 미만에 대해 이야기했습니다. 그때가 답을 찾는 데 필요한 세부 수준을 얻을 때입니다.

Bill Ellis : 예, 중요한 것은 성능 정보의 개별 수집가가 기술 기반이라는 것입니다. 따라서 배포를 수행 할 때 운영 체제, 해당 버전, Tuxedo 버전, WebLogic, 실행중인 People 도구 버전을 시작으로 애플리케이션 스택을 구축하는 방법에 대해 알아야합니다.

그리고 실제로이를 수행하는 에이전트의 설계입니다. 데이터 수집은 Precise가 제공하는 가시성 수준을 나타낼 수 있도록합니다. 그리고 그 가시성은 때때로 사람들에게 약간 위협이 될 수 있다고 생각합니다. 그러나 목표가 실제로 상황을 개선하고 성능을 11로 올리는 것이 목표라면 가시성 수준입니다. 그리고 Precise가이를 제공 할 수 있고 오버 헤드가 적다면 문제는 왜 그렇지 않습니까? 그래서 나는 이것이 좋은 질문이라고 생각하며, 더 논의하고 싶다면 저희에게 연락하십시오.

에릭 카바나 흐 : 좋습니다. 그리고 매트, 질문 있니?

Matt Sarrel : 괜찮을 것 같아요. 내 말은, WebEx가 여기에서 충돌하는 것을 다루었습니다.

에릭 카바나 흐 : 아뇨. 정확한 이유를 이해하려면 정확한 정보가 필요합니다.

Matt Sarrel : 네, 당신이 이야기하는 동안 내가 생각했던 질문 인 Bill은 성능 문제를 해결할 때 여러 팀이 같은 페이지에 어떻게 접근 할 수 있는지에 대해 조금 이야기 할 수있을 것입니다. 모든 사람들이 무엇을 어떻게 협력하여 직원들에게 최고의 품질을 제공 할 수 있는지를 책임지고 있습니다.

Bill Ellis : 예. IT 직원은 비싸다는 경향이 있습니다. 대부분의 상점에서는 기술의 복잡성을 고려할 때 기술에 따라 팀으로 나뉩니다. 발생하는 가장 큰 문제 중 하나는 성능 문제가 있고 전쟁이 소집되는 경우가 많다는 것입니다. 여기에는 모든 사람들이 컨텍스트를 가지고 있지 않기 때문에 자신의 계층을 확장시킬 수있는 메트릭스가 있습니다. 그들은 트랜잭션 코드 수준에서 일어나는 것이 아니라 WebLogic 수준에서 일어나는 것을보고 있습니다. 또는 트랜잭션의 개별 SQL 문이 아닌 데이터베이스 수준을보고 있습니다.

또한 해당 계층 내에서 문제 계층과 문제 코드를 정확히 파악할 수 있으므로 다른 팀이 자신의 영역 내에 있지 않은 문제를 찾기 위해 자원을 사용하거나 시간을 소비하지 않아도됩니다. 데이터베이스 문제인 경우 문제 해결에 필요한 정보를 DBA로 보내십시오. 그들은 기뻐할 것입니다.

마찬가지로 WebLogic 지원 팀인 Tuxedo를 데이터베이스의 문제에 중점을 두지 마십시오. 마찬가지로, WebLogic 구성에 문제가 발생하는 경우, 자신을 방어하려는 일종의 전쟁 실에서 DBA의 시간을 소비하지 마십시오. WebLogic에서 문제를 해결하십시오.

우리는 IT 직원이 시간 절약으로 Precise를 높이 평가합니다. 일반적으로 이러한 전시실은 각 FTE 조직의 시간 계획에 예산이 책정되어 있지 않기 때문입니다. 그것은 추가 시간과 같습니다. 따라서 이러한 문제를보다 효율적으로 처리 할 수 ​​있어야합니다. 유동적 인 UI를 도입 한 조직의 경우 프로덕션에서 확장하고 실제로 프로덕션에서 경험하는 문제를 해결할 수있는 것은 실제로 개별 직원이나 팀에게 중요한 것이 아니라 실제로 나쁜 소식 이었기 때문에 전체 IT 관리에 매우 중요했습니다. 롤백해야한다면 기술적 인 문제가 아니기 때문에 좋은 질문입니다. 그것은 항상 사람들에 관한 것입니다.

Matt Sarrel : 맞습니다. 그것은 사람과 과정입니다. 네, 데모 중에 나에게 제기 된 유일한 질문이었습니다. 청중으로부터 다른 사람이 있다면?

에릭 카바나 흐 : 네, 마지막 한 가지만하겠습니다. Bill과 Matt는 그의 프리젠 테이션에서 이것에 대해 간단히 이야기했습니다. 우리는이 작물을보기 시작했습니다. 여전히 전망 적이지만 컨테이너와 컨테이너화 및 Docker 및 그 자연의 사물을 사용하면 얼마나 큰 커브 볼이 당신을 던지나요?

Bill Ellis : 단어는 기술에 따라 다른 것을 의미합니다. 따라서 데이터베이스 수준과 응용 프로그램 수준에서 컨테이너를 관리하도록 제품을 발전시키고 있습니다. 그리고 그것의 일부로서, 그것은 움직임과 구름이있는 전체 환경의 종류이며, 우리는 구름 안에서 작동합니다. 그러나 발견 프로세스가 있으므로 PeopleSoft를 포함한 이러한 응용 프로그램이 어떻게 발전하고 있는지에 따라 모니터링 솔루션을 발전시켜 과거에 매우 귀중한 수준의 깊이를 제공 할 수 있습니다.

에릭 카바나 : 네. 그리고 저는이 데모를 볼 때마다 여러분이 가지고있는 세분성에 놀랐습니다. 그리고 그것은 당신이 이해를 함께 쌓을 수 있어야하고 정상적인 상황에 대해 약간의 교육을 받아야하는 것입니다. 표준은 무엇입니까?

그리고 사람들은 그 주변에 많은 콘텐츠를 제공하여 사람들이 정상적인 것이 아닌 것을 식별하도록 도와줍니다. 예를 들어, 경향 경고에 대해 이야기했습니다. 예를 들어, 이것들은 잘못된 것, 잘못된 것이 아닌 것을 이해하기 위해 사용할 수있는 모든 메커니즘입니다. 물론 그것을 찾기 위해 드릴 다운해야하지만 모든 데이터가 있습니다.

빌 엘리스 : 네, 정말 중요한 일입니다. 나는 매트가 그것에 대해 이야기했다고 생각합니다. 정상은 무엇입니까? 다른 환경에는 다른 수준의 정상이 있습니다. 고급 하드웨어, Oracle 로직 및 데이터를 사용하는 경우, 상점에서 정상적이거나 상점에서 달성 할 수있는 것이 덜 강력한 인프라에서 실행하는 경우와 다를 수 있습니다. 첫 번째로, 무엇이 정상인지 알아 내고, 그 기준을 계산하기 시작하면 거기서부터 개선을 시작할 수 있습니다.

Eric Kavanagh : 좋습니다. 좋은 지적입니다. 마지막 질문이 하나 있습니다. 마지막 질문 하나만 빌릴 게 시스템 수준 및 응용 프로그램 수준 데이터의 관점에서 SQL과 데이터베이스 성능 모니터링의 차이점은 무엇입니까? 관점에서 SQL과 데이터베이스 성능 모니터링의 차이점은 무엇입니까?

Bill Ellis : 음, SQL 문이 실행될 때까지 데이터베이스에서 아무 일도 일어나지 않습니다. SQL 문 경합은 데이터 수준 및 SQL Server 수준에서 리소스 잠금, 대기, 리소스 경합을 제어합니다. 따라서 SQL 문의 드라이버와 시스템에 미치는 영향을 모두 볼 수 있다면 영향을 미쳤습니다. 정확한 도구를 최대한 활용할 수있을 때까지 응용 프로그램 DBA가 관심 사항과 인프라 DBA가 관심 사항을 연결할 수 있습니다.

내가 인프라 DBA이고 활용률과 같은 것을보고 있다면, 실제로는 개별적인 SQL 문을 볼 수 있고 실제로 리소스를 최소화 할 수 있는지에 비해 광범위한 브러시로 관리하는 것입니다. 소비 – CPU, 메모리, I / O 여부 – 동일한 동전의 양면을 처리 할 수 ​​있습니다.

에릭 카바나 흐 : 좋습니다. 우리는 한 시간 이상 타버 렸습니다. IDERA의 친구들에게 감사합니다. 오늘 우리와 함께 해주신 Matt Sarrel에게 큰 감사를드립니다. 우리는 나중에 볼 수 있도록 이러한 모든 웹 캐스트를 보관하므로 언제든지 돌아와서 보통 몇 시간 안에 보관소가 올라갑니다. 제가 확인해야 할 것은이 물건을 좋아한다는 것입니다. 저는 정확한 것을 좋아하고 잡초에 들어갈 수있는 것을 좋아합니다. 그리고 저는 여러분이 IDERA와 Precise가 가지고있는 것보다 애플리케이션 스택의 모든 다른 부분과 부분을 파헤칠 수있는 다른 도구를 모릅니다.

그걸로 우리는 작별 인사를합니다. 다시 한 번 감사드립니다. 다음에 연락 드리겠습니다.