93. 성능(중급) : Performance, 성능 최적화, 빠른 로딩 팁, 페이지 로딩 순서

앱 구축 방식에 따라 Bubble 앱의 성능과 확장성이 큰 영향을 받습니다. 이 섹션에서는 앱 성능 및 확장성에 대한 개요를 제공하고 몇 가지 구체적인 팁을 제공합니다.

 

(1) 성능 최적화의 일반 원칙 및 팁

1. 가져오는 데이터가 적을수록 성능은 더 빨라집니다.

• 페이지는 로드 시 일부 데이터를 가져와야 하는 경우가 많습니다.
• 페이지 로드 시 100개의 항목을 가져오는 페이지는 1백만 개의 데이터 항목을 가져오는 페이지보다 더 빠르게 로드됩니다.
• 마찬가지로 숫자와 같은 간단한 데이터 유형을 가져오는 것이 ‘메가’ 단위의 데이터를 가져오는 것보다 빠릅니다.

 

2. 복잡한 페이지가 간단한 페이지 보다 더 느립니다.

• 작고 간단한 페이지를 많이 갖는 것이 더 적은 수의 복잡한 페이지를 갖는 것보다 빠릅니다.

 

3. 최대한 원래 검색에 가깝게 정렬 또는 필터링을 유지합니다.

• Bubble은 여러 가지 방법으로 데이터베이스 쿼리를 최적화하지만 데이터베이스 수준에서 정렬 또는 필터를 수행하는 것은 매우 효율적입니다.
• 즉, :sort 또는 :filter를 적용하는 쿼리는 다른 종류의 결과 조작 후 정렬 또는 필터링을 사용하는 쿼리보다 더 효율적인 경향이 있습니다. (예: search:count를 수행하는 것이 search:group by보다 더 효율적입니다.)

 

4. 고급 필터를 사용하면 쿼리 속도가 느려질 수 있습니다.

• 기본 원칙은 필터(또는 정렬)가 "데이터베이스 내에서" 수행될 수 있으면 Bubble이 초기 세트를 검색한 후 수행해야 하는 필터(또는 정렬) 보다 더 빠르다는 것입니다.

*데이터베이스 내에서 수행되는 필터와 수행되지 않는 필터는 무엇입니까?

• 검색 팔레트("Do a search for"을 클릭하면 미끄러지듯 나오는 추가 사이드바)에 표시되는 필터는 데이터베이스 내에서 수행되므로 일반적으로 속도가 빠릅니다. 그러나 :filter와 함께 적용되는 필터는 일반적으로 속도가 느린 "고급" 필터입니다.

 

5. 순차적으로 연결된 쿼리는 병렬이 아닌 직렬로 실행됩니다.

• 하나의 검색 결과를 다른 검색의 제약 조건으로 사용할 수 있습니다. 이러한 검색은 병렬이 아닌 연속으로 실행되므로 첫 번째 검색에서 많은 데이터가 반환되면 두 번째 검색 속도가 느려집니다.

 

6. 기본적으로 Bubble은 많은 성능 최적화를 수행합니다.

• Bubble은 데이터베이스에서 쿼리를 실행하고, 서버에서 이미지 크기를 조정하고, 브라우저에 Javascript를 캐시 하도록 지시하는 등의 작업을 적절하게 시도합니다.
• 만약에 단순하고 작은 양의 쿼리를 실행할 때 상대적으로 느리게 실행된다고 느낀다면, 여기에 있는 지침들을 기반으로 앱의 데이터 계층 구조 또는 쿼리에 수행할 수 있는 최적화가 있는지 확인하세요

 

7. 일반적으로는 간단한 방법으로 쿼리를 표현하는 게 더 빠릅니다.

• 항상 그런 것은 아니지만 경험상 좋은 규칙입니다.
• Bubble은 가장 일반적인 패턴에 대한 데이터베이스 최적화를 위해 지속적으로 노력하고 있습니다.

 

8. 페이지를 로드할 때마다 수정되는 데이터 업데이트를 방지하세요

