Laravel은 많은 것입니다. 그러나 빠른 것은 그들 중 하나가 아닙니다. 거래를 더 빠르게 하기 위한 거래 요령을 배워봅시다!
어떤 PHP 개발자도 라라벨 요즘에는. 그들은 Laravel이 제공하는 빠른 개발을 좋아하는 주니어 또는 중간 레벨 개발자이거나 시장 압력 때문에 Laravel을 배워야 하는 시니어 개발자입니다.
어느 쪽이든 Laravel이 PHP 생태계를 활성화했다는 사실을 부인할 수 없습니다.
Laravel의 (다소 정당한) 자기 칭찬의 일부
그러나 Laravel은 일을 쉽게 하기 위해 뒤로 구부러져 있기 때문에 개발자로서 편안한 삶을 누릴 수 있도록 수많은 작업을 수행하고 있음을 의미합니다. 작동하는 것처럼 보이는 Laravel의 모든 “마법 같은” 기능에는 기능이 실행될 때마다 추가해야 하는 코드 레이어가 있습니다. 토끼 구멍이 얼마나 깊은지 간단한 예외 추적도 가능합니다(오류가 시작되는 위치를 확인하고 메인 커널까지 내려갑니다).
보기 중 하나에서 컴파일 오류로 보이는 경우 추적할 함수 호출이 18개 있습니다. 저는 개인적으로 40개를 만났고 다른 라이브러리와 플러그인을 사용한다면 쉽게 더 있을 수 있습니다.
기본적으로 코드 레이어에 있는 이 레이어는 Laravel을 느리게 만듭니다.
Laravel은 얼마나 느립니까?
솔직히 이 질문에 답하는 것은 여러 가지 이유로 불가능합니다.
첫째, 웹 앱의 속도를 측정하기 위한 받아들여지고 객관적이며 합리적인 표준이 없습니다. 무엇에 비해 빠르거나 느립니까? 어떤 조건에서?
둘째, 웹 응용 프로그램은 너무 많은 것(데이터베이스, 파일 시스템, 네트워크, 캐시 등)에 의존하므로 속도에 대해 이야기하는 것은 어리석은 일입니다. 매우 느린 데이터베이스를 가진 매우 빠른 웹 앱은 매우 느린 웹 앱입니다. 🙂
그러나 이러한 불확실성이 바로 벤치마크가 인기 있는 이유입니다. 아무 의미가 없더라도(참조 이것 그리고 이것), 그것들은 참조의 틀을 제공하고 우리가 화를 내지 않도록 도와줍니다. 따라서 약간의 소금이 준비되어 있는 상태에서 PHP 프레임워크 사이의 속도에 대한 잘못된 대략적인 개념을 알아봅시다.
다소 존경할만한 GitHub로 이동 원천비교했을 때 PHP 프레임워크가 정렬되는 방식은 다음과 같습니다.
케이스를 꼬리 끝까지 던지지 않는 한 여기에서 Laravel을 눈치 채지 못할 수도 있습니다. 네, 친구 여러분, 라라벨이 마지막입니다! 당연하게도 이러한 “프레임워크”의 대부분은 그다지 실용적이지 않거나 심지어 유용하지도 않지만 다른 인기 있는 프레임워크와 비교할 때 Laravel이 얼마나 느린지 알 수 있습니다.
일반적으로 이러한 “느림”은 일상적인 웹 앱이 높은 수치에 도달하는 경우가 거의 없기 때문에 애플리케이션에서는 나타나지 않습니다. 그러나 일단 그렇게 되면(즉, 200-500개 이상의 동시성) 서버가 질식하고 죽기 시작합니다. 더 많은 하드웨어를 투입해도 문제가 해결되지 않고 인프라 요금이 너무 빨리 올라가서 클라우드 컴퓨팅에 대한 높은 이상이 무너지는 시기입니다.
하지만 이봐, 힘내! 이 기사는 할 수 없는 것에 관한 것이 아니라 할 수 있는 것에 관한 것입니다. 🙂
좋은 소식은 Laravel 앱을 더 빠르게 만들기 위해 많은 일을 할 수 있다는 것입니다. 몇 배나 빠릅니다. 예, 농담이 아닙니다. 동일한 코드베이스를 안정적으로 만들고 매달 인프라/호스팅 청구서에서 수백 달러를 절약할 수 있습니다. 어떻게? 시작합시다.
네 가지 유형의 최적화
내 생각에 최적화는 4가지 개별 수준에서 수행할 수 있습니다(즉, PHP 응용 프로그램의 경우).
- 언어 수준: 이것은 더 빠른 버전의 언어를 사용하고 코드를 느리게 만드는 언어의 특정 기능/스타일 코딩을 피함을 의미합니다.
- 프레임워크 수준: 이 기사에서 다룰 내용입니다.
- 인프라 수준: PHP 프로세스 관리자, 웹 서버, 데이터베이스 등 조정
- 하드웨어 수준: 더 우수하고 빠르고 강력한 하드웨어 호스팅 공급자로 이동합니다.
이러한 모든 유형의 최적화는 각자의 자리가 있습니다(예를 들어, PHP-fpm 최적화는 매우 중요하고 강력합니다). 그러나 이 기사의 초점은 순전히 유형 2의 최적화, 즉 프레임워크와 관련된 최적화입니다.
그건 그렇고, 번호 매기기 뒤에는 근거가 없으며 허용된 표준도 아닙니다. 방금 구성했습니다. 제 말을 인용해서 “우리 서버에 3종 최적화가 필요합니다.”라고 말하지 마십시오. 그렇지 않으면 팀 리더가 당신을 죽이고, 나를 찾은 다음, 나도 죽일 것입니다. 😀
그리고 이제 드디어 약속의 땅에 도착합니다.
목차
n+1 데이터베이스 쿼리에 유의하십시오.
n+1 쿼리 문제는 ORM을 사용할 때 흔히 발생하는 문제입니다. Laravel은 Eloquent라는 강력한 ORM을 가지고 있습니다. 너무 아름답고 편리해서 무슨 일이 일어나고 있는지 보는 것을 종종 잊어버립니다.
매우 일반적인 시나리오를 고려하십시오. 지정된 고객 목록이 주문한 모든 주문 목록을 표시합니다. 이것은 전자 상거래 시스템과 일반적으로 일부 엔터티와 관련된 모든 엔터티를 표시해야 하는 모든 보고 인터페이스에서 매우 일반적입니다.
Laravel에서 다음과 같은 작업을 수행하는 컨트롤러 기능을 상상할 수 있습니다.
class OrdersController extends Controller
{
// ...
public function getAllByCustomers(Request $request, array $ids) {
$customers = Customer::findMany($ids);
$orders = collect(); // new collection
foreach ($customers as $customer) {
$orders = $orders->merge($customer->orders);
}
return view('admin.reports.orders', ['orders' => $orders]);
}
}
달콤한! 그리고 더 중요한 것은 우아하고 아름답습니다. 🤩🤩
불행히도 Laravel에서 코드를 작성하는 것은 비참한 방법입니다.
이유는 다음과 같습니다.
ORM에게 주어진 고객을 찾도록 요청하면 다음과 같은 SQL 쿼리가 생성됩니다.
SELECT * FROM customers WHERE id IN (22, 45, 34, . . .);
예상대로입니다. 결과적으로 반환된 모든 행은 컨트롤러 함수 내부의 $customers 컬렉션에 저장됩니다.
이제 각 고객을 하나씩 반복하고 주문을 받습니다. 그러면 다음 쿼리가 실행됩니다. . .
SELECT * FROM orders WHERE customer_id = 22;
. . . 고객이 있는 만큼.
즉, 1000명의 고객에 대한 주문 데이터를 가져와야 하는 경우 실행되는 총 데이터베이스 쿼리 수는 1(모든 고객의 데이터를 가져오는 경우) + 1000(각 고객의 주문 데이터를 가져오는 경우) = 1001이 됩니다. 여기서 n+1이라는 이름이 유래되었습니다.
더 잘할 수 있을까요? 틀림없이! Eager Loading이라고 알려진 것을 사용하면 ORM이 강제로 JOIN을 수행하고 필요한 모든 데이터를 단일 쿼리로 반환할 수 있습니다! 이와 같이:
$orders = Customer::findMany($ids)->with('orders')->get();
결과 데이터 구조는 물론 중첩된 것이지만 주문 데이터를 쉽게 추출할 수 있습니다. 이 경우 결과 단일 쿼리는 다음과 같습니다.
SELECT * FROM customers INNER JOIN orders ON customers.id = orders.customer_id WHERE customers.id IN (22, 45, . . .);
물론 단일 쿼리가 수천 개의 추가 쿼리보다 낫습니다. 처리할 고객이 10,000명이라면 어떤 일이 벌어질지 상상해 보십시오! 또는 모든 주문에 포함된 항목도 표시하고 싶은 경우에는 금지합니다! 이 기술의 이름은 열망 로딩이며 거의 항상 좋은 생각입니다.
구성을 캐시하십시오!
Laravel의 유연성에 대한 이유 중 하나는 프레임워크의 일부인 수많은 구성 파일입니다. 이미지가 저장되는 방법/위치를 변경하고 싶습니까?
음, config/filesystems.php 파일을 변경하기만 하면 됩니다(적어도 작성 시점에서는). 여러 큐 드라이버로 작업하고 싶습니까? config/queue.php에 자유롭게 설명하십시오. 방금 세어보니 프레임워크의 다양한 측면에 대한 13개의 구성 파일이 있으므로 무엇을 변경하든 실망하지 않을 것입니다.
PHP의 특성상 새로운 웹 요청이 들어올 때마다 Laravel은 깨어나서 모든 것을 부팅하고 이 모든 구성 파일을 구문 분석하여 이번에는 다르게 수행하는 방법을 알아냅니다. 지난 며칠 동안 아무 것도 변경되지 않았다면 그것은 어리석은 일입니다! 모든 요청에 대해 구성을 다시 빌드하는 것은 피할 수 있는(실제로는 피해야 하는) 낭비이며 탈출구는 Laravel이 제공하는 간단한 명령입니다.
php artisan config:cache
이것이 하는 일은 사용 가능한 모든 구성 파일을 단일 파일로 결합하고 캐시는 빠른 검색을 위한 어딘가에 있습니다. 다음에 웹 요청이 있을 때 Laravel은 이 단일 파일을 읽고 작업을 시작합니다.
즉, 구성 캐싱은 매우 섬세한 작업으로 얼굴을 붉힐 수 있습니다. 가장 큰 문제점은 일단 이 명령을 실행하면 구성 파일을 제외한 모든 위치에서 env() 함수 호출이 null을 반환한다는 것입니다!
당신이 그것에 대해 생각할 때 그것은 의미가 있습니다. 구성 캐싱을 사용하는 경우 프레임워크에 “그거 알아요. 설정을 잘 했다고 생각하고 변경을 원하지 않는다고 100% 확신합니다.”라고 말하는 것입니다. 즉, .env 파일이 필요한 환경이 정적으로 유지될 것으로 예상합니다.
즉, 구성 캐싱에 대한 엄격하고 신성하며 깨뜨릴 수 없는 몇 가지 규칙이 있습니다.
자동 로드 서비스 줄이기
도움이 되도록 Laravel은 깨어날 때 수많은 서비스를 로드합니다. 이들은 ‘providers’ 배열 키의 일부로 config/app.php 파일에서 사용할 수 있습니다. 내 경우에 무엇이 있는지 살펴 보겠습니다.
/*
|--------------------------------------------------------------------------
| Autoloaded Service Providers
|--------------------------------------------------------------------------
|
| The service providers listed here will be automatically loaded on the
| request to your application. Feel free to add your own services to
| this array to grant expanded functionality to your applications.
|
*/
'providers' => [
/*
* Laravel Framework Service Providers...
*/
IlluminateAuthAuthServiceProvider::class,
IlluminateBroadcastingBroadcastServiceProvider::class,
IlluminateBusBusServiceProvider::class,
IlluminateCacheCacheServiceProvider::class,
IlluminateFoundationProvidersConsoleSupportServiceProvider::class,
IlluminateCookieCookieServiceProvider::class,
IlluminateDatabaseDatabaseServiceProvider::class,
IlluminateEncryptionEncryptionServiceProvider::class,
IlluminateFilesystemFilesystemServiceProvider::class,
IlluminateFoundationProvidersFoundationServiceProvider::class,
IlluminateHashingHashServiceProvider::class,
IlluminateMailMailServiceProvider::class,
IlluminateNotificationsNotificationServiceProvider::class,
IlluminatePaginationPaginationServiceProvider::class,
IlluminatePipelinePipelineServiceProvider::class,
IlluminateQueueQueueServiceProvider::class,
IlluminateRedisRedisServiceProvider::class,
IlluminateAuthPasswordsPasswordResetServiceProvider::class,
IlluminateSessionSessionServiceProvider::class,
IlluminateTranslationTranslationServiceProvider::class,
IlluminateValidationValidationServiceProvider::class,
IlluminateViewViewServiceProvider::class,
/*
* Package Service Providers...
*/
/*
* Application Service Providers...
*/
AppProvidersAppServiceProvider::class,
AppProvidersAuthServiceProvider::class,
// AppProvidersBroadcastServiceProvider::class,
AppProvidersEventServiceProvider::class,
AppProvidersRouteServiceProvider::class,
],
다시 한 번 세어보니 27개의 서비스가 나열되어 있습니다! 이제 모든 항목이 필요할 수 있지만 그럴 가능성은 낮습니다.
예를 들어 저는 현재 REST API를 구축하고 있습니다. 즉, Session Service Provider, View Service Provider 등이 필요하지 않습니다. , Auth Service Provider, Pagination Service Provider, Translation Service Provider 등을 비활성화할 수도 있습니다. 대체로 이들 중 거의 절반이 내 사용 사례에 필요하지 않습니다.
지원서를 자세히 살펴보세요. 이러한 서비스 공급자가 모두 필요합니까? 하지만 이런 서비스를 맹목적으로 주석 처리하고 프로덕션으로 밀어붙이지 마세요! 모든 테스트를 실행하고 개발 및 준비 시스템에서 수동으로 확인하고 방아쇠를 당기기 전에 매우 편집증적입니다. 🙂
미들웨어 스택을 현명하게 사용하십시오.
들어오는 웹 요청에 대한 일부 사용자 지정 처리가 필요한 경우 새 미들웨어를 만드는 것이 답입니다. 이제 app/Http/Kernel.php를 열고 웹 또는 API 스택에 미들웨어를 붙이고 싶은 유혹이 있습니다. 그렇게 하면 앱 전체에서 그리고 방해가 되는 작업(예: 로깅 또는 알림)을 수행하지 않는 경우 사용할 수 있게 됩니다.
그러나 앱이 커짐에 따라 이러한 글로벌 미들웨어 모음이 모든 요청에 모두(또는 대부분) 존재하는 경우 비즈니스상의 이유가 없더라도 이 컬렉션은 앱에 소리 없는 부담이 될 수 있습니다.
즉, 새로운 미들웨어를 추가/적용하는 위치에 주의해야 합니다. 전역적으로 무언가를 추가하는 것이 더 편리할 수 있지만 장기적으로 성능 저하가 매우 높습니다. 새로운 변화가 있을 때마다 선택적으로 미들웨어를 적용한다면 겪어야 할 수고로움을 알지만 기꺼이 감수하고 추천하고 싶은 수고로움입니다!
ORM을 피하십시오 (때때로)
Eloquent는 DB 상호작용의 여러 측면을 즐겁게 만들어주지만 속도를 희생해야 합니다. 매퍼이기 때문에 ORM은 데이터베이스에서 레코드를 가져올 뿐만 아니라 모델 개체를 인스턴스화하고 열 데이터로 수화(채우기)해야 합니다.
따라서 간단한 $users = User::all()을 수행하고 10,000명의 사용자가 있는 경우 프레임워크는 데이터베이스에서 10,000개의 행을 가져오고 내부적으로 10,000개의 new User()를 수행하고 해당 속성을 관련 데이터로 채웁니다. . 이것은 뒤에서 수행되는 엄청난 양의 작업이며 데이터베이스가 애플리케이션이 있는 곳에서 병목 현상이 발생하는 경우 ORM을 우회하는 것이 때때로 좋은 생각입니다.
이것은 복잡한 SQL 쿼리의 경우 특히 그렇습니다. 여기서 많은 후프를 건너뛰고 클로저에 클로저를 작성해야 하지만 여전히 효율적인 쿼리로 끝납니다. 이러한 경우 DB::raw()를 수행하고 쿼리를 직접 작성하는 것이 좋습니다.
지나가다 이것 간단한 삽입의 경우에도 성능 연구 Eloquent는 레코드 수가 증가함에 따라 훨씬 느려집니다.
가능한 한 캐싱을 사용하십시오.
웹 애플리케이션 최적화의 가장 잘 알려진 비밀 중 하나는 캐싱입니다.
초보자에게 캐싱이란 비용이 많이 드는 결과(CPU 및 메모리 사용 측면에서 비용이 많이 들음)를 사전 계산 및 저장하고 동일한 쿼리가 반복될 때 단순히 반환하는 것을 의미합니다.
예를 들어, 전자 상거래 상점에서 200만 개의 제품 중 대부분의 경우 사람들은 특정 가격대 내에서 특정 연령 그룹에 대해 갓 구입한 제품에 관심을 가질 수 있습니다. 이 정보에 대해 데이터베이스를 쿼리하는 것은 낭비입니다. 쿼리가 자주 변경되지 않기 때문에 이러한 결과를 빠르게 액세스할 수 있는 곳에 저장하는 것이 좋습니다.
라라벨은 여러 유형의 지원을 내장하고 있습니다. 캐싱. 캐싱 드라이버를 사용하고 처음부터 캐싱 시스템을 구축하는 것 외에도 다음을 용이하게 하는 몇 가지 Laravel 패키지를 사용할 수 있습니다. 모델 캐싱, 쿼리 캐싱등.
그러나 특정 단순화된 사용 사례를 넘어 미리 빌드된 캐싱 패키지는 해결하는 것보다 더 많은 문제를 일으킬 수 있습니다.
메모리 내 캐싱 선호
Laravel에서 무언가를 캐시할 때 캐시해야 하는 결과 계산을 저장할 위치에 대한 몇 가지 옵션이 있습니다. 이러한 옵션은 캐시 드라이버. 따라서 캐시 결과를 저장하기 위해 파일 시스템을 사용하는 것이 가능하고 완벽하게 합리적이지만 실제로 캐싱이 의미하는 바는 아닙니다.
이상적으로는 Redis, Memcached, MongoDB 등과 같은 메모리 내(완전히 RAM에 상주하는) 캐시를 사용하여 더 높은 부하에서 캐싱 자체가 병목 현상이 되기보다는 중요한 용도로 사용되기를 원합니다.
이제 SSD 디스크를 사용하는 것이 RAM 스틱을 사용하는 것과 거의 같다고 생각할 수도 있지만 가깝지도 않습니다. 비공식적이라도 벤치마크 속도 면에서 RAM이 SSD보다 10~20배 더 우수하다는 것을 보여줍니다.
캐싱과 관련하여 제가 가장 좋아하는 시스템은 Redis입니다. 이것의 엄청나게 빠른 (초당 100,000회의 읽기 작업이 일반적임) 매우 큰 캐시 시스템의 경우 무리 용이하게.
경로 캐시
응용 프로그램 구성과 마찬가지로 경로는 시간이 지나도 많이 변경되지 않으며 캐싱을 위한 이상적인 후보입니다. 특히 저처럼 대용량 파일을 견디지 못하고 web.php와 api.php를 여러 파일로 분할하는 경우에 특히 그렇습니다. 단일 Laravel 명령은 사용 가능한 모든 경로를 압축하고 향후 액세스를 위해 편리하게 보관합니다.
php artisan route:cache
그리고 경로를 추가하거나 변경하게 되면 다음을 수행하십시오.
php artisan route:clear
이미지 최적화 및 CDN
이미지는 대부분의 웹 애플리케이션의 핵심입니다. 공교롭게도, 그들은 또한 가장 큰 대역폭 소비자이자 느린 앱/웹 사이트의 가장 큰 이유 중 하나입니다. 업로드된 이미지를 순진하게 서버에 저장하고 HTTP 응답으로 다시 보내면 막대한 최적화 기회를 놓치게 됩니다.
첫 번째 권장 사항은 이미지를 로컬에 저장하지 않는 것입니다. 처리해야 할 데이터 손실 문제가 있으며 고객이 있는 지역에 따라 데이터 전송 속도가 매우 느려질 수 있습니다.
대신 다음과 같은 솔루션을 찾으십시오. 흐림 즉석에서 이미지 크기를 자동으로 조정하고 최적화합니다.
이것이 가능하지 않다면 Cloudflare와 같은 것을 사용하여 이미지가 서버에 저장되어 있는 동안 이미지를 캐싱하고 제공하세요.
그리고 그것이 가능하지 않더라도 웹 서버 소프트웨어를 약간 조정하여 자산을 압축하고 방문자의 브라우저가 항목을 캐시하도록 지시하면 많은 차이가 있습니다. Nginx 구성 스니펫은 다음과 같습니다.
server {
# file truncated
# gzip compression settings
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_proxied any;
gzip_vary on;
# browser cache control
location ~* .(ico|css|js|gif|jpeg|jpg|png|woff|ttf|otf|svg|woff2|eot)$ {
expires 1d;
access_log off;
add_header Pragma public;
add_header Cache-Control "public, max-age=86400";
}
}
나는 이미지 최적화가 라라벨과 아무 관련이 없다는 것을 알고 있지만, 나 자신을 도울 수 없는 매우 간단하고 강력한 트릭(그리고 너무 자주 무시됩니다)입니다.
오토로더 최적화
자동 로딩은 언어를 파멸에서 구한 PHP의 깔끔하고 그리 오래되지 않은 기능입니다. 즉, 지정된 네임스페이스 문자열을 해독하여 관련 클래스를 찾고 로드하는 프로세스는 시간이 걸리며 고성능이 요구되는 프로덕션 배포에서는 피할 수 있습니다. 다시 한 번 Laravel은 이에 대한 단일 명령 솔루션을 제공합니다.
composer install --optimize-autoloader --no-dev
대기열과 친구 사귀기
대기열 많은 것들이 있고 각각 완료하는 데 몇 밀리 초가 걸릴 때 처리하는 방법입니다. 좋은 예는 이메일을 보내는 것입니다. 웹 앱에서 널리 사용되는 사용 사례는 사용자가 어떤 작업을 수행할 때 몇 개의 알림 이메일을 보내는 것입니다.
예를 들어, 새로 출시된 제품에서 누군가가 특정 금액 이상으로 주문할 때마다 회사 경영진(약 6-7개의 이메일 주소)에게 알리기를 원할 수 있습니다. 이메일 게이트웨이가 500ms 내에 SMTP 요청에 응답할 수 있다고 가정하면 주문 확인이 시작되기 전에 사용자가 3-4초 정도 기다려야 한다는 의미입니다. 정말 나쁜 UX 조각입니다. 동의하다.
해결책은 들어오는 작업을 저장하고 사용자에게 모든 것이 잘 되었다고 알리고 나중에 처리하는 것입니다(몇 초). 오류가 있는 경우 대기 중인 작업이 실패한 것으로 선언되기 전에 몇 번 재시도할 수 있습니다.
크레딧: Microsoft.com
큐잉 시스템은 설정을 약간 복잡하게 만들지만(모니터링 오버헤드를 추가함) 최신 웹 애플리케이션에서는 없어서는 안 될 요소입니다.
자산 최적화(Laravel Mix)
Laravel 애플리케이션의 프런트 엔드 자산에 대해 모든 자산 파일을 컴파일하고 축소하는 파이프라인이 있는지 확인하십시오. Webpack, Gulp, Parcel 등과 같은 번들러 시스템에 익숙한 사람들은 귀찮게 할 필요가 없지만 아직 이것을하지 않는 경우 라라벨 믹스 확실한 추천입니다.
Mix는 프로덕션을 위한 모든 CSS, SASS, JS 등 파일을 관리하는 Webpack 주변의 경량(그리고 정직하게 유쾌한) 래퍼입니다. 일반적인 .mix.js 파일은 다음과 같이 작을 수 있으며 여전히 놀라운 작업을 수행할 수 있습니다.
const mix = require('laravel-mix');
mix.js('resources/js/app.js', 'public/js')
.sass('resources/sass/app.scss', 'public/css');
이것은 프로덕션 준비가 되고 npm run production을 실행할 때 가져오기, 축소, 최적화 및 전체 shebang을 자동으로 처리합니다. Mix는 전통적인 JS 및 CSS 파일뿐만 아니라 애플리케이션 워크플로에 있을 수 있는 Vue 및 React 구성 요소도 처리합니다.
더 많은 정보 여기!
결론
성능 최적화는 과학보다 예술에 가깝습니다. 무엇을 해야 하는지보다 어떻게 얼마나 해야 하는지 아는 것이 중요합니다. 즉, Laravel 애플리케이션에서 얼마나 많은 것을 최적화할 수 있는지는 끝이 없습니다.
그러나 무엇을 하든 이별 조언을 남기고 싶습니다. 최적화는 그럴듯하게 들리거나 현실에서 100,000명 이상의 사용자를 위한 앱 성능에 대해 편집증적이기 때문이 아니라 확실한 이유가 있을 때 수행되어야 합니다. 10개 밖에 없습니다.
앱을 최적화해야 하는지 여부가 확실하지 않은 경우 말벌의 둥지를 걷어차지 않아도 됩니다. 지루하게 느껴지지만 해야 할 일을 정확히 수행하는 작동하는 앱은 돌연변이 하이브리드 슈퍼머신에 최적화되었지만 때때로 실패하는 앱보다 10배 더 바람직합니다.
그리고 초보자가 Laravel 마스터가 되려면 다음을 확인하십시오. 온라인 코스.
앱이 훨씬 더 빠르게 실행되기를 바랍니다! 🙂