2011-03-05 2 views
5

저는 미국의 주요 대학 웹 마스터입니다. 우리는 지난 7 년 동안 우리가 구축하고 책임지고있는 웹 사이트에 많은 요청을했습니다. 필자는 웹 사이트에 점점 더 복잡한 기능을 구축 해왔고, 저장 프로 시저, 뷰 등을 사용하여 가능한 한 멀티 프로세서 Microsoft SQL 서버에 많은 프로그래밍 부담을 가하는 것은 항상 필자의 연습이었습니다. IIS 웹 서버에서 PHP, ASP 또는 Perl로 수행 할 수없는 작업. 두 서버 모두 매우 강력하고 기능이 뛰어난 컴퓨터입니다. 다른 누구도 브레인 스토밍을하지 않고 오랫동안 혼자서이 작업을 해왔으므로 장래에 더 높은로드 상황에 이상적이라면 궁금합니다.더 나은 방법 : SQL 또는 웹 서버에로드를 배치 하시겠습니까?

내 질문입니다 : 중첩 된 SELECT 문, 뷰, 저장 프로 시저 및 집계 함수를 사용하여 SQL Server에 더 많은 부하 부담을 가하는 것이 더 좋은 방법입니까 아니면 여러 개의 간단한 쿼리를 가져 와서 서버를 사용하여 처리해야합니까? PHP와 같은 컴파일 타임 스크립트가 있습니까? keepin '에 계속 또는 더 나은 방법을 생각해 내?

로드 트레이스를 수행하고 SQL 서버의 어깨에 얼마나 많이 얹어 놓았는지 알게 된 후 최근 성능에 관심을 갖게되었습니다. 웹 서버와 SQL 서버는 하루 종일 빠르며 반응 속도가 빠르며, 내가 얼마나 많이 넣었는지에 관계없이 거의 준비가되어 있고 자신을 훈련시키고 기존 코드를 최적화하여 모범 사례를 염두에두고 업그레이드했습니다. 그것이 중요해질 때.

귀하의 조언과 의견을 보내 주셔서 감사합니다.

답변

9

스택의 각 레이어를에 가장 적합한 도메인에서 사용하는 으로 지정합니다.

데이터베이스 서버가 1000 개의 행을 보내고 WHERE 절 또는 GROUP 절로 충분할 경우 PHP를 사용하여 필터링 할 필요가 없습니다. 데이터베이스를 호출하여 두 개의 정수를 추가하는 것은 좋지 않습니다 (SELECT 5+9은 잘 작동하지만 PHP가 자체적으로 수행 할 수 있으며 왕복을 저장합니다).

확장 성 : 여러 프로세스로 분할 할 수있는 응용 프로그램의 부분은 무엇입니까? 여전히 2 개의 레이어 (스크립트 & db)를 사용하고 있다면, 거기에 확장을위한 많은 공간이 있습니다. 하지만 항상 병목 현상부터 시작.

예 : CDN의 정적 컨텐츠 호스트, 페이지 캐싱, nginx 및 memcached 읽기, nosql (mongoDB) 사용, 샤딩 고려, 복제 고려.

+0

감사합니다. Konerak. 그 중 많은 것들이 무엇인지조차 알지 못한다는 것을 고려할 때, 나는 나보다 앞선 진짜 연구 작업을 가지고 있습니다. 지금까지는로드에 관심을 기울일 필요가 없었습니다. 모든 것이 꽤 순조롭게 진행되었습니다. 코드에서 효율성을 중요시하기 때문에, 지금 습관에 들어가서 여기에서하는 일을 배우는 것은 내가 지금 감당할 수있는 멋진 사치. 팁 주셔서 감사. 나는 그들을 잘 활용할 것입니다. – Brak

4

제 생각에는 일반적으로 웹 서버에 처리를 맡기는 것이 가장 좋습니다. 2 점 :

첫 번째는 확장 성입니다. 응용 프로그램에서 충분한 사용량을 확보하면로드 균형 조정에 대한 걱정을 시작해야합니다. 그리고 분산 데이터베이스 클러스터를 설정하는 것보다 일반적인 데이터베이스를 가리키는 몇 가지 추가 웹 서버를 사용하는 것이 훨씬 쉽습니다. 가능한 한 데이터베이스에서 많은 부담을 덜어 가능한 한 오랫동안 단일 시스템에 보관하는 것이 가장 좋습니다.

두 번째 요점은 쿼리를 최적화하는 것입니다. 이것은 사용중인 쿼리와 데이터베이스 백엔드에 따라 크게 달라집니다. 필자가 데이터베이스 작업을 처음 시작했을 때, 4 개 또는 5 개의 다른 테이블에서라도 정확히 원하는 데이터를 가져온 여러 JOIN으로 정교한 SQL 쿼리를 작성하는 함정에 빠져 들었습니다."그게 바로 데이터베이스가있는 이유입니다. 열심히 일하게하십시오"

나는 이러한 쿼리가 너무 오래 실행되어 다른 요청으로부터 데이터베이스를 차단하는 결과를 가져 오는 것으로 나타났습니다. 쿼리를 여러 요청 (예 : for 루프)으로 분할하는 것이 비효율적 일 수는 있지만 빠른 인덱스를 사용하여 여러 개의 작은 쿼리를 실행하면 응용 프로그램이 모든 고된 작업을 전달하는 것보다 훨씬 원활하게 실행됩니다.