• 동일한 동작을 수행하기 위해 추가 데이터베이스 호출을 수행하는 것보다 element state를 변경하는 것이 더 성능이 좋습니다.

 

9. 비용이 많이 드는 계산은 숨겨진 scheduled 워크플로로 옮겨 보십시오

• 예약된 워크플로는 무거운 쿼리를 실행한 다음 나중에 사용할 수 있도록 결과를 어딘가에 저장할 수 있습니다.
• 이는 페이지 로드 시 무거운 쿼리를 실행하는 것보다 성능이 더 좋습니다.

 

10. ”Make changes to a list of X”(x리스트 변경) 워크플로 작업을 주의해서 사용하세요

• 이 작업은 짧은 항목 List를 빠르게 변경할 때 유용하지만, List의 숫자가 늘어나면 워크플로 시간이 초과될 위험이 높아집니다.
• 이 작업으로 인해 시간 초과가 발생하는 경우 대신 "Schedule API Workflow on a list”의 사용을 고려하세요
• 이는 목록을 가져와 목록의 각 항목에 대해 개별적으로 실행되도록 API 워크플로를 예약하므로(예: 위험 감소) 성능이 더 좋습니다.

 

[ 주의사항 ]

• Bubble 앱의 데이터베이스는 매우 유연하고 강력합니다. 많은 양을 저장할 수 있지만 한 필드에 너무 많은 데이터를 저장하려고 하면 해당 필드와 관련된 성능 문제가 발생할 수 있습니다.
• 예를 들어, 콘텐츠 필드가 있는 블로그 데이터 유형이 있는 경우 블로그 게시물을 잘 처리할 수 있습니다. 하지만 Wikipedia의 모든 내용을 해당 필드에 넣으려고 하면 아마 잘 작동하지 않을 것입니다!
• 보다 현실적으로, base64로 인코딩 된 이미지(많은 텍스트)를 텍스트 필드에 저장하려고 하면 성능이 저하되고 예상치 못한 동작이 발생할 수 있습니다.

 

(2) 페이지 로드 시 어떤 일이 발생하나요?

1. 페이지 로드 시 발생되는 이벤트 순서

다음은 Bubble이 페이지를 로드할 때 발생하는 대략적인 이벤트 순서입니다.

1. Bubble은 모든 element(표시 및 보이지 않음)에 대한 코드를 보냅니다.
2. 페이지에 보이는 모든 요소를 그립니다.
3. 표시되는 element에 필요한 모든 동적 데이터를 가져옵니다.

 

2. 페이지 로드 시 발생되는 이벤트의 의미

1) 보이지 않는 element는 나중에 표시될 때까지 그려지지 않습니다.

• 보이는 항목이 보이지 않는 항목의 데이터 소스를 참조하지 않는 한 계속 보이지 않음
• (하나의 보이는 요소를 사용하여 다른 보이는 요소를 덮는다고 해서 후자의 요소가 보이지 않게 되는 것은 아닙니다.)

 

2) 페이지 로드 속도의 경우 element 유형보다 element 수가 더 큰 요소입니다.

모든 element 유형은 몇 가지 예외를 제외하고 성능 측면에서 서로 상당히 유사합니다.

 

1. 반복 그룹(Repeating Group)은 레이아웃 스타일 속성에 따라 서로 다른 양의 데이터를 로드합니다. 또한 반복 그룹의 각 셀에 element가 많을수록 페이지를 렌더링 하는 데 더 많은 시간이 걸립니다.
2. 각각 2개의 element가 있는 10개의 셀로 구성된 반복 그룹은 20개의 개별 element보다 빠르지만 3개의 element보다 느립니다.
3. 중첩된 반복 그룹(반복 그룹 안의 반복 그룹)은 element 수에 곱셈 효과를 줍니다. (반복 그룹 하나보다 훨씬 느려짐)
4. 플러그인에는 사용 여부에 관계없이 각 페이지 로드에 플러그인 코드가 포함되어 있습니다. Bubble은 사용되지 않는 플러그인을 렌더링 하지 않기 때문에 성능에 큰 영향을 미치지는 않지만 일반적으로 앱에서 사용하지 않는 플러그인을 제거하는 것이 좋습니다.

 

