현대 컴퓨팅 시대의 '일반적인 비즈니스 앱'에서 성능이 중요한 이유는 무엇입니까? [닫은]

이것은 당신에게 이상한 질문처럼 보일 수 있습니다.

저는 취미 자바 프로그래머입니다. 나는 여러 게임, 음악을 만드는 AI 프로그램, 그림을위한 또 다른 프로그램 및 유사한 것들을 개발했습니다. 이것은 프로그래밍에 대한 경험이 있지만 비즈니스 응용 프로그램의 전문 개발에는 해당되지 않음을 나타냅니다.

이 사이트에서 성능에 대한 많은 이야기를 봅니다. 사람들은 종종 C #에서 작업을 수행하는 데 가장 효율적인 알고리즘이 무엇인지, 왜 파이썬이 느리고 Java가 더 빠른지 등에 대해 토론합니다.

내가 이해하려고하는 것은 왜 중요합니까?

성능이 중요한 이유는 게임, 게임, 지속적인 업데이트 루프에서 초당 수만 건의 계산이 발생하는 특정 컴퓨팅 영역 또는 OS 및 VM과 같은 다른 프로그램이 의존하는 저수준 시스템 등이 있습니다.

그러나 일반적인 일반 비즈니스 응용 프로그램의 경우 성능이 중요한 이유는 무엇입니까?

수십 년 전에 그것이 왜 중요한지 이해할 수 있습니다. 컴퓨터는 속도 가 훨씬 느리고 메모리가 훨씬 적으므로 이러한 것들에 대해 신중하게 생각해야했습니다.

그러나 오늘날 우리는 여분의 메모리를 많이 가지고 있으며 컴퓨터가 너무 빠릅니다. 특정 Java 알고리즘이 O (n ^ 2)인지 실제로 중요합니까? 실제로이 일반적인 비즈니스 앱의 최종 사용자에게 차이가 있습니까?

일반적인 비즈니스 응용 프로그램에서 GUI 버튼을 누르고 무대 뒤에서 현대 컴퓨팅 시대에 O (n ^ 2) 알고리즘을 호출 합니다. 실제로 비 효율성을 느끼십니까?

내 질문은 두 가지로 나뉩니다.

1. 실제로 오늘날 일반적인 비즈니스 프로그램에서 성능이 중요합니까?
2. 그렇다면 성능과 최적화가 중요한 응용 프로그램의 실제 장소에 대한 예를 알려주십시오.

당신이 바로있어 비즈니스 애플리케이션의 성능이 정말 중요한 과제가 대부분의 프로그래머에 의해 설명하는 방법이 아니다 . 일반적으로 프로그래머가 듣는 성능 관련 토론에는 몇 가지 문제가 있습니다.

• 그들은 주로 조기 최적화 입니다. 일반적으로 누군가는 명백한 이유없이 작업을 수행하는 "가장 빠른 방법"을 원하고 어쨌든 대부분의 컴파일러가 수행하는 코드 변경 (예 : 곱셈 또는 인라인으로 나누기 등) 또는 변경하는 데 며칠을 소비합니다 런타임에 몇 마이크로 초를 얻는 데 도움이됩니다.

• 그들은 종종 투기 적 입니다. Stack Overflow and Programmers.SE 에서 문제가 성능과 관련이있을 때 프로파일 링 이 자주 언급되지만 성능에 대해 프로파일 링이 무엇인지 모르는 두 명의 프로그래머를 보면 실망합니다. 코드에서 수행해야 할 관련 변경 사항 그들은 변화가 모든 것을 더 빨리 만들 것이라고 생각하지만 실제로는 눈에 띄는 영향을 미치지 않거나 속도를 늦추는 반면 프로파일 러는 쉽게 최적화 할 수 있고 코드를 낭비하는 80 %의 다른 부분을 지적했을 것입니다 시간의.

