Bởi nhân viên Techopedia, ngày 2 tháng 11 năm 2016
Takeaway: Người dẫn chương trình Eric Kavanagh thảo luận về hiệu suất ứng dụng và cách cải thiện hiệu quả với Tiến sĩ Robin Bloor, Dez Blanchfield và IDERA của Bill Ellis.
Bạn hiện chưa đăng nhập. Vui lòng đăng nhập hoặc đăng ký để xem video.
Eric Kavanagh: Thưa quý vị và các bạn, xin chào và chào mừng bạn quay trở lại Hot Technologies. Vâng thực sự! Tên tôi là Eric Kavanagh, tôi sẽ là người dẫn chương trình của bạn cho một webcast khác ngày hôm nay trong loạt thực sự thú vị, thú vị này, chúng tôi đã nhận được như một lời khen cho loạt Phòng họp của chúng tôi. Tiêu đề là Tăng tốc ứng dụng: Hiệu suất nhanh hơn cho người dùng cuối. Hãy đến với mọi người, ai không muốn điều đó? Nếu tôi là người ngoài kia giúp ứng dụng của bạn chạy nhanh hơn, tôi nghĩ tôi là người được mua bia cho tôi tại quán bar sau giờ làm việc. Đó là một điều khá tuyệt vời để bước vào và tăng tốc ứng dụng của bất kỳ ai.
Có một slide về bạn thật sự, đánh tôi lên Twitter @Eric_Kavanagh. Tôi luôn cố gắng theo dõi lại và tôi luôn tweet lại nếu bạn đề cập đến tôi, vì vậy hãy thoải mái đề cập đến tôi.
Toàn bộ mục đích của chương trình này là tập trung vào các khía cạnh khác nhau của công nghệ doanh nghiệp và thực sự giúp xác định một số ngành hoặc khuôn mặt nhất định, nếu bạn muốn. Rất nhiều lần các nhà cung cấp sẽ chọn các thuật ngữ tiếp thị nhất định và nói về cách họ làm điều này hoặc điều kia hoặc một số điều khác. Chương trình này thực sự được thiết kế để giúp khán giả của chúng tôi hiểu những gì một công cụ phần mềm cần phải có để trở thành người dẫn đầu trong không gian của nó. Các định dạng của đây là hai nhà phân tích. Mỗi lần đi trước, không giống như Phòng Tóm tắt nơi nhà cung cấp đi trước. Mỗi người đưa ra những gì họ nghĩ là quan trọng để bạn biết về một loại công nghệ cụ thể.
Hôm nay chúng ta đang nói về tăng tốc ứng dụng. Chúng ta sẽ được nghe từ Dez Blanchfield và cả Bác sĩ Robin Bloor - chúng ta ở khắp nơi trên thế giới ngày hôm nay - và sau đó Bill Ellis đang quay số từ khu vực Virginia rộng lớn hơn. Với điều đó, tôi sẽ trao nó cho người dẫn chương trình đầu tiên của chúng tôi, Tiến sĩ Bloor. Chúng tôi đã tweet hashtag của #podcast bằng cách này, vì vậy hãy thoải mái để tweet. Mang nó đi.
Tiến sĩ Robin Bloor: Được rồi, cảm ơn vì lời giới thiệu đó. Hiệu suất ứng dụng và mức độ dịch vụ - đây là một loại lĩnh vực, tôi đã thực hiện rất nhiều công việc trong lĩnh vực này trong nhiều năm qua, theo nghĩa là tôi thực sự đã làm rất nhiều công việc trong việc giám sát hiệu suất và làm việc trong một cách này hay cách khác, làm thế nào để thử và tính các cấp độ đó. Phải nói rằng cho đến khi - chúng ta đã từng có thời đại này, cách đây một thời gian, nơi con người xây dựng các hệ thống trong silo. Về cơ bản, khối lượng công việc họ thực sự phải làm để làm cho một hệ thống hoạt động tốt một cách hợp lý nếu nó ở trong một silo không thực sự quá khó vì có rất ít, rất ít các biến bạn phải xem xét. Ngay sau khi chúng tôi kết nối đúng cách, định hướng tương tác và dịch vụ đã đi vào phương trình. Nó có một chút khó khăn. Hiệu suất có thể là một chiều. Nếu bạn chỉ nghĩ về một ứng dụng thực thi một đường dẫn mã cụ thể nhiều lần, thực hiện nó một cách hợp lý, kịp thời, sẽ cảm thấy giống như một thứ một chiều. Ngay khi bạn bắt đầu nói về các cấp độ dịch vụ, bạn thực sự đang nói về nhiều thứ cạnh tranh tài nguyên máy tính. Nó trở nên đa chiều rất nhanh. Nếu bạn bắt đầu nói về các quy trình kinh doanh, các quy trình kinh doanh có thể được xâu chuỗi lại với nhau từ nhiều ứng dụng. Nếu bạn đang nói về kiến trúc hướng dịch vụ, thì một ứng dụng nhất định thực sự có thể truy cập vào khả năng của nhiều ứng dụng. Sau đó, nó trở thành một điều rất phức tạp.
Tôi nhìn vào - lâu rồi, tôi đã vẽ sơ đồ này. Sơ đồ này ít nhất 20 tuổi. Về cơ bản, tôi gọi nó là Sơ đồ của mọi thứ vì đó là cách để xem xét mọi thứ tồn tại trong môi trường CNTT. Nó thực sự chỉ có bốn phần: người dùng, dữ liệu, phần mềm và phần cứng. Tất nhiên chúng thay đổi theo thời gian, nhưng bạn thực sự nhận ra khi bạn nhìn vào điều này rằng có một sự bùng nổ phân cấp của từng một trong những mảnh này. Một phần cứng có, phần cứng có thể là một máy chủ nhưng một máy chủ bao gồm nhiều CPU, công nghệ mạng và bộ nhớ, và điều này, rất nhiều bộ điều khiển khủng khiếp, như nó xảy ra. Nếu bạn thực sự nhìn vào điều này, tất cả sẽ vỡ thành nhiều mảnh. Nếu bạn thực sự nghĩ về việc cố gắng sắp xếp tất cả những điều đó, liên quan đến dữ liệu thay đổi, hiệu suất của phần mềm thay đổi, vì phần cứng thay đổi, v.v., bạn thực sự đang nhìn vào một tình huống đa biến cực kỳ khó khăn. Đây là đường cong phức tạp. Tất nhiên đó là đường cong phức tạp cho mọi thứ, nhưng tôi đã thấy nó bị thu hút hết lần này đến lần khác khi nói về máy tính. Về cơ bản, nếu bạn đặt các nút trên một trục và các kết nối quan trọng trên trục kia, bạn sẽ có một đường cong phức tạp. Hầu như không có vấn đề gì về các nút và kết nối là gì và điều đó sẽ làm nếu bạn muốn đại diện cho sự tăng trưởng âm lượng trong mạng điện thoại.
Trong thực tế, khi nói về các nút trong môi trường máy tính, bạn đang nói về những điều riêng lẻ quan tâm đến nhau. Sự phức tạp, hóa ra là, một vấn đề về cấu trúc đa dạng và các ràng buộc khác nhau mà bạn đang cố gắng tuân theo. Ngoài ra, những con số. Khi những con số tăng lên, họ phát điên. Tôi đã có một cuộc trò chuyện thú vị ngày hôm qua, tôi đã nói chuyện với ai đó - tôi không thể đề cập đến anh ấy là ai, nhưng điều đó không thực sự quan trọng - họ đang nói về một trang web có 40.000 - đó là bốn, 40.000 - cơ sở dữ liệu Trong trang web. Chỉ cần nghĩ về điều đó - 40.000 cơ sở dữ liệu khác nhau. Tất nhiên là thứ duy nhất chúng tôi có - rõ ràng là chúng có rất nhiều, hàng ngàn ứng dụng. Chúng ta đang nói về một tổ chức rất lớn, nhưng tôi không thể đặt tên cho nó. Bạn thực sự nhìn vào điều đó, và bạn thực sự đang cố gắng, bằng cách này hay cách khác, có được các mức dịch vụ sẽ phù hợp trên nhiều bảng cho nhiều người dùng, với nhiều kỳ vọng khác nhau, nếu bạn muốn, mong đợi. Đó là một tình huống phức tạp, và tất cả những gì tôi thực sự nói là, thứ này phức tạp. Con số luôn tăng. Các ràng buộc được xác định bởi các quy trình kinh doanh và mục tiêu kinh doanh. Bạn sẽ nhận thấy sự thay đổi kỳ vọng.
Tôi nhớ ngay khi Gmail và Yahoo mail và Hotmail, tất cả các hệ thống thư đó xuất hiện, mọi người bắt đầu kỳ vọng hệ thống thư nội bộ của họ trong tổ chức sẽ xứng đáng với mức độ dịch vụ của các hoạt động khổng lồ này với các trang trại máy chủ rộng lớn bên ngoài tổ chức và bắt đầu bị áp lực để làm cho tất cả những điều đó xảy ra. Trên thực tế, thỏa thuận cấp độ dịch vụ là một chuyện, nhưng kỳ vọng là một điều khác và họ chiến đấu với nhau trong một tổ chức, một điều khó xử. Đây chỉ là một quan điểm kinh doanh. Trong một số hệ thống, thời gian phản hồi tối ưu là một phần mười giây của thời gian phản hồi của con người. Một phần mười giây là thời gian con rắn hổ mang cắn bạn. Nếu bạn đứng trước một con rắn hổ mang và nó quyết định cắn bạn, thì đã quá muộn, điều đó sẽ xảy ra bởi vì bạn không thể trả lời trong một phần mười giây. Một phần mười giây là khoảng thời gian để bóng rời khỏi tay người ném bóng để tiếp cận anh chàng với con dơi. Về cơ bản, khi anh ta nhìn thấy quả bóng ném, anh ta phải trả lời đúng vào thời điểm đó. Phản ứng của con người, một loại điều thú vị. Phần mềm-phần mềm, rõ ràng có thể có một kỳ vọng cao hơn.
Sau đó, bạn gặp phải một số tình huống mà tôi nghĩ là những tình huống thị trường, trong đó đầu tiên là giá trị kinh doanh. Điều này giống như nếu bạn muốn bán một cổ phiếu cụ thể trên thị trường chứng khoán có lẽ ít hơn, chẳng hạn, bởi vì bạn nghĩ rằng nó sẽ giảm và nhiều người khác nghĩ rằng nó sẽ giảm, bạn sẽ có được giá tốt nhất nếu bạn tiếp cận thị trường trước. Có rất nhiều tình huống, phục vụ quảng cáo và những thứ tương tự, tình huống rất giống nhau. Bạn đã có phong trào này về kỳ vọng cấp dịch vụ. Bạn đã có một điều đó là một loại trần thủy tinh cho phản ứng của con người. Khi đã là phần mềm thành phần mềm, nếu bạn gặp tình huống trần này, thì không có mức dịch vụ tốt nhất. Nhanh hơn mọi người khác là tốt nhất.
Được rồi, đây là, tôi nghĩ, slide cuối cùng mà tôi đang làm, nhưng đây chỉ là để cung cấp cho bạn một bức tranh lớn về sự phức tạp, một khi bạn thực sự nhìn vào yêu cầu của một tổ chức, dịch vụ. Bạn đã có, đi lên phía bên trái ở đây, bạn có quản lý hệ thống, đó là một bộ phần mềm phục vụ cho việc quản lý dịch vụ, đang cố gắng quản lý cấp độ dịch vụ. Ở trên bạn đã có quản lý hiệu quả kinh doanh. Sau đó, nếu bạn nhìn xuống phía dưới, khu vực tự động hóa quản lý dịch vụ, bạn đã có các dịch vụ phân mảnh phát triển thành các dịch vụ được tiêu chuẩn hóa, nếu bạn thực sự quan tâm đầu tư vào loại hình này, phát triển thành các dịch vụ tích hợp, phát triển thành các dịch vụ được tối ưu hóa . Hầu hết những gì mọi người đã làm là, chỉ ở góc dưới bên trái của điều này. Có thể một chút quản lý dịch vụ. Quản lý hiệu quả kinh doanh, rất hiếm. Phân mảnh, gần như tất cả. Một thế giới hoàn hảo sẽ lấp đầy lưới điện đó. Thiết bị đo đạc - Tôi đã đề cập đến một vấn đề tối ưu hóa phụ. Bạn có thể tối ưu hóa các bộ phận của một hệ thống và nó không tốt cho toàn bộ hệ thống. Nếu bạn làm cho tim tối ưu, thì máu của bạn có thể lưu thông quá nhanh đối với các cơ quan còn lại. Đó là một vấn đề với các tổ chức và cấp độ dịch vụ lớn. Rõ ràng không có gì sẽ đạt được nếu không có các công cụ tinh vi bởi vì các biến đã nhận được - cũng có quá nhiều biến để thử và tối ưu hóa.
Có nói rằng, tôi sẽ chuyển cho Dez, người sẽ nói về điều gì đó hoàn toàn khác, hy vọng.
Dez Blanchfield: Cảm ơn bạn, Robin. Giống như Tiến sĩ Robin Bloor, tôi đã dành quá nhiều năm để suy nghĩ về hiệu suất của các hệ thống rất phức tạp ở quy mô rất lớn. Có lẽ không hoàn toàn giống với quy mô của Robin, nhưng hiệu suất là một chủ đề hàng ngày và đó là một phần trong DNA của chúng tôi muốn có hiệu suất, để tận dụng tốt nhất mọi thứ. Trên thực tế, tôi đã sử dụng một hình ảnh về một trong những điều yêu thích của tôi trên thế giới, đua xe Công thức I, trong đó toàn bộ hành tinh ngồi yên một lúc và xem những chiếc xe đi vòng tròn rất nhanh. Mỗi khía cạnh, không có khía cạnh nào của Công thức I mà không đặc biệt là về hiệu suất. Rất nhiều người thích chơi thể thao vì họ nghĩ rằng đó là một sự lãng phí tiền bạc. Hóa ra chiếc xe chúng ta lái mỗi ngày để thả bọn trẻ vào bóng đá vào cuối tuần và đi học vào những ngày khác, bắt nguồn từ nghiên cứu và phát triển dựa trên hiệu suất. Đó là cuộc sống của đua xe Công thức I. Công nghệ hàng ngày, khoa học hàng ngày, thường xuất phát từ việc thích một thứ gì đó được tập trung hoàn toàn vào hiệu suất cao.
Tuy nhiên, thực tế là thế giới "luôn luôn" mới của chúng ta, đòi hỏi 100% thời gian hoạt động - như Robin đã đề cập trước đó - với những thứ như giới thiệu webmail và các dịch vụ khác mà chúng ta đã được cấp trong không gian liên tục, và bây giờ chúng ta mong đợi rằng doanh nghiệp và môi trường làm việc của chúng tôi. Thực tế là không phải lúc nào cũng có nghĩa là bạn đang đáp ứng thỏa thuận cấp dịch vụ. Tôi có nhu cầu quản lý hiệu suất ứng dụng và các thỏa thuận cấp độ dịch vụ sẵn có đã trải qua một sự thay đổi cơ bản trong thập kỷ qua. Chúng tôi không chỉ cố gắng lo lắng về hiệu suất của một hệ thống nữa. Khi thế giới đơn giản hơn một chút, chúng ta có thể gặp tình huống một máy chủ duy nhất chạy nhiều dịch vụ có thể được giám sát trực tiếp và việc hỗ trợ tương đối đơn giản. Chúng tôi có thể - và đây là nhỏ của tôi, những điều chúng tôi từng lo lắng khi tôi là quản trị viên hệ thống, ví dụ, nhiều năm trước - chúng tôi sẽ xem xét xung quanh, dịch vụ có thường xuyên phản hồi không? Tôi có thể đăng nhập vào một thiết bị đầu cuối chẳng hạn? Là hệ điều hành đáp ứng và tôi có thể gõ lệnh? Các ứng dụng đang hoạt động? Tôi có thể thấy các quy trình và bộ nhớ khi thực hiện mọi thứ và I / O trên mạng không? Trong những ngày máy tính lớn, bạn có thể nghe thấy băng từ zip-zip-zip và giấy rơi ra khỏi chúng.
Các ứng dụng có phản hồi không và chúng ta có thể đăng nhập và thực hiện mọi thứ trên chúng không? Người dùng có thể kết nối với một số máy chủ đó không? Nó tiếp tục. Chúng khá cơ bản, bạn biết đấy. Sau đó, một vài cái buồn cười - là bàn trợ giúp màu xanh lá cây? Bởi vì nếu không, mọi thứ sẽ ổn, và ai sẽ nhận được bánh rán? Cuộc sống thực sự đơn giản trong những ngày đó. Ngay cả trong những ngày đó, và sau đó tôi đang nói chuyện với 20 trận30 năm trước, độ phức tạp vẫn rất cao. Chúng ta có thể, theo cách tương đối đơn giản, quản lý các thỏa thuận cấp dịch vụ và để mắt đến hiệu suất. Chúng ta không thể làm điều đó bằng tay nữa, như Robin đã ám chỉ. Thử thách quá lớn. Thực tế là thời điểm mà một vài ứng dụng, quản trị viên, mạng hệ thống và cơ sở dữ liệu tốt, quản trị viên có thể giám sát và đáp ứng SLA hiệu suất. SLA đã đi quá xa đến nỗi tôi đã vật lộn tối qua khi tôi đặt các ghi chú cuối cùng của mình để thậm chí nghĩ về năm cuối cùng tôi nhìn vào một hệ thống của một ngăn xếp rất phức tạp, và hiểu ý nghĩa của nó và thậm chí hiểu được những gì diễn ra dưới mui xe, và tôi đến từ một nền tảng kỹ thuật sâu sắc. Tôi không thể tưởng tượng những gì nó muốn đối mặt với điều đó hàng ngày bây giờ theo kiểu hành chính.
Chuyện gì đã xảy ra? Vâng, vào năm 1996, các ứng dụng điều khiển cơ sở dữ liệu đã được chuyển đổi với sự bùng nổ của internet. Rất nhiều người trong chúng ta đã trải qua điều đó. Ngay cả khi bạn không có sự bùng nổ về internet, bạn có thể dễ dàng nhìn xung quanh và nhận ra rằng trong cuộc sống hàng ngày, chúng ta sẽ kết nối mọi thứ với internet ngay bây giờ. Tôi tin rằng chúng tôi đã có một máy nướng bánh mì dường như đi kèm với tùy chọn để truy cập Wi-Fi, điều này thật vô lý, vì tôi không cần máy nướng bánh mì của tôi kết nối với internet. Trong những năm 2000, đặc biệt là đầu những năm 2000, chúng ta đã phải đối phó với sự tăng trưởng lớn này trong vòng phức tạp cung cấp hiệu suất dịch vụ trong thời kỳ bùng nổ dot-com. Sau đó, một tia sáng lúng túng kỳ cục khác trong web 2.0, nơi điện thoại thông minh xuất hiện và bây giờ các ứng dụng đã ở trong tay chúng tôi 24/7 và luôn ở chế độ bật.
Bây giờ là năm 2016, chúng ta phải đối mặt với một vũng lầy khác dưới dạng đám mây và dữ liệu lớn và tính di động. Đây là những hệ thống chỉ lớn đến mức chúng thường khó hiểu và đặt bằng tiếng Anh. Khi chúng ta nghĩ về thực tế là một số kỳ lân lớn mà chúng ta nói đến có hàng chục hàng trăm petabyte dữ liệu. Đây là toàn bộ không gian đĩa và bộ lưu trữ chỉ để giữ email, hình ảnh và phương tiện truyền thông xã hội của bạn. Hoặc trong một số trường hợp, trong vận chuyển và vận chuyển hậu cần, tất cả đều thuộc về ngân hàng, đó là tiền của bạn ở đâu, hoặc bài đăng của bạn, hoặc của bạn, nơi bạn mua thứ gì trên eBay. Làn sóng lớn tiếp theo mà chúng ta sắp phải đối mặt là thách thức rất lớn này của internet về mọi thứ.
Nếu điều này không đủ tệ, chúng ta sẽ xây dựng trí tuệ nhân tạo và điện toán nhận thức vào mọi thứ. Chúng tôi nói chuyện với Siri và Google engine những ngày này. Tôi biết Amazon có một cái riêng. Baidu có một trong những thiết bị mà bạn có thể nói chuyện, họ chuyển đổi nó thành văn bản đi vào một hệ thống bình thường, cơ sở dữ liệu tạo một truy vấn và quay lại và đảo ngược quá trình. Hãy suy nghĩ về sự phức tạp đi vào đó. Thực tế là sự phức tạp của ngăn xếp ứng dụng tiêu chuẩn ngày nay vượt xa khả năng của con người. Khi bạn nghĩ về mọi thứ xảy ra khi bạn nhấn nút trên thiết bị điện thoại thông minh hoặc máy tính bảng của mình, bạn sẽ nói chuyện với nó, chuyển đổi nó thành văn bản, chạy toàn bộ internet sang hệ thống back-end, mặt trước nhận được rằng, chuyển đổi nó thành truy vấn, chạy truy vấn thông qua ngăn xếp ứng dụng, đi qua cơ sở dữ liệu, nhấn đĩa, quay trở lại và ở giữa có một mạng di động, có một trung tâm trạng thái mạng cục bộ. Sự phức tạp là điên rồ.
Chúng tôi khẳng định một cách hiệu quả điều này như là siêu cường điệu. Sự phức tạp và tốc độ của siêu âm chỉ là tưới mắt. Các ứng dụng và cơ sở dữ liệu đã trở nên quá lớn và phức tạp, đến nỗi việc quản lý hiệu suất thực tế là một khoa học. Nhiều người coi nó như một khoa học tên lửa. Chúng tôi có công nghệ tại chỗ, chúng tôi có công nghệ ngoại vi, chúng tôi có một loạt các tùy chọn trung tâm dữ liệu; vật lý và ảo. Chúng ta đã có máy chủ vật lý và ảo, chúng ta có đám mây, chúng ta có cơ sở hạ tầng như một dịch vụ và nền tảng như một dịch vụ và phần mềm như một dịch vụ là điều chúng ta coi là điều hiển nhiên. Sau này, phần mềm như một dịch vụ, đã trở nên đáng sợ trong một vài năm trước đây khi các giám đốc tài chính và các bộ phận của tổ chức nhận ra rằng họ có thể lấy thẻ tín dụng của họ và chỉ cần mua đồ và đi xung quanh CIO và chúng tôi gọi đây là bóng tối Bây giờ IT IT và các CIO cố gắng điều chỉnh lại và kiểm soát vật lộn trở lại.
Trong cơ sở hạ tầng, chúng tôi có mạng được xác định bằng phần mềm, ảo hóa chức năng mạng, dưới mức mà chúng tôi có, giờ đây, chúng tôi đã có các dịch vụ vi mô và ứng dụng của các dịch vụ đang hoạt động. Khi bạn nhấp vào một URL, có một loạt logic nghiệp vụ nằm ở cuối URL đó mô tả những gì nó cần để thực sự phân phối nó. Nó không nhất thiết phải có logic dựng sẵn đang chờ nó. Chúng tôi đã có cơ sở dữ liệu truyền thống ở một bên đang mở rộng rất, rất lớn. Chúng ta đã có cơ sở hạ tầng và hệ sinh thái Hadoop ở phổ khác chỉ lớn đến mức, như tôi đã nói, mọi người đang nói về hàng trăm petabyte dữ liệu hiện nay. Chúng tôi đã có tính di động phức tạp cho đến khi các thiết bị mang theo bên mình, máy tính xách tay và điện thoại và máy tính bảng.
Chúng tôi đã có BYOD trong một số môi trường kín và ngày càng nhiều hơn, vì những người có kinh nghiệm về Gen Y đang mang các thiết bị của riêng họ. Chúng tôi chỉ để họ nói chuyện với họ về giao diện web. Qua internet hoặc qua Wi-Fi, chúng tôi có Wi-Fi miễn phí trong quán cà phê ở tầng dưới khi họ đang uống cà phê. Hoặc Wi-Fi nội bộ của chúng tôi. Máy-to-machine là luôn luôn hiện nay. Đó không phải là một phần trực tiếp của internet, nhưng nó cũng liên quan. Internet vạn vật là một trò chơi hoàn toàn mới về sự phức tạp khiến tâm trí không thể tin được. Trí thông minh nhân tạo và nếu bạn nghĩ rằng những gì chúng ta đang chơi bây giờ, với tất cả các Siri và các thiết bị liên quan khác mà chúng ta nói đến đều phức tạp, hãy đợi cho đến khi bạn gặp tình huống mà bạn thấy một thứ gọi là Olli là 3-D xe buýt in có khoảng sáu người và có thể tự lái vòng quanh thành phố và bạn có thể nói tiếng Anh đơn giản với nó, và nó sẽ nói lại với bạn. Nếu nó chạm vào giao thông, nó sẽ quyết định rẽ trái hoặc phải khỏi khu vực chính nơi có giao thông. Khi nó rẽ và bạn lo lắng về lý do tại sao nó rẽ trái hoặc phải ra khỏi đường chính, nó sẽ nói với bạn, đừng đừng lo lắng, tôi sắp rẽ trái. Có lưu lượng truy cập phía trước và tôi sẽ đi xung quanh nó.
Quản lý hiệu suất của tất cả các hệ thống trong đó và tất cả sự phức tạp, theo dõi dữ liệu đó đi đâu, cho dù nó đi vào cơ sở dữ liệu, tất cả các kết nối và tất cả các bit có liên quan chỉ là tâm trí. Thực tế là việc quản lý hiệu suất và SLA ở tốc độ và quy mô ngày nay đòi hỏi phải có các công cụ và hệ thống, và theo mặc định, đây không còn là điều mà bạn nghĩ rằng sẽ rất tốt nếu có một công cụ - đó là điều kiện tiên quyết; nó là hoàn toàn cần thiết Đây là một ví dụ nhỏ, một danh sách các sơ đồ thiết kế ứng dụng cấp cao cho OpenStack, đám mây được xác định bằng phần mềm nguồn mở. Đây chỉ là một khúc lớn. Đây không chỉ là máy chủ và cơ sở dữ liệu. Đây là nơi mỗi đốm màu xanh nhỏ tượng trưng cho các cụm sự vật. Trong một số trường hợp, tệp và máy chủ hoặc hàng trăm cơ sở dữ liệu hoặc tất nhiên không quá hàng chục nghìn mẩu ứng dụng logic đang chạy. Đó là một phiên bản nhỏ. Nó thực sự khá phiền khi bạn bắt đầu nghĩ về sự phức tạp xảy ra trong việc này. Ngày nay, ngay cả trong không gian dữ liệu lớn, tôi sẽ chỉ đưa một số ảnh chụp màn hình của các thương hiệu. Khi bạn nghĩ về tất cả các phần chúng tôi phải quản lý ở đây, chúng tôi không chỉ nói về một thương hiệu nhất thiết, đây là tất cả các thương hiệu trong bối cảnh dữ liệu lớn và thương hiệu hàng đầu, không chỉ mỗi một nguồn nhỏ hoặc nguồn mở. Bạn nhìn và bạn nghĩ rằng đó là một biểu đồ khá khó hiểu.
Chúng ta hãy nhìn vào một vài chiều dọc. Hãy lấy ví dụ về tiếp thị. Đây là một biểu đồ tương tự nhưng chỉ từ các ngăn xếp công nghệ có sẵn trong công nghệ tiếp thị. Đây là biểu đồ năm 2011. Đây là phiên bản 2016. Chỉ cần nghĩ về, đây chỉ là số lượng thương hiệu sản phẩm bạn có thể chạy cho công nghệ liên quan đến công nghệ tiếp thị. Không phải sự phức tạp của các hệ thống bên trong đó, không phải là ứng dụng và web và phát triển và mạng khác nhau và tất cả các hệ thống khác. Chỉ là thương hiệu. Có trước đây, năm năm trước và đây là ngày hôm nay. Nó sẽ chỉ trở nên tồi tệ hơn. Hiện tại chúng ta đang ở đâu trong thực tế, con người đơn giản là không thể đảm bảo tất cả các thỏa thuận cấp dịch vụ. Chúng ta không thể đi sâu vào đủ chi tiết, đủ nhanh và ở quy mô chúng ta cần. Đây là một ví dụ về giao diện điều khiển giám sát bây giờ. Điều này giống như gần hai mươi màn hình kỳ lạ dán vào nhau giả vờ rằng chúng là một màn hình lớn, được chiếu theo dõi từng mảnh nhỏ. Bây giờ thật thú vị ở đây, tôi sẽ không đề cập đến thương hiệu, nhưng nền tảng giám sát này đang giám sát một ứng dụng duy nhất trong môi trường hậu cần và vận chuyển. Chỉ cần một ứng dụng. Nếu bạn nghĩ về những gì Robin đã nói về nơi các tổ chức có thể có 40.000 cơ sở dữ liệu hiện nay trong môi trường sản xuất. Bạn có thể hình dung 40.000 phiên bản của bộ sưu tập màn hình theo dõi một ứng dụng này có thể như thế nào không? Đó là một thế giới rất dũng cảm mà chúng ta đang sống. Như Robin đã nói và tôi sẽ hoàn toàn, 100% lặp lại rằng, không có công cụ phù hợp, không có sự hỗ trợ và dân gian đúng đắn trên bàn bằng những công cụ đó, hiệu suất ứng dụng là một trò chơi bị mất đối với con người và nó phải được thực hiện bằng các công cụ và phần mềm.
Với điều đó tôi sẽ chuyển cho bạn bè của chúng tôi trong IDERA.
Eric Kavanagh: Được rồi, Bill.
Bill Ellis: Cảm ơn bạn. Chia sẻ ra màn hình của tôi ở đây. Tôi đoán ai đó có thể xác nhận rằng bạn có thể thấy màn hình của tôi?
Tiến sĩ Robin Bloor: Vâng.
Eric Kavanagh: Có vẻ ổn cả.
Bill Ellis: Cảm ơn bạn. Một điều anh ấy nhắc đến là, tôi thực sự không thể chờ đợi là chiếc xe tự lái. Một điều mà tôi chưa từng nghe ai nói đến là, chuyện gì sẽ xảy ra khi tuyết rơi? Tôi tự hỏi liệu các kỹ sư ở California có nhận ra rằng ở các vùng khác của đất nước, tuyết rơi khá nhiều.
Dez Blanchfield: Tôi thích điều đó, tôi sẽ nhớ điều đó.
Eric Kavanagh: Một dặm một giờ điển hình.
Bill Ellis: Chúng tôi ở đây để nói về quản lý hiệu suất ứng dụng trong một môi trường phức tạp. Một điều tôi muốn nói là, rất nhiều người, khi họ nói về hiệu suất, bản chất của phản ứng là, nhiều máy chủ hơn, nhiều CPU hơn, nhiều bộ nhớ hơn, v.v … Mặt khác của đồng tiền đó là hiệu quả xử lý. Thực sự, đó là hai mặt của cùng một đồng tiền và chúng ta sẽ xem xét cả hai. Mục tiêu cuối cùng là đáp ứng các thỏa thuận cấp độ dịch vụ cho các giao dịch kinh doanh. Cuối cùng tất cả các công nghệ này tồn tại cho doanh nghiệp. Chúng tôi đã nói về việc có một cơ sở dữ liệu quản lý hiệu suất đầu tiên trong ngành. Lý tưởng của điều đó là phù hợp với khuôn mẫu lý tưởng của hiệu năng và quản lý nó từ đầu vòng đời ứng dụng.
Các chủ đề thực sự sôi xuống đến bốn mảnh; một là quá trình quản lý hiệu suất. Chúng tôi đã nói chuyện với mọi người, và mọi người đều có công cụ. Nếu họ không có công cụ, họ có tập lệnh hoặc lệnh, nhưng cái họ thiếu là bối cảnh. Bối cảnh chỉ đơn giản là kết nối các dấu chấm trên ngăn xếp ứng dụng. Các ứng dụng này cho - dựa trên trình duyệt. Chúng được ghép rất chặt chẽ từ tầng này sang tầng khác. Làm thế nào các tầng tương tác cũng rất quan trọng. Sau đó, chúng ta đang nói về giao dịch kinh doanh. Chúng tôi sẽ cung cấp khả năng hiển thị không chỉ cho dân kỹ thuật mà còn cho các chủ sở hữu ứng dụng và người quản lý hoạt động.
Tôi có một vài nghiên cứu trường hợp để chia sẻ với bạn về cách khách hàng sử dụng chúng. Đây là một phần rất thực tế của bài trình bày ở đây. Chúng ta hãy xem những gì thường xảy ra. Tôi thích sơ đồ - nó giống như một ảnh ghép đáng kinh ngạc của các công nghệ. Số lượng công nghệ trong trung tâm dữ liệu vừa phát triển, vừa phát triển và phát triển. Trong khi đó, một người dùng cuối không quan tâm đến nó và không biết gì về nó. Họ chỉ muốn thực hiện giao dịch, có sẵn, hoàn thành nhanh chóng. Điều thường xảy ra là, các chuyên gia về CNTT không biết rằng người dùng cuối thậm chí có vấn đề, cho đến khi họ tự báo cáo. Điều đó khởi đầu cho một quá trình tốn thời gian, chậm và thường gây nản lòng. Điều gì xảy ra là, mọi người sẽ mở ra các công cụ của họ và họ nhìn vào một tập hợp con của ngăn xếp ứng dụng của họ. Với tập hợp con đó, việc trả lời câu hỏi đơn giản nhất trở nên rất khó khăn. Có phải bình thường bạn có vấn đề? Giao dịch là gì? Trường hợp trong ngăn xếp ứng dụng là nút cổ chai? Bằng cách dành tất cả thời gian này, tìm kiếm từng tầng một, không thể trả lời những câu hỏi này, cuối cùng bạn đã dành rất nhiều thời gian và năng lượng, rất nhiều nhân viên, quỹ và loại năng lượng để tìm hiểu.
Để giải quyết vấn đề này, để cung cấp một cách tốt hơn, những gì Chính xác thực sự là thực hiện giao dịch theo dõi người dùng cuối, nắm bắt siêu dữ liệu về nó, theo dõi giao dịch qua mạng, vào máy chủ web, vào tầng logic nghiệp vụ và chúng tôi hỗ trợ .NET và ABAP và PeopleCode và E-Business Suite, trong các ứng dụng đa nhiệm mà cuối cùng tất cả các giao dịch sẽ tương tác với hệ thống bản ghi. Cho dù đó là tra cứu hàng tồn kho, thời gian báo cáo hoạt động, chúng luôn tương tác với cơ sở dữ liệu. Cơ sở dữ liệu trở thành nền tảng của hiệu quả kinh doanh. Cơ sở dữ liệu, lần lượt, dựa vào lưu trữ. Siêu dữ liệu về các câu trả lời giao dịch, ai, giao dịch nào, ở đâu trong ngăn xếp ứng dụng và sau đó chúng tôi có khả năng hiển thị ở cấp độ mã sâu để cho bạn thấy những gì đang thực thi. Thông tin này được ghi lại liên tục, được đưa vào cơ sở dữ liệu quản lý hiệu suất - trở thành một bản nhạc duy nhất cho mọi người thấy những gì đang diễn ra. Có nhiều người và tổ chức khác nhau quan tâm đến những gì đang xảy ra: các chuyên gia kỹ thuật, chủ sở hữu ứng dụng, cuối cùng là chính doanh nghiệp. Khi một vấn đề xuất hiện, bạn muốn có thể trích xuất thông tin về giao dịch đó.
Trước khi chúng ta xem xét giao dịch đầu tư, tôi muốn cho bạn thấy làm thế nào điều đó có thể xuất hiện với những người khác nhau trong tổ chức. Ở cấp quản lý, bạn có thể muốn có tổng quan về nhiều ứng dụng. Bạn có thể muốn biết về sức khỏe được tính theo sự tuân thủ và tính sẵn có của SLA. Sức khỏe đó không có nghĩa là mọi thứ đều hoạt động hoàn hảo. Có chỗ trong trường hợp này bạn có thể thấy giao dịch đầu tư đang ở trạng thái cảnh báo. Bây giờ, sâu hơn một chút, có thể trong ngành kinh doanh, bạn muốn có thêm một số chi tiết về các giao dịch riêng lẻ, khi chúng vi phạm SLA, số lượng giao dịch, v.v. Nhóm hoạt động sẽ muốn được thông báo về điều đó thông qua một cảnh báo về một số sắp xếp Chúng tôi có các cảnh báo hiệu suất được tích hợp. Chúng tôi thực sự đo hiệu suất trong trình duyệt của người dùng cuối. Cho dù đó là Internet Explorer, Chrome, Firefox, v.v., chúng tôi có thể phát hiện ra, điều này trả lời câu hỏi đầu tiên: người dùng cuối có gặp sự cố không?
Hãy đi sâu vào và xem những gì chúng ta có thể cho thấy về điều đó. Những người quan tâm đến hiệu suất sẽ mở ra Chính xác. Họ sẽ đánh giá các giao dịch. Họ sẽ xem cột SLA để xác định các giao dịch không tuân thủ SLA. Họ có thể thấy những người dùng cuối bị ảnh hưởng cũng như những gì giao dịch đó đã thực hiện khi nó chảy qua ứng dụng. Cách mà bạn giải mã các chữ tượng hình này, đây là trình duyệt, URL, chữ U dành cho URL, đó là điểm nhập cảnh vào JVM. Bây giờ JVM cụ thể này làm cho một máy chủ web gọi ra JVM thứ hai, sau đó thực thi câu lệnh SQL. Đây rõ ràng là một vấn đề cơ sở dữ liệu vì câu lệnh SQL này chịu trách nhiệm cho 72 phần trăm thời gian phản hồi. Chúng tôi đang tập trung vào thời gian. Thời gian là tiền tệ của hiệu suất. Đó là cách người dùng cuối trải nghiệm xem mọi thứ có chạy chậm hay không và đó là thước đo mức tiêu thụ tài nguyên. Nó rất tiện dụng; đó là một số liệu duy nhất quan trọng nhất để đánh giá hiệu suất. Khi vấn đề này được đưa ra cho DBA, đó không chỉ là vấn đề về cơ sở dữ liệu, đây là câu lệnh SQL. Đây là bối cảnh tôi đã nói về.
Bây giờ được trang bị thông tin này, tôi có thể đi vào và phân tích những gì đã xảy ra. Tôi có thể thấy trước hết, trục y là thời gian trong cả ngày. Xin lỗi, trục y là thời gian đáp ứng, trục x là thời gian trong ngày. Tôi có thể thấy có một vấn đề về cơ sở dữ liệu, có hai sự cố xảy ra, quay trở lại luồng đó, chọn câu lệnh SQL đó và đi vào chế độ xem chuyên gia, nơi Chính xác có thể cho bạn thấy những gì đang xảy ra, các điều khiển của nó, thời gian mã đó mất bao lâu hành hình. Trong tầng cơ sở dữ liệu, đó là kế hoạch thực hiện. Bạn sẽ lưu ý rằng Chính xác đã chọn ra kế hoạch thực hiện thực tế được sử dụng tại thời điểm thực hiện, được phân biệt với kế hoạch ước tính, sẽ là khi kế hoạch được đưa ra và không trong thời gian thực hiện. Nó có thể hoặc không thể phản ánh rằng cơ sở dữ liệu thực sự đã làm.
Bây giờ ở đây, là một phân tích thời gian đáp ứng cho câu lệnh SQL. 90% thời gian dành cho việc lưu trữ; mười phần trăm đã được sử dụng trong CPU. Tôi có thể xem văn bản của câu lệnh SQL cũng như báo cáo kết quả. Văn bản của câu lệnh SQL thực sự bắt đầu tiết lộ một số vấn đề mã hóa. Đó là chọn sao; trả về tất cả các hàng - xin lỗi, tất cả các cột từ các hàng được trả về. Chúng tôi đang quay trở lại các cột bổ sung mà ứng dụng có thể hoặc không cần. Những cột tiêu thụ không gian và tài nguyên để xử lý. Nếu bạn chạy SAP, một trong những thay đổi lớn, vì cơ sở dữ liệu HANA là cột, về cơ bản là viết lại SAP để không chọn sao chọn để chúng có thể giảm đáng kể mức tiêu thụ tài nguyên. Điều này về cơ bản là một cái gì đó xảy ra rất nhiều thời gian trong các ứng dụng nhà, cho dù Java, .NET, v.v.
Màn hình đó, cho bạn thấy ai, cái gì, khi nào, ở đâu và tại sao. Tại sao lại đến, như câu lệnh SQL và kế hoạch thực hiện cho phép bạn giải quyết vấn đề. Vì Chính xác chạy liên tục, nên bạn thực sự có thể đo lường trước và sau, ở cấp độ câu lệnh SQL, ở cấp độ giao dịch, do đó bạn có thể tự đo lường, cũng như thông qua chủ sở hữu ứng dụng và quản lý, rằng bạn đã giải quyết vấn đề . Tài liệu đó thực sự hữu ích. Có rất nhiều phức tạp trong ngăn xếp ứng dụng này. Trên thực tế, trong số nhiều ứng dụng, mọi người chúng ta đã nói chuyện, chạy ít nhất một phần của ngăn xếp ứng dụng trong VMware. Trong trường hợp này, họ đang xem ứng dụng dịch vụ khách hàng, họ đang xem thời gian giao dịch và tương quan với sự chậm lại là một sự kiện ảo hóa. Theo dõi chính xác tất cả các sự kiện ảo hóa. Chúng tôi có một trình cắm thêm vào vCenter để chọn nó.
Chúng tôi cũng có thể phát hiện sự tranh chấp. Sự tham gia khác với việc sử dụng. Thực tế hiển thị khi có thể một người hàng xóm ồn ào đang tác động đến VM khách của bạn, trong bối cảnh ứng dụng của máy chủ khách hàng. Bây giờ, tôi có thể truy cập và lấy thông tin và tôi thực sự có thể thấy hai máy ảo đang tranh chấp, trong trường hợp này, cho tài nguyên CPU. Điều này cho phép tôi có tầm nhìn để tôi có thể nhìn vào lịch trình. Tôi có thể đặt một máy khách VM trên một máy chủ vật lý khác. Tất cả các loại điều mà bạn có thể đáp ứng và sau đó, ngoài ra, tôi thực sự có thể xem xét hiệu quả mã để có thể sử dụng ít CPU hơn. Tôi nghĩ rằng tôi có một ví dụ khá hay trong bài trình bày này về cách ai đó có thể giảm mức tiêu thụ CPU bằng các đơn đặt hàng lớn.
Đó là VMware. Chúng ta hãy đi vào chính mã, mã ứng dụng. Chính xác sẽ có thể cho bạn thấy những gì đang xảy ra trong Java, .NET, mã ABAP, E-Business, PeopleCode, v.v. Đây là những điểm nhập vào, trong trường hợp này, vào WebLogic. Ở đây, có một báo cáo phát hiện cho tôi biết đó là những EJB mà bạn cần xem, và sẽ cho tôi biết bạn cũng có khóa xảy ra trên hệ thống này. Một lần nữa, đi sâu vào lớp logic nghiệp vụ, để hiển thị những gì đang diễn ra. Trong trường hợp này, tôi đang xem xét các trường hợp cụ thể; Tôi cũng hỗ trợ phân cụm. Nếu bạn có nhiều JVM đang chạy, bạn có thể xem xét toàn bộ cụm hoặc xem xét các tắc nghẽn trong JVM riêng lẻ.
Khi bạn vào khóa, tôi có thể có ngoại lệ. Ngoại lệ là một chút khác nhau so với một vấn đề hiệu suất. Thông thường, các ngoại lệ được chạy rất nhanh. Bởi vì có lỗi logic và một khi bạn gặp lỗi logic đó, nó sẽ kết thúc. Chúng tôi đã có thể ghi lại dấu vết ngăn xếp ở một ngoại lệ, điều này có thể tiết kiệm rất nhiều thời gian vì nó đang cố gắng tìm hiểu chuyện gì đang xảy ra, bạn chỉ cần có dấu vết ngăn xếp, ngay tại đó. Chúng tôi cũng có thể chụp rò rỉ bộ nhớ là tốt. Giải pháp cũng bao gồm tầng cơ sở dữ liệu, tôi có thể vào, tôi có thể đánh giá thể hiện cơ sở dữ liệu. Một lần nữa, trục y là nơi thời gian được sử dụng, trục x là thời gian trong ngày. Có một báo cáo phát hiện chỉ tự động cho tôi biết những gì đang xảy ra trong hệ thống và những gì tôi có thể xem xét.
Một trong những điều về báo cáo phát hiện của Precise, nó không chỉ nhìn vào nhật ký hoặc trạng thái chờ - nó xem xét tất cả các trạng thái thực thi bao gồm CPU, cũng như trả về thông tin từ bộ lưu trữ. Lưu trữ là một phần rất quan trọng của ngăn xếp ứng dụng, đặc biệt là với sự ra đời của trạng thái rắn. Có thông tin dọc theo những dòng đó có thể rất hữu ích. Đối với các đơn vị lưu trữ nhất định, chúng tôi thực sự có thể đi sâu và hiển thị những gì đang xảy ra ở cấp thiết bị riêng lẻ. Loại thông tin đó - một lần nữa, đó là tầm nhìn sâu sắc; phạm vi rộng - cung cấp cho bạn vừa đủ thông tin để có thêm đòn bẩy để trở thành một chuyên gia hiệu suất ứng dụng, để bạn có thể tối ưu hóa các ứng dụng của mình trên cơ sở từ đầu đến cuối để đáp ứng các giao dịch kinh doanh đó.
Tôi có một vài nghiên cứu trường hợp tôi muốn chia sẻ với bạn. Chúng tôi đi tàu dọc khá nhanh; Tôi hy vọng tôi sẽ đi với một tốc độ ổn. Nói về lưu trữ, mọi người theo thời gian thay đổi phần cứng. Có bảo hành phần cứng. Nó thực sự cung cấp những gì các nhà cung cấp nói với bạn? Bạn có thể đánh giá điều đó với Chính xác. Bạn vào đây, và những gì đã xảy ra ở đây, về cơ bản họ đã đặt một đơn vị lưu trữ mới, nhưng khi các quản trị viên lưu trữ chỉ nhìn vào cấp độ đơn vị lưu trữ, họ đã thấy rất nhiều tranh cãi và họ nghĩ rằng có thể có vấn đề với đơn vị lưu trữ mới này . Nhìn vào nhiều hơn từ góc độ từ đầu đến cuối, chính xác để chỉ ra nơi điều đó sẽ thực sự xảy ra. Họ thực sự đã đạt được thông lượng khoảng 400 meg mỗi giây, trong đó bộ lưu trữ chịu trách nhiệm cho 38% thời gian phản hồi, vì vậy nó khá cao. Với đơn vị lưu trữ mới, chúng tôi thực sự đã tăng lưu lượng lên sáu, bảy trăm megs mỗi giây, về cơ bản là gấp đôi và chúng tôi có thể cắt giảm sự đóng góp của tầng lưu trữ xuống một nửa thời gian giao dịch. Tôi thực sự có thể vẽ biểu đồ ra trước đó, đây là giai đoạn cắt, và sau đó là sau.
Vì vậy, một lần nữa, tài liệu để chứng minh rằng đầu tư phần cứng là xứng đáng và họ đã giao như nhà cung cấp cụ thể đã mong đợi. Có tất cả, vì sự phức tạp, số lượng của mọi thứ, có tất cả các loại điều có thể xảy ra. Trong trường hợp này, họ thực sự đã có một tình huống mà mọi người đều đổ lỗi cho DBA, DBA giống như của Well Well, không nhanh như vậy. Ở đây chúng tôi thực sự đang xem xét một ứng dụng SAP, tôi nghĩ loại kịch bản này khá phổ biến . Điều gì đã xảy ra là, họ đang phát triển một giao dịch tùy chỉnh cho người dùng. Người dùng cũng như vậy, Cái này rất chậm. Bộ mã hóa ABAP - đó là ngôn ngữ lập trình trong SAP - cho biết, Đây là một vấn đề về cơ sở dữ liệu. Họ đã kết thúc việc mở Precise; họ đã đo người dùng cuối 60 giây, trong hơn một phút. Năm mươi ba giây đã được sử dụng ở phía sau. Họ đã khoan vào phần cuối và họ thực sự có thể tiết lộ câu lệnh SQL được trình bày theo thứ tự giảm dần.
Câu lệnh SQL hàng đầu này chịu trách nhiệm cho 25 phần trăm mức tiêu thụ tài nguyên, thời gian thực hiện trung bình của nó là hai mili giây. Bạn không thể đổ lỗi cho cơ sở dữ liệu. Bạn biết đấy, hey, không nhanh như vậy, chàng trai. Câu hỏi là, tại sao có quá nhiều vụ hành quyết? Chà, họ đã đưa nó trở lại ABAP, anh ta đi vào, nhìn vào tổ của vòng lặp, phát hiện ra họ đang gọi sai cơ sở dữ liệu, về cơ bản họ đã thực hiện thay đổi, kiểm tra thay đổi và giờ là thời gian phản hồi mới năm giây Một chút chậm, nhưng họ có thể sống với điều đó. Tốt hơn nhiều so với 60 giây. Đôi khi, chỉ cần tìm ra, nó là mã ứng dụng, nó là cơ sở dữ liệu, nó có phải là lưu trữ không? Đó là những lĩnh vực mà Precise, bằng cách có bối cảnh của các giao dịch đầu cuối, đó là nơi Precise bắt đầu hoạt động. Bạn cơ bản kết thúc những điều đó.
Tôi đang nhìn vào thời gian, có vẻ như chúng ta vẫn còn một chút thời gian để trải qua một vài trong số này. Tôi đang phát trực tuyến thông qua những điều này. Ứng dụng này đã được phát triển trong hơn một năm. Khi họ vào QA, họ đã thấy rằng các máy chủ web đã đạt tối đa 100% và có vẻ như ứng dụng không thể chạy dưới VMware. Điều đầu tiên mọi người nói là, về vấn đề vật lý; nó không thể chạy dưới VMware. Chính xác thực sự cung cấp cho họ những cách bổ sung để giải quyết vấn đề. Chúng tôi đã xem xét các giao dịch, chúng tôi thấy một cuộc gọi máy chủ web, nó đến như một ASMX trong IIS.NET. Nó thực sự tiết lộ mã cơ bản. Bạn thấy điều này khi tôi chỉ? Đây là 23 ngày, 11 giờ. Wow, làm thế nào là có thể? Vâng, mỗi lần gọi mất 9, 4 giây và điều này được gọi tới 215.000 lần. Đối với mỗi lần gọi, nó sử dụng 6 giây CPU. Đây là lý do, mã này là lý do tại sao điều này không bao giờ có thể mở rộng. Trong thực tế, nó không thể quy mô trong vật lý.
Những gì họ đã làm, là họ đã quay lại với các nhà phát triển của mình và họ nói, ai đó có thể thay đổi không? Họ đã có một cuộc thi, và họ đã thử nghiệm các đề xuất khác nhau và họ đã đưa ra một gợi ý có thể chạy được nhiều hiệu quả hơn. Điểm mới hoàn thành một điểm, ít hơn hai giây một chút, với hai phần trăm giây trong CPU. Bây giờ điều này có thể mở rộng và nó có thể chạy trên trang trại VMware. Về cơ bản chúng tôi có thể chứng minh rằng ở cả cấp độ mã cũng như cấp độ giao dịch. Đây là loại trước, và sau đó. Bây giờ bạn có thể thấy ở đây trong biểu đồ thanh ngăn xếp hiển thị web, .NET và cơ sở dữ liệu, bây giờ bạn đang tương tác với cơ sở dữ liệu. Đây là một hồ sơ bạn sẽ thấy cho một ứng dụng đang chạy bình thường hơn.
Được rồi, tôi đang chọn và chọn theo những điều bổ sung mà tôi có thể chỉ cho bạn. Rất nhiều người thích điều này bởi vì điều này gây ấn tượng với nhiều cửa hàng. Nếu bạn không thể gặp SLA kinh doanh và mọi người đều như vậy, thì Hãy giúp chúng tôi ra ngoài. Cửa hàng này có tình huống SLA kinh doanh nhận được đơn đặt hàng trước 3 giờ chiều, ngày hôm đó đã được chuyển đi. Điều thực sự quan trọng là họ nhận được các đơn đặt hàng, và nhà kho rất bận rộn. Màn hình đặt hàng bán hàng của JD Edwards này, đã bị đóng băng và bạn có thể biết được rằng đây là một hệ thống quản lý hàng tồn kho bán lẻ chỉ trong thời gian. Kệ trống là không thể chấp nhận trong bán lẻ. Phải có hàng hóa ở đó để bán nó. Những gì chúng tôi đã làm là chúng tôi đã tham gia, trong trường hợp này, chúng tôi đang xem xét cơ sở dữ liệu máy chủ SQL. Giao diện giống nhau cho dù đó là SQL, Oracle, DB2 hay Sybase.
Chúng tôi đã xác định lựa chọn từ PS_PROD và chúng tôi có thể nắm bắt được thời lượng, thực tế là họ thực thi rất nhiều. Màu xanh đậm khớp với khóa cho biết họ không chờ ở trạng thái chờ hoặc ghi nhật ký hoặc thậm chí lưu trữ - điều này bị ràng buộc bởi CPU. Chúng tôi đã theo dõi câu lệnh SQL bằng 34602 vì vậy mỗi khi điều này được thực thi, chúng tôi sẽ tăng các bộ đếm của mình để theo dõi nó. Điều đó có nghĩa là chúng tôi có một lịch sử chi tiết và tôi có thể truy cập nó bằng cách nhấp vào nút điều chỉnh đó. Đây là tab lịch sử. Màn hình này ở đây hiển thị thời lượng trung bình so với thay đổi. Thứ tư, thứ năm, thứ sáu, thời lượng trung bình là khoảng hai phần mười của một giây. Rất ít màn hình đóng băng, họ có thể đáp ứng SLA kinh doanh. Đến ngày 27 tháng 2, một cái gì đó thay đổi và đột nhiên, thời gian thực hiện đã đến đây và điều đó thực sự đủ chậm để gây ra thời gian chờ, dẫn đến đóng băng màn hình. Chính xác, bằng cách giữ một lịch sử chi tiết, bao gồm cả kế hoạch thực hiện và các thay đổi chung đối với các chỉ mục của bảng nếu SQL đó được sử dụng. Chúng tôi đã có thể nhận ra rằng kế hoạch truy cập đã thay đổi vào ngày 27 tháng 2. Thứ hai đến thứ sáu tuần xấu. Đến ngày 5 tháng 3, kế hoạch truy cập lại thay đổi. Đây là một tuần tốt. Ngôi sao màu hồng này cho chúng ta biết khối lượng cập nhật.
Bạn có thể thấy ở đây số lượng hàng trong các bảng bên dưới đang tăng lên và đây là điển hình cho một doanh nghiệp. Bạn muốn bảng của bạn phát triển. Vấn đề là các câu lệnh được phân tích cú pháp, các câu lệnh SQL xuất hiện, trình tối ưu hóa phải quyết định những việc cần làm và chọn khi kế hoạch thực hiện nhanh, chọn một kế hoạch thực hiện khác khi nó chậm, khiến màn hình bị đóng băng. Trên cơ sở công nghệ sâu rộng, tôi cần biết kế hoạch thực hiện là gì và Chính xác nắm bắt nó để tôi hoàn thành với dấu ngày và thời gian. Đây là một trong đó là nhanh và hiệu quả, đây là một trong đó là chậm và không hiệu quả. Tham gia bộ lọc này chỉ đơn giản là sử dụng nhiều CPU hơn để điều hòa, để thực hiện câu lệnh SQL cụ thể này. Chúng vẫn có tác dụng tối ưu tương tự, nhưng về cơ bản, công thức này có công thức chậm hơn, kém hiệu quả hơn để cung cấp tập kết quả. Vì vậy, chúng tôi bước qua. Này, chúng ta có thời gian cho một cặp vợ chồng nữa không?
Eric Kavanagh: Vâng, đi cho nó.
Bill Ellis: Được rồi, tôi sẽ bỏ qua phía trước. Một điều tôi muốn bạn lưu ý, chúng tôi đã nói về phần cứng, nói về SAP, chúng tôi đã nói về .NET, chúng tôi đã nói về JD Edwards và môi trường Máy chủ Java-SQL. Đây là SAP, ở đây chúng tôi đang xem PeopleSoft. Ma trận hỗ trợ chính xác là rộng và sâu. Nếu bạn có một ứng dụng, nhiều khả năng, chúng tôi có thể sử dụng nó để cung cấp mức độ hiển thị này. Một trong những thay đổi lớn nhất đang xảy ra ngay bây giờ là tính di động. PeopleSoft đã giới thiệu tính di động với UI Fluid của nó. UI Fluid sử dụng một hệ thống rất khác nhau. Ứng dụng này đang phát triển. Giao diện người dùng Fluid - những gì nó làm từ góc độ quản lý là nó cho phép người dùng cuối sử dụng điện thoại của họ và nó giúp tăng năng suất rất nhiều. Nếu bạn có hàng trăm hoặc hàng ngàn hoặc thậm chí nhiều nhân viên hơn, nếu bạn có thể tăng năng suất của họ, 1% 2 phần trăm, bạn có thể có một tác động rất lớn đến bảng lương và mọi thứ khác. Điều gì đã xảy ra là, cửa hàng đặc biệt này đã tung ra giao diện người dùng PeopleSoft Fluid. Bây giờ, nói về sự phức tạp, đây là ngăn xếp PeopleSoft. Một ứng dụng, tối thiểu sáu công nghệ, nhiều người dùng cuối. Làm thế nào để bạn bắt đầu nó?
Một lần nữa, Chính xác sẽ có thể theo dõi các giao dịch này. Những gì chúng tôi đang hiển thị cho bạn ở đây là một biểu đồ thanh xếp chồng lên nhau hiển thị máy khách, máy chủ web, Java, cơ sở dữ liệu tuxedo, ngăn xếp ứng dụng PeopleSoft. Các bản đồ màu xanh lá cây đến J2EE, đó là một cách nói lạ mắt về WebLogic. Đây là sự cắt xén. Người dùng cuối bắt đầu sử dụng Fluid UI và thời gian phản hồi đi từ có thể một rưỡi, hai giây, lên đến khoảng chín, mười giây. Điều mà một màn hình này không hiển thị là số người không nhận được phản hồi. Họ thực sự bị đóng băng màn hình trong ứng dụng. Chúng ta hãy xem một số khả năng mà Precise có thể cung cấp cho khách hàng này.
Trước hết, khi tôi nhìn vào các giao dịch PeopleSoft, họ có thể thấy về cơ bản, chúng tôi đã thấy loại điều này trên bảng. Tất cả các giao dịch đã bị ảnh hưởng, cũng như tất cả các địa điểm. Ngẫu nhiên, khi bạn nhìn vào điều này, bạn thực sự có thể thấy các địa điểm trên khắp thế giới. Từ Châu Á Thái Bình Dương, đến Châu Âu cũng như Bắc Mỹ. Vấn đề về hiệu suất không nằm ở một giao dịch cụ thể hoặc vị trí địa lý cụ thể, đó là hệ thống rộng. Đó là một cách để nói rằng sự thay đổi hoặc cách mà Fluid UI có tác động toàn cầu. Bạn có thể thấy ở đây từ quan điểm về khả năng mở rộng, mọi người đang cố gắng thực hiện cùng một loại hoạt động, nhưng về cơ bản thời gian đáp ứng chỉ bị suy giảm và xuống cấp. Bạn có thể thấy rằng mọi thứ không mở rộng. Mọi thứ đang diễn ra rất, rất tồi tệ. Ở đây, khi tôi nhìn vào số lượng trục và các kết nối đồng thời, bạn sẽ thấy một cái gì đó rất thú vị về số lượng truy cập và các kết nối. Ở đây chúng tôi chỉ mở rộng lên tới khoảng 5.000 và bạn đang xem xét, điều này dẫn đến 100 kết nối đồng thời. Điều này được thực hiện sau; đây là trước đây Vì vậy, nhu cầu thực sự của tôi trên hệ thống, nếu điều này có thể mở rộng, nằm trong phạm vi 300.000. Ngày xưa, với giao diện người dùng cổ điển, bạn đang xem xét 30 kết nối đồng thời.
Bây giờ điều này đang nói với bạn là UI Fluid sử dụng ít nhất 10 lần số kết nối đồng thời. Chúng tôi bắt đầu rút lại những gì đang diễn ra dưới vỏ bọc với PeopleSoft để bạn có thể bắt đầu thấy tác động trên các máy chủ web, thực tế là SLA đang bắt đầu vi phạm. Không đi sâu vào mọi thứ, nhưng điều cuối cùng xảy ra là về cơ bản họ dựa vào tin nhắn. Về cơ bản, chúng tập thể dục là WebLogic và gây ra tình trạng xếp hàng trong tuxedo. Thực sự có một vấn đề phụ thuộc nhiều hơn xuất hiện với Fluid UI, nhưng Precise có thể chỉ ra rằng bằng một loạt những điều khác nhau, chúng ta có thể tập trung vào vấn đề là gì. Nó chỉ ra rằng cũng có một vấn đề trong cơ sở dữ liệu. Thực sự có một tệp nhật ký nhắn tin và vì tất cả người dùng đồng thời, tệp nhật ký đó đã bị khóa. Về cơ bản, nó có những thứ để điều chỉnh, trong mỗi tầng trong ngăn xếp ứng dụng. Nói về sự phức tạp, đây thực sự là tầng tuxedo cho bạn thấy hàng đợi và bạn cũng có thể thấy hiệu suất giảm trong tầng này. Tôi có thể thấy các quy trình; Tôi có thể thấy các tên miền và máy chủ. Trong tuxedo, để mọi người sử dụng điều đó, thông thường những gì bạn làm là bạn mở thêm hàng đợi, tên miền và máy chủ, giống như ở siêu thị để giảm bớt tắc nghẽn, để giảm thiểu thời gian xếp hàng. Tùy chọn cuối cùng và cuối cùng, Chính xác hiển thị rất nhiều thông tin.
Như tôi đã đề cập trước đó, mọi giao dịch quan trọng đều tương tác với hệ thống hồ sơ. Tầm nhìn vào cơ sở dữ liệu là tối quan trọng. Chính xác cho thấy những gì xảy ra trong cơ sở dữ liệu, trong WebLogic, trong Java, .NET, trong trình duyệt, nhưng vị trí mà Chính xác thực sự vượt trội là trong tầng cơ sở dữ liệu. Điều này xảy ra là điểm yếu của các đối thủ cạnh tranh của chúng tôi. Hãy để tôi chỉ cho bạn một trong những cách mà Chính xác có thể giúp bạn vượt qua điều này. Tôi sẽ không dành thời gian cho tam giác tối ưu hóa cơ sở dữ liệu, nhưng về cơ bản chúng tôi đang xem xét các thay đổi loại chi phí thấp, rủi ro thấp, phạm vi rộng, rủi ro cao, chi phí cao. Tôi thực sự sẽ tweet ra slide này sau đó nếu mọi người muốn thử và xem nó. Đó là một hướng dẫn khá lớn, tôi nghĩ, để điều chỉnh các vấn đề. Đây là chính xác cho quan điểm chuyên gia của Oracle. Đứng đầu trong báo cáo phát hiện, tác động 60 phần trăm là câu lệnh SQL cụ thể này. Nếu bạn mở màn hình hoạt động này, nó sẽ hiển thị nó ở đó. Tôi có thể nhìn vào tuyên bố chọn này, có một kế hoạch thực hiện. Mỗi lần thực hiện mất một giây - 48.000 lần thực hiện. Điều đó cho biết thêm tới 48.000 giờ hành quyết.
Màu xanh đậm, một lần nữa, là CPU. Điều này là CPU bị ràng buộc, không phải là trạng thái chờ, không phải là nhật ký. Tôi nhấn mạnh rằng vì một số đối thủ cạnh tranh của chúng tôi chỉ xem xét trạng thái chờ đợi và ghi lại các sự kiện nhưng nói chung, CPU là trạng thái thực thi bận rộn nhất và cung cấp nhiều sự mua lại nhất. Đi vào cái nhìn chuyên gia này - và tôi sẽ đi rất nhanh - những gì tôi đã làm là tôi nhìn vào cái bàn, 100.000 hàng, 37.000 khối. Chúng tôi đang làm một bảng đầy đủ, nhưng chúng tôi có sáu chỉ mục về điều này. Những gì đang xảy ra ở đây? Chà, khi tôi nhìn vào mệnh đề where, mệnh đề này đang làm gì thì nó thực sự chuyển đổi một cột thành chữ hoa và nó nói nó ở đâu bằng chữ hoa, hãy tìm biến. Điều đang xảy ra là mỗi khi điều này thực thi, Oracle phải chuyển đổi cột này thành chữ hoa. Thay vì làm điều đó gần năm mươi nghìn lần, việc xây dựng chỉ mục đó thành chữ hoa của một chỉ mục dựa trên chức năng và nó không chỉ có sẵn trong bộ phận doanh nghiệp của Oracle, mà còn là bộ phận tiêu chuẩn. Khi bạn làm điều đó, những gì bạn có thể làm là xác minh kế hoạch thực hiện phát hành chữ hoa mà người dùng chỉ mục mới viết hoa, đó chỉ là một việc của tôi.
Sau đó, từ phép đo trước và sau, bạn đang xem thời gian thực hiện trong một giây, tổng hợp tối đa 9 giờ 54 phút, với cùng một câu lệnh SQL chính xác, nhưng có chỉ số đó được xây dựng bằng chữ hoa cho 58.000 lần thực thi, phản hồi thời gian giảm xuống dưới một phần nghìn giây, tổng hợp lại với nhau, nó lên đến bảy giây. Về cơ bản tôi đã lưu mười giờ CPU trên máy chủ của mình. Điều này là rất lớn. Bởi vì nếu tôi không phải do làm mới máy chủ, tôi có thể sống trên máy chủ đó. Tôi thực sự giảm mức sử dụng máy chủ đó xuống 20 phần trăm và bạn thực sự có thể thấy trước và sau. Đó là loại tầm nhìn mà Chính xác có thể cung cấp. Ngoài ra còn có một số điều bổ sung mà chúng ta có thể xem xét, tại sao bạn có tất cả các chỉ mục này nếu chúng không được sử dụng? Họ có thể theo dõi với điều đó. Có kiến trúc, và tôi sẽ gói nó lại, vì chúng ta đang đạt đến đỉnh cao của giờ. Tôi là một người tin tưởng thực sự vào giải pháp này và chúng tôi muốn bạn trở thành một người tin tưởng thực sự. Tại IDERA, chúng tôi tin rằng bản dùng thử tạo ra một khách hàng, vì vậy nếu bạn quan tâm, chúng tôi có thể thực hiện các đánh giá trong trang web của bạn.
Với điều đó, tôi sẽ vượt qua đèn hiệu.
Eric Kavanagh: Vâng, đây là chi tiết to lớn mà bạn đã thể hiện ở đó. Nó thực sự khá hấp dẫn. Tôi nghĩ rằng tôi có thể đã đề cập với bạn trong quá khứ - và tôi biết trong một số webcast khác mà chúng tôi đã thực hiện với IDERA, tôi đã đề cập rằng - tôi thực sự đã theo dõi Chính xác từ trước khi được IDERA mua lại, Tất cả các cách trở lại năm 2008, tôi nghĩ, hoặc năm 2009. Tôi đã bị nó mê hoặc từ đó. Tôi tò mò muốn biết có bao nhiêu công việc đi vào đầu các phiên bản mới của ứng dụng. Bạn đã đề cập rằng SAP HANA, mà tôi nghĩ là khá ấn tượng khi bạn thực sự có thể đào sâu vào kiến trúc HANA và thực hiện một số khắc phục sự cố ở đó. Bạn có bao nhiêu người Phần nỗ lực của bạn là bao nhiêu và phần nào có thể được thực hiện một cách linh hoạt, nghĩa là khi công cụ được triển khai, bạn bắt đầu bò xung quanh và nhìn thấy những thứ khác nhau? Bao nhiêu trong số đó có thể được tự động, sắp xếp, được xác định bởi công cụ, để bạn có thể giúp mọi người khắc phục sự cố môi trường phức tạp?
Bill Ellis: Bạn đã hỏi rất nhiều câu hỏi ở đó.
Eric Kavanagh: Tôi biết, xin lỗi.
Bill Ellis: Tôi đã cung cấp rất nhiều chi tiết bởi vì đối với các ứng dụng này, nhìn vào mã, ma quỷ nằm trong chi tiết. Bạn phải có mức độ chi tiết đó để thực sự có thể có thứ gì đó có thể thực hiện được. Không có số liệu hành động, bạn chỉ biết về các triệu chứng. Bạn không thực sự giải quyết vấn đề. IDERA là về giải quyết vấn đề. Đứng đầu trong các phiên bản mới và công cụ là một thách thức lớn. Câu hỏi về những gì nó cần để làm điều đó, đó thực sự là để quản lý sản phẩm. Tôi không có nhiều tầm nhìn về đội về cơ bản giúp chúng tôi cập nhật mọi thứ. Về mặt HANA, đó thực sự là một bổ sung mới cho dòng sản phẩm IDERA; nó rất thú vị. Một trong những điều với HANA là - hãy để tôi nói về nhiệm vụ trong một giây. Trong nhiệm vụ, các cửa hàng SAP sẽ làm là họ sao chép cơ sở dữ liệu cho mục đích báo cáo. Sau đó, bạn phải có người hòa giải với những gì thực sự hiện tại. Bạn sẽ có những cơ sở dữ liệu khác nhau và chúng không đồng bộ theo các cấp độ khác nhau. Chỉ có rất nhiều thời gian và công sức, cộng với phần cứng, phần mềm và con người để duy trì tất cả những thứ đó.
Ý tưởng về HANA để có một cơ sở dữ liệu trong bộ nhớ song song cao, để cơ bản tránh sự cần thiết phải có cơ sở dữ liệu trùng lặp. Chúng tôi có một cơ sở dữ liệu, một nguồn sự thật, nó luôn cập nhật, theo cách đó bạn tránh được sự cần thiết phải làm tất cả sự hòa giải đó. Tầm quan trọng của hiệu suất của cơ sở dữ liệu HANA tăng lên - Tôi sẽ nói gấp 10 hoặc ít nhất là có giá trị hơn tổng của tất cả các cơ sở dữ liệu, phần cứng, tài nguyên khác có thể mua. Có thể quản lý HANA, bây giờ thành phần đó thực sự đang trong giai đoạn thử nghiệm, đây là thứ sẽ sớm được sử dụng GA. Vì vậy, điều đó khá thú vị đối với IDERA và về cơ bản chúng tôi hỗ trợ nền tảng SAP. Tôi không chắc những phần khác trong câu hỏi của bạn tôi thuộc loại ngắn gọn nhưng -
Eric Kavanagh: Không có tất cả những thứ tốt trong đó. Tôi đã ném cả đống vào tất cả các bạn cùng một lúc, rất xin lỗi về điều đó. Tôi chỉ bị mê hoặc, thực sự, ý tôi là đây không phải là một ứng dụng đơn giản, phải không? Bạn đang đào sâu vào các công cụ này và hiểu cách chúng tương tác với nhau và theo quan điểm của bạn, bạn phải sắp xếp câu chuyện cùng nhau trong đầu. Bạn phải kết hợp các mẩu thông tin để hiểu những gì thực sự xảy ra và những gì gây ra rắc rối cho bạn, để bạn có thể vào đó và giải quyết những vấn đề đó.
Một người tham dự đang hỏi, việc thực hiện Chính xác khó như thế nào? Một người khác hỏi, ai là người - rõ ràng là các DBA - nhưng một số vai trò khác trong tổ chức sẽ sử dụng những công cụ này là ai?
Bill Ellis: Chính xác thì phức tạp hơn một chút để triển khai. Bạn phải có một số kiến thức về môi trường ứng dụng, về mặt, bạn biết, ứng dụng này chạy trên cơ sở dữ liệu này, nó cần hoặc - các máy chủ web trung cấp, v.v. Tôi nghĩ rằng sự phức tạp của một số ứng dụng này, nó thực sự tương đối dễ dàng. Nếu tôi có thể kết nối máy chủ web với cơ sở dữ liệu của bạn, tôi có thể thực hiện điều đó từ đầu đến cuối. Bạn nhận thấy rằng tôi đã không nói bất cứ điều gì về việc cung cấp cho khách hàng người dùng cuối và đó là vì những gì chúng tôi làm là, chúng tôi thực sự bao gồm một cách linh hoạt, vì vậy bạn không phải thay đổi mã của mình hoặc bất cứ điều gì khác. Một JavaScript đi vào khung trang ứng dụng. Bất kể người dùng ở đâu trên thế giới, khi họ truy cập URL từ ứng dụng của bạn và họ đưa trang đó xuống, nó đi kèm với Chính xác. Điều đó cho phép chúng tôi chọn ID người dùng, địa chỉ IP của họ, cũng là thời gian kết xuất byte đầu tiên của mỗi thời gian thực hiện tập lệnh thành phần trang trong trình duyệt của người dùng cuối.
Về các giao dịch, bạn không phải vạch ra các giao dịch vì chúng được liên kết chặt chẽ. URL này trở thành một điểm truy cập vào JVM và sau đó gọi thông báo này, dẫn đến một JVC bị bắt từ cơ sở dữ liệu. Về cơ bản, chúng tôi có thể nắm bắt các điểm kết nối tự nhiên đó và sau đó trình bày chúng cho bạn trong màn hình giao dịch mà tôi đã chỉ cho bạn, nơi chúng tôi cũng đã tính toán bao nhiêu thời gian hoặc phần trăm thời gian được sử dụng trong mỗi bước riêng lẻ. Tất cả điều đó được thực hiện tự động. Nói chung, chúng tôi phân bổ 90 phút để làm - về cơ bản cài đặt lõi Chính xác và sau đó chúng tôi bắt đầu triển khai ứng dụng. Tùy thuộc vào kiến thức của ứng dụng, chúng tôi có thể mất một số phiên bổ sung để có được toàn bộ ứng dụng. Nhiều người chỉ sử dụng thành phần cơ sở dữ liệu của Chính xác. Tốt rồi. Về cơ bản, bạn có thể phá vỡ điều này, chia nó thành các thành phần mà bạn cảm thấy như trang web của bạn cần. Chúng tôi chắc chắn tin rằng bối cảnh có toàn bộ ngăn xếp ứng dụng là công cụ để bạn có thể thấy rằng sự phụ thuộc giữa các tầng thực sự làm tăng giá trị của việc theo dõi một tầng riêng lẻ. Nếu bất cứ ai muốn khám phá thêm công cụ ngăn xếp ứng dụng của họ, vui lòng truy cập trang web của chúng tôi - tôi đoán đó là cách dễ nhất để yêu cầu thêm thông tin và chúng tôi sẽ thảo luận thêm một chút.
Eric Kavanagh: Hãy để tôi ném một hoặc hai câu hỏi nhanh cho bạn. Tôi đoán rằng bạn đang thu thập và xây dựng một kho lưu trữ theo thời gian, cho cả khách hàng cá nhân và với tư cách là một thực thể công ty, về sự tương tác giữa các ứng dụng khác nhau và cơ sở dữ liệu khác nhau. Nói cách khác, mô hình hóa kịch bản, tôi đoán, là những gì tôi đang ám chỉ. Có phải vậy không? Bạn có thực sự duy trì một kho lưu trữ các tình huống phổ biến để bạn có thể đưa ra đề xuất cho người dùng cuối khi một số thứ nhất định xuất hiện không? Giống như phiên bản E-Business Suite này, phiên bản của cơ sở dữ liệu này, v.v. - bạn có làm nhiều điều đó không?
Bill Ellis: Chà, loại thông tin đó được xây dựng trong báo cáo phát hiện. Báo cáo phát hiện cho biết các nút thắt hiệu suất là gì và nó dựa trên thời gian thực hiện. Một phần của báo cáo phát hiện đó là tìm hiểu thêm và bạn sẽ làm gì tiếp theo. Thông tin hoặc kinh nghiệm từ khách hàng và vv về cơ bản được tích hợp vào thư viện khuyến nghị đó.
Eric Kavanagh: Được rồi, nghe hay đấy. Vâng folks, trình bày tuyệt vời ngày hôm nay. Bill, tôi yêu bao nhiêu chi tiết bạn có trong đó. Tôi chỉ nghĩ rằng đây là thông tin thực sự tuyệt vời, nghiệt ngã, cho thấy tất cả những thứ này được thực hiện như thế nào. Tại một thời điểm nhất định, nó gần giống như ma thuật đen, nhưng thực sự, không phải vậy. Đó là công nghệ rất cụ thể mà các bạn tập hợp lại để hiểu môi trường rất, rất phức tạp và khiến mọi người hài lòng vì không ai thích khi các ứng dụng chạy chậm.
Vâng, chúng tôi sẽ lưu trữ webcast này. Bạn có thể truy cập trực tuyến vào Techopedia hoặc insideanalysis.com và wow, cảm ơn vì thời gian của bạn, chúng tôi sẽ bắt kịp bạn vào lần tới. Hãy bảo trọng, tạm biệt.