(3) Soft Limit(소프트한 제한선)

1. Hard Limit VS Soft Limit (하드한 제한 VS 소프트한 제한)

• 다양한 제한이 프로젝트에 어떤 영향을 미칠 수 있는지 살펴보기 전에 하드한 제한과 소프트한 제한의 개념을 간략하게 살펴보겠습니다.

1) Soft Limit(소프트한 제한)

• 초과할 수 있지만 성능이나 안정성에 영향을 미칠 수 있는 유연한 한계선입니다. 소프트한 한도는 애플리케이션 구조, 요금제 등의 요인에 의해 영향을 받습니다. 예를 들어, 상당히 많은 양의 데이터가 포함된 데이터베이스 레코드가 많으면 검색 성능이 저하될 수 있습니다.

2) Hard Limit(하드 한 제한)

• 초과할 수 없는 고정된 경계선입니다. 일부 엄격한 제한은 더 높은 가격 플랜으로 업그레이드하여 늘릴 수 있고, 다른 제한은 사려 깊은 앱 디자인과 최적화를 통해 피할 수 있지만, 개발자는 이러한 제한이 프로젝트에 어떤 영향을 미칠 수 있는지 알고 있어야 합니다.

94. Hard Limit (중급) : 버블의 성능 제한, 최대 텍스트 길이, 파일 크기, 최대 이벤트 액션 수, 최대 a

 

2. 시간 초과(Time out)

• 특정 작업을 완료하는 데 너무 오랜 시간이 걸려 시스템에 의해 종료되면 시간 초과(Time out)가 발생할 수 있습니다. 단일 요청이나 앱이 서버 리소스를 독점하는 것을 방지하고 공유 서버의 모든 애플리케이션의 응답성과 성능을 원활하게 유지하도록 Timeout이 발생됩니다.

3. 한계 예측 및 계획

• 모든 데이터베이스 시스템과 마찬가지로 Bubble 서버에 압력을 가할 때 발생하는 속도 저하, 시간 초과 및 오류는 예측하고 계획하기 어려울 수 있으며 앱 설계 방식과 작업 중인 데이터 양에 크게 좌우됩니다.
• 시간 초과(Timeout)는 드물지만 예측하기 어려울 수 있으며 프로세스가 완료되기 전에 종료되어 데이터 손실 및 기타 결과가 발생할 수 있습니다.
• 발생할 수 있는 엄격한 제한을 문서화할 수 있지만 소프트 제한은 앱이 수행하는 작업에 따라 크게 달라질 수 있으므로 더 복잡합니다. 속도 저하 및 시간 초과 위험을 최소화하려면 복잡한 프로세스를 더 작은 단위로 나누는 것이 좋습니다.

4. Throttling(리소스 조절)과 Time out(시간 초과)

• 앱이 일정 시간 동안 거의 최대 할당 용량을 소비하는 경우 용량을 초과하지 않고 계속 실행되도록 앱이 제한될 수 있습니다.
• 이로 인해 워크플로가 느려지고 결과적으로 엄격한 Timeout(시간 초과)을 표시하는 부정적인 피드백 루프가 발생할 수 있습니다. 따라서 프로세스가 어떤 경우에는 성공적으로 완료되었지만 다른 경우에는 시간 초과될 수 있으므로 시간 초과는 예측할 수 없는 것처럼 보일 수 있습니다.
• 앱의 총용량에 대해 전체적으로 생각하고 동시 프로세스가 서로 영향을 미칠 수 있다는 점을 명심하는 것이 좋습니다. 무거운 프로세스를 가능하다면 앱의 활동량이 적은 시간(예: 활성 사용자가 적은 시간)으로 이동해 보세요

 

(4) 알려진 소프트 제한

1. SVG 이미지 크기