• 기술적 인 측면에만 중점을 둡니다. 사용자 지향 응용 프로그램의 성능은 느낌에 관한 것입니다. 속도가 빠르고 반응이 느리거나 느리고 어색한 느낌입니까? 이러한 맥락에서 성능 문제는 일반적으로 사용자 경험 디자이너에 의해 훨씬 더 잘 해결됩니다. 단순한 애니메이션 전환은 종종 느리게 느껴지는 앱과 반응하는 느낌의 앱 사이의 차이 일 수 있습니다. 둘 다 600ms를 소비합니다. 작업을 수행합니다.

• 기술적 인 제약과 관련이있을 때에도 주관적인 요소를 기반으로합니다. 빠르고 반응 이 빠르다 는 문제가 아니라면 특정 시스템에서 실행되는 특정 데이터에 대해 작업을 얼마나 빨리 수행해야하는지 지정하는 비 기능적 요구 사항이 있어야합니다 . 실제로 관리자는 자신 이 느린 것을 발견 했다고 말한 다음 개발자는 그 의미를 파악해야합니다. "현재 30 초 미만이어야하지만 10 초가 소요됩니다"와 같이 느리거나 "10 초에서 9 초까지 지속 시간을 줄일 수 있습니다"처럼 느립니까?

프로그래머로 경력을 쌓기 시작했을 때, 나는 많은 고객들을 위해 소프트웨어를 개발하고있었습니다. 나는이 소프트웨어가 세상에 행복을 가져다 줄 차세대 위대한 제품이라고 확신했기 때문에 성능에 대해 분명히 염려했다.

"프로파일 링"또는 "벤치 마크"와 같은 용어를 들었지만 그 의미가 무엇인지 알지 못했고 덜 신경 쓰지 못했습니다. 또한 C에 관한 책, 특히 최적화 기술에 대해 논의한 장을 읽는 데 너무 집중했습니다. 컴퓨터가 나누기보다 곱셈을 더 빨리 수행한다는 것을 발견했을 때, 나는 나누기를 가능한 곳의 곱셈으로 대체했습니다. 메소드 호출이 느릴 수 있음을 발견했을 때 이전 100 LOC 메소드가 아직 문제가되지 않은 것처럼 가능한 많은 메소드를 결합했습니다.

때로는 밤새도록 변경을했지만 아무도 원하지 않는 느린 앱과 모두가 다운로드하고 사용하기를 원하는 빠른 앱간에 차이를 만들었습니다. 이 앱에 관심을 보인 두 명의 실제 고객이 실제 기능을 요청한 사실은 "애플리케이션이 느린 경우 누가 기능을 원할까요?"라고 귀찮게하지 않았습니다.

마지막으로 두 명의 고객 만이 앱 사용을 중단했습니다. 모든 노력에도 불구하고 놀라 울 정도로 빠르지는 않았습니다. 주로 인덱스가 무엇인지 알지 못하고 앱이 데이터베이스를 많이 사용하는 경우 잘못된 것이 있기 때문입니다. 어쨌든, 한달에 한 번 사용되는 코드의 실행을 몇 마이크로 초 정도 개선 한 또 다른 성능 관련 변경을 수행 할 때 고객 은 변경 사항을 보지 못했습니다 . 그들이보고있는 것은 사용자 경험이 끔찍하고 문서가 누락되었으며 몇 달 동안 요청했던 중요한 기능이 여기에 없었으며 해결해야 할 버그의 수가 계속 증가하고 있다는 것입니다.

결과 : 전 세계 수많은 회사에서이 앱을 사용하기를 희망했지만 오늘날 인터넷에서이 애플리케이션에 대한 정보를 찾을 수 없습니다. 단 두 명의 고객 만 포기하고 프로젝트도 포기했습니다. 그것은 결코 판매되지 않았고 공개적으로 광고되지도 않았으며, 오늘날 내 PC에서 그것을 컴파일 할 수 있는지 확실하지 않습니다 (원본 소스를 찾지 않음). 실제로 중요한 것에 더 집중한다면 이런 일은 일어나지 않았을 것입니다.

이 말 은 일반적으로 성능이 중요합니다 .