+0

잘 찍었습니다. 그것은 많은 의미가 있습니다. 당신의 이전의 사고 방식은 제가하고있는 일과 거의 똑같습니다. 그리고 그것은 제가해야 할 방향에 대한 멋진 그림을 그립니다. 귀하의 의견을 보내 주셔서 감사합니다. – Brak

+0

정말요? 작은 크기의 루프에서도 작고 간단한 쿼리는 동일한 데이터를 얻기 위해 큰 조인보다 빠를 수 있습니까? 이봐 요, 저는 루프에서 질의가 나쁜 일이라는 두려움 때문에 조인을 만들기 위해 농구를 뛰어 넘었습니다. 물론 필자는 괜찮은 벤치마킹을 통해 모든 테스트를 수행 할 수 있었지만 단일 조인 쿼리가 대안보다 더 빨리 진행될 것이라는 점을 비교하지 않았습니다. 하지만 그렇지 않나? 스레드/응답을 납치하고 싶지는 않지만이 점에 대한 추가 의견은 환영받을 것입니다. –

+0

@David Weinraub : 단 하나의 조인은 아닙니다. (데이터베이스 설계에 뭔가 잘못되어 있지 않는 한). 나는 당신이 모든 곳에서 데이터를 뜯어 낼 때 그것을 한꺼번에 가져 오는 하나의 모 놀리 식 문장을 쓰려는 충동에 저항해야한다는 것을 의미했습니다. 베스트 프랙티스의 예를 보려면 CakePHP, Ruby on Rails 등의 다양한 개발 프레임 워크를 확인하고 먼 저 관련 데이터를 가져 오는 방법을 살펴보십시오. –

0

먼저 클라이언트 측 캐싱 (.js, .css, 정적 HTML 및 이미지)으로 완전히 제거 할 수있는로드가 있는지 확인하고 AJAX와 같은 기술을 사용하여 화면의 부분 업데이트 - 웹 서버와 SQL 서버 모두에서로드가 제거됩니다.

둘째, 웹 서버 캐싱으로 줄일 수있는 SQL로드가 있는지 확인하십시오. 정적 또는 낮은 새로 고침 데이터 - 시스템에 많은 '콘텐츠'페이지가있는 경우 더 많은 사용자가 페이지를 다시 작성하거나 데이터베이스에 도달하지 않고 동일한 데이터를 볼 수 있도록 확장되는 일반적인 CMS 캐싱 기술을 살펴보십시오.

+0

감사합니다. 지난 몇 년 동안 더 많은 AJAX 및 JSON 데이터베이스 호출을 실제로 시작했는데 두 서버의 속도와 부담이 줄어들어 매우 유용한 조언이었습니다. 클라이언트 측 처리는 서버 측 처리보다 훨씬 저렴합니다. 나는 자바 스크립트, AJAX/JSON 및 PHP 명령에 내 옛날 전체 페이지의 Perl 코드를 많이 재 작성 해왔다.여전히 PHP에서 내 데이터베이스 호출 중 일부는 복잡한 SQL 쿼리, 중첩 된 쿼리를 실행하는 EXEC 등을 요청하고 있습니다. 캐싱에 관심이있어 확실히 살펴 봐야 할 것입니다. – Brak

0

DB 외부에서 가능한 한 많이 처리하는 경향이 있습니다. DB 호출을 비용이 많이 드는/시간 집약적 인 것으로 봅니다.

예를 들어 name_given 및 name_family 필드가있는 사용자 테이블에서 select를 수행 할 때 연결을 기반으로 작성된 full_name 열을 반환하도록 쿼리를 늘릴 수 있습니다. 그러나 서버 측 스크립팅 언어 (PHP, Ruby 등)의 모델에서 이러한 종류의 작업을 쉽게 수행 할 수 있습니다.

물론 db가 작업을 수행하는 데 "자연스러운"장소 인 경우가 있습니다. 그러나 일반적으로 웹 서버에 부하를 가하는 방향으로 기울이고 다른 답변에서 언급 된 많은 기술을 사용하여 최적화합니다.

+0

Heh, 나는 많은 경우에 나의 서버에서 그런 일을했다. 그러나 그렇게해야 할 SQL의 이유가있는 경우에만, 마치 연결된 것부터 정렬하거나 그룹화해야하는 것처럼 말이다. 내가하는 일 중 하나는'user_name_first, user_name_last, user_alias, COALESCE (user_alias, user_name_first) AS userNameFirst'입니다. 그렇게하면 이미 사용자의 선호 이름이있는 레코드 백을 얻을 수 있습니다. – Brak

+0

연결된 필드로 정렬하거나 필터링하는 경우 추가 필드를 추가하고 행을 삽입 할 때 결합을 수행하는 것이 가장 좋습니다. 이렇게하면 쿼리를 실행할 때마다 모든 행에서 연결을 수행 할 필요가 없으므로 새 필드를 인덱싱하고 쿼리 비용을 크게 줄일 수 있습니다. 이 기능의 이점은 몇 가지 (예 : 행 수, 행 업데이트 빈도 등)에 따라 달라 지지만 쿼리를 EXPLAINing하고 가격을 절약 할 수 있는지 확인하십시오. –

관련 문제