SVG 이미지는 해상도 손실 없이 확대 또는 축소할 수 있는 벡터 기반 그래픽을 렌더링 하기 위해 브라우저에서 구문 분석되는 XML 코드에 저장됩니다. 이는 원래 크기 이상으로 크기를 조정하면 픽셀화될 수 있는 JPEG 또는 PNG 파일과 같은 래스터 이미지와는 다릅니다.

이는 SVG 파일을 여러 상황에서 매우 유용하게 만들지만, 파일을 처리할 때 로컬 장치 속도가 느려지는 것을 방지하려면 SVG 파일에 대해 1Mb의 소프트 제한을 권장합니다.

 

2. 고급 제약 조건을 사용하여 검색

고급 제약 연산자(:filter 같은 연산자)를 사용하는 검색은 서버에 더 많은 부담을 줄 수 있습니다. 검색할 수 있는 항목에 대한 엄격한 제한은 없지만 일반적으로 10,000개가 넘는 항목에 대해 이 제약 조건을 사용하지 않는 것이 좋습니다.

 

(5) 성능에 대한 추가 참고 사항

1. 재사용의 효율성

• 페이지의 여러 위치에서 동일한 검색이 있는 경우 Bubble은 자동으로 이를 결합하여 쿼리를 한 번 실행합니다.
• 스타일을 활용하면 성능 향상에 도움이 됩니다. (Style탭에서 정의)
• 특히 무거운 검색을 실행하는 처음 몇 번은 향후 실행보다 약간 느릴 수 있습니다. 왜냐하면 Bubble이 무거운 쿼리 실행을 몇 번 확인한 후 Bubble은 향후 검색 속도를 엄청나게 높일 수 있는 인덱스를 구축하기 때문입니다(인덱스를 구축하면 최대 1시간 정도 소요)

2. A VS B

• 12개의 필드를 변경하는 작업은 하나의 필드를 변경하는 12개의 작업보다 더 효율적입니다.
• 상대적으로 작은 목록의 경우 “Change list of a things”가 빠르지만, 더 큰 목록의 경우 API 워크플로의 사용이 워크플로 시간 초과 위험이 없으므로 더 빠릅니다.
• (큰) 목록을 변경할 때 목록의 후속 항목에 대해 API 워크플로를 재귀적으로 호출하는 것은 , 전체 목록에서 한 번에 API 워크플로를 실행하는 것보다 약간 느리기는 하지만 확장성이 더 좋습니다.
• 페이지 이동 시, 워크플로에서 Action으로 페이지를 이동하면, 페이지를 변경하기 전에 다른 워크플로에서 데이터를 저장하기를 기다리기 때문에, 링크 element를 통해 새 페이지로 이동하는 것이 일반적으로 조금 더 빠릅니다.
• 데이터 유형 A가 여러 B에 연결되어 있는 경우(예: 카테고리가 있지만 게시물당 하나의 카테고리만 있는 게시물, A = 카테고리, B = 게시물), 이런 경우는 B에 해당 필드가 속한 A를 참조하는 필드가 있는 것이 일반적으로 더 좋습니다. A에 속한 모든 B를 나열하는 필드를 갖는 것은 해당 목록이 매우 길어질 때 참조 할 데이터 양이 많아 제대로 작동하지 않을 것입니다. (즉 두 데이터 휴형을 연결할 때, 미래에 많아질 데이터를 고려)
• API 워크플로의 경우 워크플로에서 조치를 취해야 하는 항목 수가 각 항목의 크기보다 성능에 더 큰 영향을 미칩니다.

 

(6) Workload(작업 용량)

1. 다양한 작업

Workload는 특정 기간 동안 앱이 얼마나 많은 '작업'을 수행할 수 있는지를 측정합니다.

1) 웹사이트 방문

• 당신의 웹 사이트를 방문하는 사용자는 약간의 용량을 사용합니다. 당신의 웹 사이트를 방문하는 수많은 사용자가 있다면 훨씬 많은 용량을 사용하게 됩니다.

2) 데이터베이스 사용

• 데이터베이스를 호출하면 용량이 사용됩니다. 많은 양의 무거운 데이터베이스 쿼리를 수행하면 훨씬 더 많은 용량이 사용됩니다.