• 비즈니스 용이 아닌 앱에서는 중요 할 수 있습니다. 거기에 임베디드 소프트웨어 에 소프트웨어 실행 된 서버 (당신이있을 때 큰 성능 시작이 문제가 될 것을 아니다 둘째, 당 요청의 몇 천)에 소프트웨어 실행 된 스마트 폰 , 비디오 게임 , 전문가를위한 소프트웨어 (핸들 시도 Photoshop의 50GB 파일은 매우 빠르지 않은 컴퓨터에서 확신 할 수 있음) 많은 사람들에게 판매되는 일반 소프트웨어 제품 (Microsoft Word가 모든 작업을 수행하는 데 두 배의 시간을 소비하는 경우 시간에 숫자를 곱한 시간) 사용자 수가 문제가 될 수 있습니다).

• 비즈니스 응용 프로그램에서 응용 프로그램 많은 경우가있다 느낌 과 입니다 느린 사용자에게 미움 될 것이다. 당신은 당신의 관심사에 따라 성능을 발휘하기를 원하지 않습니다.

예. 그렇습니다. 런타임 속도는 여러분이 겪어야 할 유일한 관심사 일뿐만 아니라 1982 년만큼이나 압박감이 높지 않거나 저전력 임베디드 시스템에서와 같이 항상 중요하지는 않지만 항상 관심사이므로 이해하는 것이 중요합니다. 왜 이럴까요?

우선, 언급 한 점근 적 복잡성 은 입력 크기가 커짐에 따라 프로그램의 동작 을 설명합니다 . 10 개의 항목을 다루는 비선형 프로그램은 불필요한 작업을 수행 할 수는 있지만 언젠가는 1000을 처리해야 할 때 속도가 느려질뿐 아니라 속도가 훨씬 느리기 때문에 물릴 것입니다. 그리고 당신은 그 점이 100 개 항목, 1000 개 항목, 또는 10 만개 항목에 도달 할 때까지 해당 항목이 100 개 항목에 있는지, 아니면 광범위한 분석 및 벤치마킹 없이도 알 수 없습니다. 믿기 ​​어려울 수 있지만 물론 최상의 알고리즘을 선택하는 것은 모든 루틴에 대해이 시점을 추정 하고이 추정에 따라 구현을 선택하는 것보다 훨씬 쉽습니다.

또한 사용자 경험 기본 사항을 읽으십시오. 응답 시간 (10ms, 100ms, 몇 초 등)에 따라 프로그램과의 상호 작용을 인식하는 방법을 결정하는 잘 연구 된 임계 값이 있습니다. 이러한 임계 값 중 하나를 초과하면 사용자가 응용 프로그램에서 분리 될 수 있으며, 사람들 이 사용해야 하는 독점 소프트웨어를 작성하는 데 만족하지 않으면 분리 된 사용자는 고객 손실로 이어지기 때문에 부정적인 비즈니스 가치로 직접 전환됩니다.

전문 프로그래머 가 알고리즘 복잡성에 대해 알고 책임감있게 처리 해야하는 몇 가지 이유가 여기에 있습니다. 요즘에는 시간이 걸리는 내부 루프로 밝혀지지 않은 경우 일반적으로 방해가되지 않고 프로그램에 최적화되고 잘못 읽을 수있는 코드를 프로그래밍 할 필요가 없지만, 반드시 필요한 것보다 복잡한 클래스를 호출해서는 안됩니다. 작업을 수행합니다.

그렇습니다!

예를 요청 했으므로 매일 여러 상황이 떠 오릅니다.

1. 빅 데이터 처리 : 많은 비즈니스 응용 프로그램은 데이터베이스에 의해 지원되며 많은 경우 이러한 데이터베이스는 데이터로 오버플로됩니다. 그리고 드라이브 공간이 저렴하기 때문에 기록 및 저장된 데이터의 양은 미칩니다. 지난 주 고객은 평균 수치 (약 백만 행 이상 쿼리)를 표시 할 때 그의 응용 프로그램이 너무 느리다고 불평했습니다. 시간. 작년에 알고리즘 최적화를 통해 한 배치의 처리 시간이 8 시간에서 4 시간으로 줄어 들었습니다. 이제 더 이상 주간 근무 시간과 충돌하지 않습니다!

2. 응답 성 : 사용자 만족도가 응답 성과 크게 관련이 있다는 사용성 연구가 있습니다 (시간이 있으면 ux.se ... 관련 질문에 대한 링크를 추가 할 것입니다). 200ms와 400ms의 응답 시간 차이로 인해 많은 고객이 쉽게 경쟁 업체를 떠나게됩니다.

3. 임베디드 시스템 : 컴퓨터는 점점 더 빨라지지 않고 점점 더 작아지고 있습니다 ^ _ ^ 모바일 개발은 응용 프로그램 개발에 큰 영향을 미칩니다. 현대 데스크탑 컴퓨터에서 젤리 빈과 같은 메모리와 CPU 사이클을 처리 할 수는 있지만 이제 상사는 수면 분석 알고리즘을 괴물 시계 또는 SIM 카드에서 구현하도록 요청합니다 ...

실제로 오늘날 일반적인 비즈니스 프로그램에서 성능이 중요합니까?

일반적인 비즈니스 프로그램이 무엇인지 모르겠습니다. 내가 아는 것은 사용자가 항상 계획 한 것보다 훨씬 많은 데이터를 프로그램에 공급함으로써 (종종 크기가 크거나 보안 마진이 추가 된 후) 사용자는 프로그램의 선형 증가를 기대한다는 것입니다. 런타임, 로그온 동작을 수락하고 다른 일이 발생하면 응용 프로그램이 중지된다고 불평합니다. 그리고 그것으로부터 명백한 곳 이상의 경우 예외 입력 크기보다 결과의 크기를 고려하는 경향이 그 모든 입력 데이터를 처리 할 수 있는지 POV.

그렇습니다. 최소한 복잡한 수준의 성능이 중요합니다. 복잡성 클래스 내부의 미세 최적화는 경쟁보다 눈에 띄게 나쁘지 않은 경우를 제외하고는 실제로 중요하지 않습니다 (일부 시장의 벤치 마크 또는 원시 인식에 의해 진행됨). "다른 것으로 전환하지 마십시오", "사용자가 동작 흐름을 방해 할 위험이있는 다른 것으로 전환 할 수있을 정도로 느리게", "사용자가 작업을 시작한 다음 수시로 확인하기에 충분히 느리다", "천천히 느리다 사용자가 점심, 밤, 주말에 작업을 시작할 계획입니다 ").

현대 비즈니스 애플리케이션에서 성능 문제는 CPU 또는 메모리 부족의 형태가 아닙니다. 그러나 이들은 네트워크 대기 시간, I / O 성능 및 추상화의 형태로 모든 것을 숨 깁니다. 그것은 모두 디자인의 우수성과 개발자의 경험에 달려 있습니다. 간단한 CRUD 응용 프로그램조차도 쿼리를 실행하는 대신 (N + 1 문제라고도 함) 한 번에 한 행씩 DB에서 가져 오는 경우 중지로 크롤링 할 수 있습니다.

문제는 좋은 디자인과 숙련 된 개발자가 비싸다는 것입니다. 그리고 실제 성능 최적화에 투자하는 것보다 자극적 인 사용자를 갖는 것이 일반적으로 훨씬 저렴합니다. 고객이 고성능 (예 : 웹 브라우저)을 요구하지만 일반적인 비즈니스 응용 프로그램에는 거의 적용되지 않는 경우가 있습니다.

서버 기반 응용 프로그램의 경우 수백, 수천 또는 수백만 명의 사용자가 동시에 작업을 시도 할 수 있습니다. 이러한 상황에서 효율성을 조금만 줄이면 요청을 처리하는 데 필요한 하드웨어 양에 큰 영향을 줄 수 있습니다.

확실히 중요합니다.

주요 문제는 심지어 GUI 요소를 두 번 또는 세 번 (이 초과 인출 할 때 불필요한 지연이 발생로서, 사용자에 대한 성가신 것에 대해하지 않는 프로그램이 수행하는 너무 오래 걸리기 때문에 통합 그래픽에 문제!) 또는 단순히 ... 무엇을 않습니다 (주로 관심없는 것들). 물론 문제이기도합니다.