3) 워크플로우, API 사용

• 특정 워크플로(서버에서 발생하는 워크플로)를 실행하면 용량이 사용되며, 마찬가지로 앱의 API를 호출해도 용량이 사용됩니다.

 

2. Unit

• Bubble 전반에 걸쳐 용량의 "Unit(단위)"에 대한 언급이 있습니다. "Unit(단위)"는 Bubble 시스템이 사용하는 다양한 희소 자원에 대한 가중치를 적용한 척도입니다.
• 여기에는 서버 CPU 시간, 데이터베이스 CPU 시간, 기타 백엔드 시스템 등과 같은 요소가 포함됩니다. "Unit(단위)"의 정확한 공식은 Bubble이 백엔드 시스템을 추가, 제거 또는 개선함에 따라 시간이 지남에 따라 변경됩니다.
• Bubble의 목표 중 하나는 용량 Unit(단위)이 제공하는 사용자 경험 성능을 향상하는 것입니다.

 

3. 가격체계와 제한

• 특정 Bubble 가격 체계 (무료 및 개인)에서 앱은 "Basic" 서버 용량을 갖게 됩니다. 즉, 해당 계층의 다른 모든 Bubble 앱과 동일한 컴퓨팅 리소스를 공유한다는 의미입니다.
• 앱이 "Professional" 및 "Production" 계층으로 업그레이드되면 앱은 해당 앱을 위해 예약된 전용 용량 단위를 얻습니다. 작업 용량을 초과하면 앱 속도가 제한됩니다. 다시 한번 비기술적인 용어로 말하자면, 이는 앱이 일정 기간 동안 많은 "작업"을 수행할 수 없으며 앱에 대한 사용자 요청이 느려지는 것을 의미합니다. 따라서 용량이 더 크다는 것은 일반적으로 많은 "작업"이 진행되는 경우 앱이 더 많은 "작업"을 수행할 수 있음을 의미합니다.

4. 쿼리와 작업 용량

• 남아있는 용량이 더 많다고 해서 매우 복잡한 데이터베이스 쿼리가 훨씬 더 빠르게 실행되는 것은 아닙니다. 이는 마치 한 고객이 장바구니에 많은 품목을 담아 결제하는 것과 같습니다.
• 이에 대한 주의 사항이 있습니다. 큰 쿼리가 앱의 용량을 모두 소모한다는 것을 Bubble이 감지하면 Bubble은 앱의 나머지 부분에 대해 합리적인 사용자 경험을 유지하기 위해 해당 쿼리의 속도를 늦춥니다. 따라서 특정 상황에서는 용량을 추가하면 대규모 쿼리가 더 빠르게 실행될 수 있습니다.

 

95. 쿼리에 대한 특별사항 (초급): 버블 쿼리 불용어, 형태소 분석, 쿼리의 최적화

 

5. 사용 작업 용량확인

• 사용자는 왼쪽 탐색 메뉴의 Log로 이동하여 앱이 사용하고 있는 용량을 확인할 수 있습니다.
• 첫 번째 차트는 앱이 최대 용량에 도달한 시간을 보여줍니다.
• 두 번째 차트는 최대 용량을 기준으로 앱이 사용한 용량을 보여줍니다.
• 페이지 아래에는 지난 24시간 동안 앱의 여러 부분에서 사용한 용량의 분석을 보여주는 서버 용량 사용량 세부 정보 차트가 있습니다. 앱이 느리고 용량 제한에 도달하는 경우 예약된 추가 용량을 구매하는 것이 도움이 될 수 있습니다.

 

참고사항:

• Bubble의 서버 로깅 제공업체인 AppOptics는 최대 용량 차트에 사용하는 측정항목에 제한을 두고 있습니다.
• 활동이 매우 많은 버블 앱은 장기간(예: 30일) 동안 로그를 쿼리 하려고 하면 이 제한에 도달할 수 있습니다.
• 앱에서 이런 일이 발생하면 차트 기간을 더 짧은 기간(예: 7일)으로 설정하는 것이 좋습니다.