세 가지 중요한 오해가 있습니다.

1. 대부분의 일반적인 업무용 컴퓨터는 "훨씬 더 강력 하지 " 않습니다 . 일반적인 업무용 컴퓨터는 킥업 그래픽 카드와 16GB RAM을 갖춘 8 코어 i7 이 아닙니다 . 미드 클래스 모바일 프로세서, 통합 그래픽, 2GB의 메인 메모리 (운이 좋으면 4GB), 5400RPM 디스크 및 다양한 실시간 안티 바이러스 및 정책 시행 소프트웨어가 설치된 엔터프라이즈 버전의 Windows를 갖춘 노트북입니다. 배경. 또는 대부분의 컨설턴트에게 "컴퓨터"는 단순히 iPhone입니다.
2. 대부분의 "일반적인 비즈니스 사용자"는 기술자가 아니며 10-12 개의 상호 참조 탭, 150 개의 열 및 30,000 개의 행이있는 스프레드 시트를 만드는 데 따른 영향을 이해하지 못합니다 (이 수치는 예상보다 비현실적이지 않습니다!). 어느 쪽도 알고 싶지 않습니다. 그들은 그냥 할 것입니다.
3. 두 번째 손실은 비용 이 들지 않습니다 .

아내는 "일반적인 비즈니스 환경"의 상단에서 일합니다. 그녀가 사용하는 컴퓨터는 작업 시간의 약 3.5 시간이 소요됩니다. Microsoft Outlook을 시작하려면 준비가 될 때까지 약 3 분이 걸립니다 (서버로드가 많은 경우 분기말에 6-8 분). 언급 된 30k- 행-스프레드 시트 중 일부는 컴퓨터가 "동결"된 값을 업데이트하는 데 2-3 초가 걸립니다 (Excel을 시작하고 처음 여는 데 걸리는 시간은 말할 것도 없습니다!). 데스크톱을 공유 할 때 더욱 악화됩니다. 나도 SAP에 갈 수 없습니다.
십만 명이 각각 하루 동안 20-25 분씩 아무것도 잃지 않고 지는지 여부는 중요합니다. 그들은 수백만을 잃었다이를 잃지 않고 배당금으로 지불하거나 더 높은 임금을 지불 할 수 있습니다.
물론, 대부분의 직원은 급여 규모의 하한에 있지만 하한 시간 에도 돈 입니다.

수십 년 전에 그것이 왜 중요한지 이해할 수 있습니다. 컴퓨터는 속도가 훨씬 느리고 메모리가 훨씬 적으므로 이러한 것들에 대해 신중하게 생각해야했습니다.

N ^ 2가 얼마나 빨리 성장하는지 과소 평가하는 것 같습니다. 컴퓨터가 있고 N = 10 일 때 N ^ 2 알고리즘은 10 초가 걸립니다. 시간이 지남에 따라 원래 프로세서보다 6 배 더 빠른 새 프로세서가 있으므로 이제 10 초 계산이 2 초 미만입니다. 원래 10 초 실행 시간에 N이 얼마나 더 크고 여전히 맞을 수 있습니까? 이제 24 개 항목을 처리 할 수 ​​있습니다. 시스템이 10 배 많은 항목을 처리하는 데 얼마나 빠릅니까? 글쎄요, 그것은 100 배 더 빨라야합니다. N ^ 2 알고리즘의 컴퓨터 하드웨어 진행률을 지우는 것보다 데이터가 매우 빠르게 커집니다.

우리는 직장에서 사용하는 타사 비즈니스 프로그램의 양을 믿지 않을 것입니다. 많은 사람들이 내 개인 표준에 비해 엄청나게 사용하기가 느립니다. 만약 프로그램이 내가 집에서 사용하는 것이라면, 나는 오래 전에 대안으로 대체했을 것입니다.

일부 프로그램은 하루 동안 수행 할 수있는 작업 수에 직접 영향을 미치므로 생산성과 청구 가능한 항목의 양이 줄어들 기 때문에 차이가 비용에 직접 영향을 미칩니다. 따라서 비즈니스 프로그램도 소득 제한 항목이되지 않을 정도로 성능이 뛰어나야합니다.

작업이 15 분 간격 (서비스 데스크)으로 측정되는 인시던트 관리가 그 예입니다. 프로그램이 하나의 티켓을 15 분 이상 (실제 작업 포함) 이상으로 밀어 낼 수있을 정도로 느리면 프로세스 속도가 상당히 느려집니다. 한 가지 원인은 사용자가 작업을 수행 할 때마다 (일부 해결 세부 정보, 작업 정보 업데이트 등) 데이터베이스 연결이 느려질 수 있습니다. 나는 느린 프로그램이 긴급한 중독 사례에 대한 병원 환자의 세부 사항과 같은 더 중요한 것들에 영향을 미칠 수 있다고 상상할 수 있습니다.

다른 답변들 대부분은 주제를 아주 철저히 다루기 때문에 그 이유와 근거에 대해서는 그것들을 연기합니다. 대신 알고리즘 선택이 실제 영향을 미칠 수있는 방법을 보여주는 실제 예제를 제공하고자합니다.

http://windowsitpro.com/windows-xp/svchost-and-windows-update-windows-xp-still-problem

링크 된 기사에서는 Windows XP 업데이트를 계산하는 알고리즘의 버그에 대해 설명합니다. 대부분의 Windows XP 수명 동안 업데이트 알고리즘이 제대로 작동했습니다. 이 알고리즘은 패치가 최신 패치로 대체되었는지 여부를 계산하므로 설치할 필요가 없습니다. 그러나 결국 업데이트 된 업데이트 목록이 매우 길어졌습니다 *.

업데이트 알고리즘은 기하 급수적이며, 각 새 업데이트는 이전 업데이트보다 계산하는 데 두 배가 걸렸습니다 ( ). 목록이 40 개의 업데이트 범위 (* long )에 도달하면 전체 용량으로 실행하여 업데이트를 확인하는 데 최대 15 분이 걸렸습니다. 이로 인해 업데이트 중에 많은 XP 시스템이 효과적으로 잠겼습니다. 더 나쁜 것은 업데이트를 설치하려고 할 때 알고리즘이 다시 실행 되어 15 분이 더 걸립니다. 많은 시스템에 자동 업데이트가 설정되어 있기 때문에 부팅 할 때마다 15 분 동안 그리고 특정주기에 다시 시스템을 잠글 수 있습니다.O(n) = 2n

Microsoft는이 문제를 해결하기 위해 단기 해킹 (업데이트 목록에서 항목 제거)과 장기 수정 사항을 모두 사용했습니다. 최신 버전의 Windows에서도 동일한 알고리즘을 사용하고 있기 때문에 언젠가 같은 문제에 직면 할 수 있기 때문에 중요했습니다.

여기서 알고리즘의 선택이 실제로 영향을 미쳤음을 알 수 있습니다. 잘못된 알고리즘은 대부분의 제품 수명 동안 훌륭하지만 여전히 도로에 부정적인 영향을 줄 수 있습니다.

성능 향상이 어렵다는 것을 인식하는 대신 비즈니스 앱의 성능 요구 사항이 중요하다는 표시로 성능에 대한 질문을 해석하고 있다고 생각합니다 . 그냥 작동시키는 것은 무차별 대입 기술, 시행 착오 또는 예제 코드 복사 및 붙여 넣기로 수행 할 수 있습니다.

운이 좋으면 무언가 더 빨리 실행될 때까지 계속 변경을 할 수 있지만 거의 작동하지 않습니다. 경험 부족으로 인해 개발자들은 외부의 도움을 보게 될 것입니다. 일부 환경에서는 성능 향상이 고유 한 문제이므로 StackOverflow와 같은 사이트에서 특정 질문을하는 것이 유일한 옵션 일 수 있습니다. 또한 많은 컨설턴트들이 이러한 종류의 문제를 해결하고 해결함으로써 돈을 벌고 있습니다.

"좋은 성능"을 정의하는 방법에 크게 의존합니다. 알고리즘은 항상 최상의 복잡성을 사용해야합니다. 허점을 남용하여 평균 케이지 속도를 높이십시오. 대화식 프로그램에서 가능한 경우 버퍼 및 사전로드 / 사전 컴파일.

"좋은 성능"에 대한 또 다른 정의가 있습니다 : 복잡성 클래스의 상수 최적화. 여기에서 C ++이 타이틀을 얻었고, 사람들이 자바를 느리게 부르기 시작했습니다. 런타임이 5 % 줄어 들었습니다. 이 정의를 사용하면 맞습니다. 컴퓨터 하드웨어는 시간이 지남에 따라 복잡해지고 컴파일러는 더 나아지고 향상됩니다. 어떤 시점에서는 컴파일러보다 로우 엔드 코드를 더 잘 최적화 할 수 없으므로 알고리즘에 집중하십시오.

이 시점에서 Java / Haskell / C ++를 사용하는 것은 또 다른 디자인 결정이되었습니다. 숫자 크런치는 GPU의 OpenCL을 통해 수행 할 수 있습니다. 사용자 인터페이스에는 일정한 시간 알고리즘이 필요하며 좋습니다. 캐시 활용도를 20 % 향상시키기 위해 클래스를 정렬하는 것보다 출력 및 모듈성이 중요합니다. 사람들은 빠른 앱을 원하지 않고 반응적인 앱을 원하기 때문에 멀티 스레딩이 중요해집니다. 중요하지 않은 것은 앱이 지속적으로 10 % 느리다는 것입니다. 50 %도 괜찮습니다 (그러나 사람들은 질문을하기 시작합니다). 정확성, 응답 성 및 모듈성에 집중하십시오.

나는 Haskell 또는 최소한 기능적인 형태 (C ++에서도)로 프로그래밍하는 것을 좋아합니다. 전체 프로그램에 대해 쉽게 테스트를 작성할 수있는 것이 배치 작업에서 조금 더 빠르는 것보다 훨씬 중요합니다.

아주 간단합니다 : 비용

이전 고용주는 물리적 서버에서 SaaS 모델로 호스팅되는 학습 관리 시스템을 가지고있었습니다. JVM의 힙은 이전 머신의 경우 2GB, 최신 머신의 경우 3GB로 구성되었으며 머신 당 여러 인스턴스를 실행했습니다. 충분하다고 생각할 것입니다.

시작하기 전에 시스템의 응답 성과 확장 성을 책임지는 성능 팀이있었습니다. 그들은 우리가 데이터베이스에서 지속적으로 쿼리하는 특정 데이터 조각이 있음을 발견했습니다. 하나의 열을 검색하기 위해 대부분의 쿼리에 결합한 테이블도 하나있었습니다. 그 데이터는 거의 바뀌지 않았습니다.

문제는 2GB가 필요하다는 것입니다. 따라서 확실한 해결책은 자주 읽는 데이터를 모두 캐시하는 것입니다. 그런 다음 탑승 직전에 메모리 문제가 발생했습니다.

이것에 대해 2 개의 학교가 있습니다 :

1. 요즘에는 메모리와 하드웨어가 일반적으로 저렴합니다. 더 많은 RAM을 구입하면 더 많은 캐시를 할 수 있습니다.
2. 학습 관리 시스템에 3GB 이상의 RAM이 필요한 이유는 무엇입니까? SQL 쿼리를 실행하고, 코스를 시작하기위한 리디렉션을 보내고, 코스를 통한 학생의 진행 상황을 평가합니다.

두 번째 논증이 나왔고 메모리 사용량을 조정하는 데 1 년이 걸렸습니다.

현재 고용주는 학습 관리 시스템을 호스팅하지만 조금 다르게 호스팅합니다. 확장 성이 너무 낮아 단일 설치 (4 개의로드 밸런싱 된 가상 서버에 분할)는 80 명의 고객 만 처리 할 수 ​​있습니다. 더 큰 규모의 고객 중 일부는 자체 서버 세트를 갖습니다. 이를 초래하는 대부분의 문제는 모든 CPU주기를 낭비하는 SQL 쿼리, 메모리 누수, 동일한 일을 여러 번 수행하는 중복 코드와 같은 성능 문제입니다. 우리는 서버가 제대로 작동하지 않을 때 서버를 다시 시작하는 것이 유일한 목적인 사내 앱도 구축했습니다. 해당 도구를 유지 관리하는 직원이 있습니다 (다른 책임과 함께).

그들은 위에서 언급 한 첫 번째 생각에 가입했습니다. 하드웨어 비용이 개발자 급여보다 저렴하기 때문에 더 많은 하드웨어를 던져야합니다.

이것은 예상만큼 경제적으로 효과가 없었습니다. 하드웨어, 소프트웨어 라이센스 및 지원 담당자 사이에서 서버를 처리 하기 위해 개발자가 코드 프로파일 링에 시간을 소비하지 않도록 매년 수백만 달러를 소비했습니다.

입사했을 때 가용성 문제를 해결해야했습니다. 대부분의 가용성 문제는 성능 저하로 인한 것이 었으므로 코드 성능을 조정하고 확장 성이 크게 향상되어 가동 시간이 훨씬 향상되었습니다. 밀도를 높일 준비가되었습니다. 말할 것도없이, 내 급여는 백만에 가까운 곳이 아니므로 코드를 조정하는 데 돈을 쓰면 연간 수백만 달러를 절약하게됩니다.

TL; DR

철저한 비용 / 혜택 분석을 수행하면 코드를 수정하는 것이 더 저렴하다는 것을 알 수 있습니다. 무시하는 알려진 성능 문제는 기술 부채 로 바뀝니다 .

나는 당신의 질문을 다음과 같이 이해했습니다 : 충분한 성능을 달성하려면 (예 : 사용자가 행복하고 백엔드가 울지 않습니다) 알고리즘 복잡성 이론을 이해해야합니까?

"일반적인"비즈니스 응용 프로그램의 의미에 따라 다릅니다. 많은 경우, 특히 간단한 CRUD와 같은 정보 시스템에서는 대답이 '아니오'입니다. 이를 위해 당신은 "간단하게"(때로는 어렵다) 성능 병목 현상을 추적 할 수 있어야한다 : 데이터베이스에서 인덱스가 빠졌는가? 네트워크를 통해 너무 많은 데이터를 보내나요? 내 angular.js 프런트 엔드에 천 달러의 시계가 있습니까? 이것은 건전한 아키텍처를 구축하고 기술 스택을 잘 알고 있으며 말도 안되는 것을 피하는 것입니다. 훌륭한 과학자라면 반드시 컴퓨터 과학자 일 필요는 없습니다. 또 다른 방법은 Oracle 쿼리 최적화 프로그램을 작성한 사람들이 알고리즘 복잡성 문제를 처리했기 때문에 그들이 제공 한 것을 올바르게 사용해야하기 때문입니다.

이제 예외가 있습니다. 빅 데이터 또는 머신 러닝에 대해 이야기하는 경우 사용 가능한 기본 알고리즘 만 사용하는 것이 아니라 현재 수행중인 작업을 알아야합니다. 프론트 엔드에서도 고급 데이터 시각화를 구축하기 시작하면 그 중 일부는 선형이 아닌 복잡성 비용 (예 : 강제 레이아웃 차트)을 암시 할 수 있습니다.

오늘날 이러한 예외는 점점 일반화되고 있으며이를 처리 할 수있는 사람들을 찾을 때 시장은 매우 건조합니다. 예 : 컴퓨터 과학에 대한 지식이 없어도 성공할 수 있지만 더 많은 지식을 얻을 수 있습니다.

다른 응답자들은 대부분의 기본 사항을 다루었지만 병렬화 할 수있는 작업의 경우 비효율적 인 소프트웨어로 인해 더 많은 서버의 형태로 하드웨어 비용이 증가하여 더 많은 전력을 사용하고 더 많은 공간과 유지 관리가 필요합니다.