Как да отстранявате грешки и да оптимизирате Laravel приложения в производствена среда

Начало » Python » Как да отстранявате грешки и да оптимизирате Laravel приложения в продукция

Разгръщането и дебъгването на Laravel приложение в продукционна среда е един от онези моменти, в които теорията за разработка се сблъсква с реалната инфраструктура : сървъри без Composer, споделени хостинги с cPanel, VPS с Redis и опашки, бавни заявки, грешки от типа 500, които се появяват само под натоварване... и потребители, чакащи от другата страна на екрана. Ако не планирате това внимателно, производителността и надеждността ще пострадат бързо.

Това ръководство ще ви преведе през целия жизнен цикъл: от внедряването на Laravel на споделен хостинг или VPS, до диагностицирането на пречки, извличането на всяка милисекунда от приложението ви с кеширане, настройване на базата данни и оптимизации на ниво сървър . Ще видим също кога да използваме инструменти като Debugbar и Telescope, как да преминем безопасно от разработка към производство и какво да наблюдаваме непрекъснато, за да остане приложението ви бързо и стабилно, докато расте.

От развойна кутия до производствен сървър: кой е правилният път?

Напълно валидно (и често препоръчително) е да запазите Composer само във вашата среда за разработка и да внедрите предварително изграден код в производствената среда . Ако вашият виртуален сървър за разработка има инсталирани Composer, Laravel, Apache2 и MariaDB, а вашата производствена виртуална машина изпълнява само стека (PHP + уеб сървър + база данни) без Composer, не правите нищо нередно – просто ви е необходим чист работен процес за внедряване.

Често срещан и надежден подход е да се отдели внедряването на код от внедряването на база данни : използвайте Git (или друга система за управление на веригите) за преместване на код и контролиран процес (миграции и, когато е необходимо, дъмпове) за преместване или синхронизиране на базата данни. Разчитането на суров mysqldump за всичко може да работи, но не винаги е най-безопасният или лесен вариант, когато приложението вече е онлайн.

Разумният базов работен процес обикновено изглежда така :

• код: качете в отдалечено хранилище и изтеглете/клонирайте на производствената машина или качете подготвен архив (ZIP/TAR) с vendor вече построено.
• Зависимоститеили инсталирайте с Composer на prod (ако е позволено), или ship-нете vendor от вашата локална машина за изграждане.
• Структура на база данниразчитайте на Laravel миграция за да се поддържа схемата синхронизирана между dev и prod, вместо постоянно да се импортират пълни дъмпове.
• Данни от базата данниПремествайте начални/демо данни само когато е наистина необходимо; за работещ проект структурата трябва да бъде мигрирана, но реалните данни ще бъдат създадени от потребителите в производствения процес.

На споделен хостинг с cPanel процесът е подобен, но обикновено пакетирате целия Laravel проект локално и го качвате чрез файловия мениджър или FTP/SFTP.След това ще коригирате пътищата, ще конфигурирате .env, създайте производствената база данни чрез cPanel и, когато имате достъп до терминала, изпълнете командите на Artisan директно на сървъра.

Безопасно внедряване на Laravel на споделен хостинг (cPanel)

При евтин споделен хостинг обикновено получавате cPanel, PHP, MySQL и не много друго.Това означава, че в много случаи няма пълен SSH, няма Composer глобално и има строг публичен уеб root достъп, както... public_htmlВсе още можете да разположите Laravel чисто – просто трябва да спазвате оформлението на папките на хостинга и да засилите разрешенията.

Подгответе проекта си локално, преди да качите каквото и да било :

• Изграждане на фронтенд ресурси с NPM (Webpack, Vite, Laravel Mix), така че JS и CSS кодът за производство да са готови: минифицирани, пакетирани и версирани.
• Оптимизиране на автоматичното зареждане на Composer с composer dump-autoload -o и ако изграждате изключително за производство, използвайте composer install --no-dev за да се избегнат пакети само за разработчици на активния сървър.
• Почистване на кешовете и лог файловете за да не вмъквате „боклуци“ от разработката в продукционната среда: изчистете кешовете на Laravel и премахнете всичко вътре storage/logs така че в новата среда да се генерират нови лог файлове.

Когато опаковате проекта в ZIP/TAR архив, имайте предвид какво не трябва да се изпраща :

• Не включвай .git или всякакви метаданни, свързани с VCS, ако няма да използвате Git директно на сървъра.
• Чисто старо влезете файлове от storage/logs за да се избегне шум и да се спести дискова квота.
• Осигурете скрити файлове, като например .env намлява . Htaccess наистина са част от архива; някои архиватори пропускат dotfiles по подразбиране.

От страна на хостинга, първата стъпка е да качите и разархивирате архива :

• Използвайте файловия мениджър на cPanel, за да качите компресирания файл в дома на вашия потребител.
• Разархивирайте го в папка, например /home/your-user/your-laravel-project.
• Държа public_html отделен; той ще действа като уеб корен, докато останалата част от Laravel ще се намира извън него за сигурност.

След това заключете разрешенията за файловеМного разработчици работят локално с широко отворени разрешения (като 777) по време на разработка, но това е огромна уязвимост в споделени среди. Само минимално допустимите за запис директории – обикновено storage намлява bootstrap/cache – трябва да може да се записва от потребителя на уеб сървъра и нищо във вашата кодова база не трябва да може да се записва от всички.

За да завършите разделянето между публичен и частен код, преместете съдържанието на Laravel public директория в public_html:

• Всичко вътре your-laravel-project/public (index.php, ресурси и т.н.) отива в /home/your-user/public_html.
• Останалата част от Laravel приложението остава в /home/your-user/your-laravel-project, извън обсега на обществеността.

След това движение, public/index.php (сега живея в public_html) вече не намира vendor/autoload.php намлява bootstrap/app.php в очакваните относителни пътищаАктуализирайте двете require съответно редовете, насочвайки ги обратно към истинския корен на проекта:

• Променете включването на автоматичното зареждане от нещо подобно __DIR__.'/../vendor/autoload.php' към път, който води към папката на вашия проект, напр. __DIR__.'/../your-laravel-project/vendor/autoload.php'.
• Направете същото за приложението bootstrap: __DIR__.'/../your-laravel-project/bootstrap/app.php'.

Всеки път, когато качвате нова версия на проекта, избягвайте сляпо презаписване index.php без повторно прилагане на тези промениАко го смените, проверете отново require пътища, преди да бъдат публикувани.

Конфигуриране на база данни, среда и поща в производствена среда

Готово за производство Laravel приложение е поставено на правилно свързана мрежа. .env файл и правилно създаден потребител на базата данниНеправилно конфигурирани идентификационни данни за базата данни, грешни APP_URL или забравен APP_DEBUG=true са сред най-честите източници на производствени главоболия.

Започнете със създаването на базата данни във вашия хостинг панел :

• В cPanel отидете на MySQL бази данни и създайте нова база данни за проекта.
• Създайте специален потребител за база данни със силна парола.
• Присвоете на този потребител всички необходими привилегии към базата данни (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER и др.).

След това адаптирайте производството си .env досиеАко не е бил включен в архива, създайте го в корена на проекта и копирайте всички стойности от локалната версия, след което коригирайте:

• APP_ENV: задайте го на production Така Laravel прилага производствени предположения за кеширане, регистриране и обработка на грешки.
• APP_DEBUG: задайте го на false за да се избегне изтичане на чувствителна информация в страниците с изключения.
• URL_адрес на приложението: задайте го на вашия реален домейн, напр. https://your-domain.com, така че генерирането на URL адреси и връзките да се държат правилно.
• APP_KEYгенериране на нов ключ локално с php artisan key:generate, след което копирайте стойността в производствения файл .envТози ключ защитава криптирани данни и сесии, така че не използвайте повторно остарели ключове небрежно.

Променливите за връзка с базата данни са следващата критична част :

• DB_DATABASE трябва да съвпада с името на базата данни, която сте създали в хостинга.
• DB_USERNAME трябва да е специалният потребител на базата данни, а не вашите данни за вход в панела.
• DB_PASSWORD трябва да е генерираната парола за този потребител на MySQL.

Ако приложението ви изпраща имейл, производствената MAIL_* настройките също трябва да бъдат актуализираниЗаменете всички локални или sandbox стойности (като Mailtrap) с SMTP данните, предоставени от вашия хост или имейл услуга на трета страна:

• ПОЩЕНСКИ_ХОСТ, ПОЩЕНСКИ ПОРТ намлява ПОЩЕНСКИ ПОЩЕН трябва да отразява реалния SMTP сървър.
• ПОЩЕНСКО_ПОТРЕБИТЕЛСКОИМЕ намлява ПАРОЛА ЗА ПОЩА обикновено съответстват на истинска пощенска кутия (напр. noreply@your-domain.com).
• ПОЩЕНСКИ_АДРЕС_ОТ_ПОЩА намлява ПОЩА_ОТ_ИМЕ дефинирайте самоличността на подателя, видима за крайните потребители.

След като .env файлът е на място, добра идея е да обновите кеша на конфигурацията на Laravel, така че рамката да не чете десетки конфигурационни файлове при всяка заявка.С достъп до терминал обикновено бихте изпълнили php artisan config:cache да се възстанови bootstrap/cache/config.php използвайки вашите производствени стойности.

За самата схема на базата данни имате две основни стратегии в зависимост от това дали това е първо внедряване или миграция от съществуваща система :

• В чисто нов производствен екземпляр, изпълняващ php artisan migrate в корена на проекта ще създаде всички таблици празни и готови за данни на живо.
• Ако трябва да репликирате съществуваща локална схема без редове, можете да нулирате миграциите локално, да експортирате чистата база данни като SQL чрез phpMyAdmin и да импортирате този дъмп в базата данни на хоста.

Разбиране и отстраняване на проблемите с производителността на Laravel

Laravel поставя опита на разработчиците на първо място, което означава, че конфигурацията по подразбиране е пригодена за гъвкавост, а не за сурова скорост . Веднага щом е готова, рамката зарежда много услуги, решава много неща динамично чрез контейнера и записва подробно – всичко това помага при разработката, но може да забави производството, ако не се контролира.

Съвременните потребители очакват отговори за по-малко от секунда, често под 200 мс, за често срещани страници . Ако приложението ви постоянно отнема повече време, ангажираността, конверсията и дори SEO оптимизацията могат да започнат да страдат. Когато внедрявате приложението в производствен режим, оптимизацията на производителността не е нещо незадължително, което е „хубаво да има“; тя е част от завършването на работата.

Някои от най-честите проблеми с производителността в Laravel приложенията включват :

• Неоптимизирани заявки към база данни, особено класически N+1 задачи.
• Прекомерно зареждане на данни чрез Eloquent модели, вместо да се избират само необходимите колони.
• Липса на кеширане за маршрути, конфигурация, заявки и изгледи.
• Неоптимизирана PHP настройка (няма OPcache, бавен PHP манипулатор, грешна PHP версия).
• Изпълняване на тежки задачи по време на заявката, вместо да се поставят в опашки.

За да определите точно какво забавя приложението ви, ви е необходима видимост както на ниво приложение, така и на ниво инфраструктура . На ниво Laravel, инструменти като Debugbar и Telescope предоставят информация за заявки, времена и грешки. На ниво хостинг, табла за управление, които показват процесора, RAM, дисковия I/O и честотната лента, помагат за съпоставяне на бавните отговори с претоварени сървъри или лоша I/O производителност.

Когато комбинирате двете перспективи, можете да направите разлика между „лош код“ и „недостатъчна или неправилно конфигурирана инфраструктура“ . Това е от съществено значение, ако искате да избегнете хвърлянето на хардуер към проблем, който е трябвало да бъде решен в една единствена релация или индекс на Eloquent.

Оптимизация на заявки към база данни с Eloquent

Слоят на базата данни често е първият и най-голям източник на проблеми с производителността в истински Laravel проект . Eloquent е удобен и изразителен, но е лесно случайно да се напишат заявки, които експлодират при натоварване или с големи набори от данни.

Класическият виновник е проблемът с N+1 заявка . Това се случва, когато вашият код зарежда списък със записи и след това за всеки елемент от този списък задейства допълнителна заявка за зареждане на свързани данни. Двадесет публикации в блога с данни за автора могат внезапно да означават 21 заявки вместо 2 (една за публикациите, една за всички автори).

Този бъг обикновено се появява в код като този :

• Извличате публикации: $posts = Post::all();
• В изглед на Blade, итерирате и извиквате $post->author за всеки артикул.
• Всеки ->author достъпът задейства друг SQL SELECT зад сцената.

Решението е нетърпеливо зареждане чрез with()Вместо да позволявате на Eloquent да зарежда релациите лениво всеки път, вие изрично му инструктирате да зарежда релациите наведнъж: $posts = Post::with('author')->get();Инструменти за отстраняване на грешки, като Laravel Debugbar, правят проблемите с N+1 очевидни, като показват подозрително висок брой заявки на страници, на които би трябвало да им трябват само няколко.

След като N+1 е под контрол, следващата стъпка е да намалите количеството данни, които извличате и обработвате :

• употреба изберете() за да извлечете само колоните, от които действително се нуждаете, вместо пълните редове на таблицата.
• Кандидатствай лимит() или номериране на страниците със списъци, за да се избегне влаченето на хиляди редове в паметта, когато са видими само няколко.
• За сложни агрегации или тежки съединения, помислете за използване на конструктора на заявки или дори суров SQL, където е уместно.

Индексирането на базата данни е друга мощна, но често пренебрегвана оптимизация . Миграциите на Laravel не индексират автоматично всеки външен ключ, а неиндексираните колони, използвани във филтри или съединения, могат да причинят бавно сканиране на цялата таблица. Чрез изрично добавяне на индекси с една колона или съставни индекси към често заявявани полета, можете драстично да намалите времето за заявки, особено за натоварвания с голямо четене.

На VPS или специализиран хостинг, където контролирате настройките на MySQL или MariaDB, можете да стигнете по-далеч, като настроите кеша на заявките, буферния пул на InnoDB и бавните регистрационни файлове на заявките . След като кодът на приложението бъде оптимизиран, тези корекции на ниво база данни помагат на двигателя да се мащабира при продължително натоварване и големи набори от данни.

Ефективно използване на кеширането в Laravel

Кеширането е една от най-ефективните и най-малко изискващи усилия техники, които можете да използвате, за да подобрите производителността на Laravel . Чрез съхраняване на често използвани данни, конфигурация или дефиниции на маршрути в бързо хранилище, вие избягвате повтарянето на скъпи операции при всяка заявка.

Laravel се доставя с гъвкава абстракция на кеша, която поддържа множество драйвери :

• Redis – хранилище за данни в паметта, идеално за сесии, кеш и данни в реално време, широко използвано в производството.
• Спомен – друг слой за кеширане в паметта с по-опростен модел на данните; подходящ, когато искате скорост без допълнителните възможности на Redis.
• Кеш на файлове – съхранява кеш записите на диск; по-бавно от паметта, но често единствената опция при по-евтин споделен хостинг.

Драйверите са конфигурирани в config/cache.phpи можете да промените настройката по подразбиране, без да пренаписвате кода сиМоже да започнете на споделен хост, използвайки файлов кеш, след което да мигрирате прозрачно към Redis, когато преминете към VPS – кодът на приложението, който извиква API за кеширане, не е необходимо да знае какво има отдолу.

Няколко основни стратегии за кеширане са практически задължителни за производствените Laravel приложения :

• Кеш на маршрута: php artisan route:cache компилира маршрути в един файл. Това е особено важно за приложения с много маршрути.
• Конфигуриране на кеша: php artisan config:cache обединява всички конфигурационни файлове, минимизирайки посещенията във файловата система по време на заявки.
• Преглед на кеша: php artisan view:cache предварително компилира шаблоните на Blade в чист PHP, така че се избягва парсирането по време на изпълнение.
• Кеширане на резултатите от заявките: използвайки Cache::remember() или подобни помощни програми за съхраняване на резултати от заявки към база данни, които не се променят при всяка заявка.

Когато са налични Redis или Memcached, тези стратегии стават още по-мощни, защото кешираните данни се обслужват от паметта . При хостинг, поддържан от NVMe SSD, дори кешът, базиран на файлове, се подобрява, тъй като латентността при четене/запис на диска е значително намалена в сравнение с традиционните твърди дискове.

За по-напреднали настройки, комбинирането на кеша на приложението с CDN за статични ресурси (CSS, JS, изображения) разтоварва много работа от вашия оригинален сървър . Кеширането на статични ресурси на периферията намалява латентността за потребителите в различните региони и помага на вашето Laravel приложение да се фокусира върху динамични отговори.

Настройка на ниво сървър: PHP, уеб сървър и хостинг нива

Без значение колко изпипан е вашият Laravel код, лошо конфигурираният сървър може да саботира производителността и стабилността . PHP настройките, избраният манипулатор (като PHP-FPM), OPcache и базовият хардуер (SSD срещу NVMe срещу HDD) влияят пряко върху времето за реакция и паралелизма.

Първо, изберете подходяща версия на PHP, която официално се поддържа от вашата версия на Laravel и все още се поддържа в upstream версията . По-новите версии на PHP 8.x обикновено осигуряват значително подобрение в производителността в сравнение със старите версии 7.x, така че самото надграждане на PHP често намалява драстично времето за обработка на заявки, дори преди да сте докоснали кода на приложението.

След това се уверете, че необходимите PHP разширения (mbstring, openssl, PDO и др.) са активирани и че OPcache е активен . OPcache съхранява предварително компилирания PHP байткод в споделена памет, предотвратявайки презареждането и прекомпилирането на скриптове от PHP при всяка заявка. На VPS и специализирани планове можете да настроите размера на паметта и политиките за валидиране на OPcache, за да отговарят на капацитета на вашето приложение.

Използването на PHP-FPM с правилно оразмерени пулове от процеси може също да подобри едновременността и изолацията . Вместо да използва по-стари, по-бавни обработчици, PHP-FPM управлява работните процеси по-ефективно и ви позволява да настройвате настройките на пула (максимален брой деца, време за изчакване) според вашия профил на трафик.

От страна на уеб сървъра, конфигурирайте пренаписването на URL адреси, така че рутерът на Laravel да получава чисти URL адреси.В Apache това означава да се гарантира mod_rewrite е активирано и правилата от public/.htaccess са спазени. Активирането на HTTP/2 и TLS (HTTPS) на ниво панел също носи предимства както за производителността, така и за сигурността.

Изборът на правилния хостинг пакет е също толкова важен, колкото и настройването на софтуерния стек :

• Споделен хостинг Работи за малки Laravel приложения с нисък трафик, но споделяте процесор и памет с други клиенти. Очаквайте ограничения и непостоянна производителност при пикове.
• VPS дава ви root достъп и специални ресурси, което ви позволява да персонализирате PHP-FPM пулове, Redis, queue workers, настройка на базата данни и по-добър цялостен контрол.
• Специализирани сървъри са най-подходящи за критично важни или високотрафикови приложения, които изискват предвидима производителност, персонализирани стекове и разширени модели на мащабиране.

Във всички тези нива, NVMe SSD съхранението е основно предимство, защото ускорява всичко, свързано с дисков входно/изходен трафик : кеширане на базата на файлове, съхранение на сесии, запис на лог файлове, дори достъп до база данни. Този допълнителен капацитет е особено полезен, след като приложението ви започне да се мащабира.

Оптимизации на Artisan и Composer за продукция

Преди да включите превключвателя в производствена версия, винаги трябва да изпълните специфичен набор от команди Artisan и Composer, за да подготвите кодовата база за бързина . Пропускането на тези стъпки е един от най-лесните начини да не се засяга производителността.

Основните команди на Artisan, които да включите в процеса на внедряване, са :

• php artisan optimize: изпълнява набор от оптимизации наведнъж за много често срещани сценарии.
• php artisan config:cache: компилира конфигурационните файлове в един файл.
• php artisan route:cache: ускорява регистрацията на маршрути (избягвайте, ако все още използвате затваряния в маршрути; първо ги рефакторирайте в контролери).
• php artisan view:cache: компилира шаблоните на Blade предварително.

Имайте предвид, че кешовете за конфигурация и маршрути могат да повредят нещата, ако приложението ви разчита на специфична за средата конфигурация или затваряния в маршрути . Винаги тествайте тези команди в тестова среда, преди да ги изпълните в продукция, и се уверете, че процесът на внедряване може да изчисти кешовете, ако нещо се обърка.

От страна на Composer, два флага са фундаментални за производствените компилации :

• --no-dev при инсталиране, за да се избегне изпращането на пакети само за разработчици, което намалява повърхността за атака и натоварването на пакетите.
• dump-autoload -o за генериране на оптимизирана карта на класовете, ускорявайки автоматичното зареждане.

Ако вашият производствен сървър няма инсталиран Composer, изпълнете тези стъпки в локалната или CI среда и качете получения файл. vendor директорията заедно с кода на приложениетоПо този начин, продукцията никога не е необходимо да докосва Composer, но въпреки това се възползва от оптимизираното автоматично зареждане.

Структуриране на приложението, ресурсите, сесиите и опашките

Освен базите данни и кеширането, начинът, по който вашият Laravel проект е структуриран вътрешно, също влияе върху производителността и поддръжката по време на изпълнение . По-стройната и по-целенасочена архитектура обикновено води до по-малко ненужни операции при всяка заявка.

Обърнете специално внимание на това как използвате контейнера за услуги и междинния софтуер :

• Избягвайте регистрирането или разрешаването на услуги, които рядко или никога не се използват за текущата заявка; използвайте отложено зареждане, когато е възможно.
• Прикачете междинен софтуер само към маршрутите или групите, които наистина се нуждаят от него, вместо да трупате всичко върху web or api в световен мащаб.
• Организирайте маршрутите в групи с префикси и споделен мидълуер, за да ги направите едновременно по-лесни за управление и по-подходящи за кеширане.

От страна на frontend-а, ​​правилният asset pipeline е голямо предимство за производителността . Използвайки Laravel Mix, Vite или подобен инструмент, трябва:

• Компилирайте SCSS/LESS и модерен JS в минифицирани, версирани пакети.
• Активирайте минифицирането и разклащането на дървовидни структури, за да намалите размера на файла.
• Когато е възможно, обслужвайте статични ресурси чрез CDN, оставяйки CDN да обработва георазпределената доставка.

Конфигурацията на сесии и опашки има пряко въздействие при натоварване . Малките приложения могат да оцелеят с драйвери за сесии на файлове или бази данни, но с нарастването на паралелизма тези опции бързо се превръщат в пречки. Redis обикновено е предпочитаният избор за бързо, едновременно съхранение на сесии и бекендове за опашки в производствена среда.

Разтоварването на тежката работа върху опашки е един от ключовете за поддържане на ниско време за реакцияИзпращане на имейли, генериране на PDF файлове, обработка на големи отчети или изображения – тези задачи трябва да се изпълняват във фонов режим чрез задания и работници (php artisan queue:work), не блокират основния HTTP отговор. На VPS или специализирани машини можете да стартирате тези работници постоянно чрез системни услуги или мениджъри на процеси.

Добре структурираното Laravel приложение, комбинирано с правилните функции за хостинг (поддръжка на Redis, NVMe съхранение, SSH достъп), може да остане бързо и стабилно, дори когато трафикът и данните нарастват . Целта е винаги една и съща: вашите заявки да извършват минимално възможна синхронна работа, а останалото да се съхранява в кешове или фонови задачи.

Дебъгване и наблюдение на Laravel в продукция: Debugbar срещу Telescope

В даден момент ще ви е необходимо нещо повече от лог файлове и страници с грешки, за да разберете какво се случва във вашето Laravel приложение . Тогава на помощ идват инструменти като Laravel Debugbar и Laravel Telescope, всеки със своята идеална среда.

Laravel Debugbar е лента с инструменти в браузъра, която се инжектира в долната част на HTML страниците ви по време на разработка . Тя показва SQL заявки (с брой и времеви интервали), разбивки на времевата линия, маршрути, изгледи, лог файлове и други, директно в страницата, която тествате. Идеална е за бързо, визуално отстраняване на грешки при работа с Blade изгледи локално.

Типичен инсталационен процес за Debugbar използва Composer с --dev флаг, като се гарантира, че пакетът е наличен само в процес на разработка:

• Инсталирайте го с Composer в режим на разработка.
• Публикувайте конфигурацията му, ако е необходимо, и я оставете да се активира автоматично, когато APP_DEBUG=true.
• Промяна на настройките чрез debugbar.php или env флагове, ако искате да го превключвате за всяка среда.

Debugbar се фокусира върху текущата заявка . Не е предназначен да съхранява много исторически данни или да бъде достъпен за крайни потребители. Всъщност, собствената му документация предупреждава да не се активира на публично достъпни сайтове, тъй като разкрива чувствителна информация за заявките по замисъл.

Laravel Telescope, за разлика от него, е пълноценен панел за наблюдение на вашето Laravel приложение.Работи със собствен URI (обикновено /telescope) и записва заявки, запитвания, изключения, задания, команди, имейл, известия и други във вашата база данни. Това е особено полезно за API, SPA или системи с интензивна фонова активност, където няма HTML потребителски интерфейс, в който да се вмъкне лента с инструменти.

Инсталирането на Telescope включва добавяне на пакета, публикуване на ресурси и изпълнение на миграции за създаване на неговите таблициТъй като данните се натрупват с течение на времето, е добре да планирате редовно „подрязване“, например чрез ежедневно telescope:prune команда в ядрото на конзолата, за да предотвратите неограниченото нарастване на таблиците.

Когато използвате Telescope в производствени условия, трябва да го защитите с порти за оторизация.Само администратори или лица с определени роли трябва да имат достъп /telescopeи тази защита трябва да е част от доставчика на услуги Telescope. Ако се направи правилно, Telescope може да работи безопасно дори в реални среди и се превръща в мощен профилиращ инструмент и инструмент за одит на бавни заявки и грешки.

По отношение на функциите, Debugbar и Telescope се припокриват в някои области, но с различни компромиси . Debugbar предоставя незабавна обратна връзка на страницата (идеална за визуално забелязване на N+1 в изгледи), докато Telescope съхранява дълга история, която екипите могат да проверяват асинхронно и съвместно. Telescope е склонен да обработва по-добре големи обеми данни, защото зарежда информация асинхронно и я съхранява в базата данни, за сметка на допълнителна поддръжка и съхранение.

Не е нужно да ги третирате като взаимно изключващи се . Много разработчици изпълняват Debugbar локално за дебъгване на ниво изглед и използват Telescope в етапи на подготовка или производство, за да проследяват фонови задачи, API заявки и дълго изпълняващи се процеси. Ако вече използвате Telescope и се притеснявате за режийните разходи, Telescope Toolbar е опция, която ви предоставя интерфейс, подобен на Debugbar, подкрепен от хранилището за данни на Telescope.

Независимо от набора от инструменти, ключът е да деактивирате Debugbar в производствения режим, да ограничите Telescope с подходящо разрешение и периодично да премахвате съхранените данни . В комбинация със сървърни лог файлове и показатели от таблото за управление на вашия хост, те формират стабилен стек за дебъгване и наблюдение за сериозни Laravel приложения.

Съчетаването на всички тези елементи – чист поток на внедряване, внимателна конфигурация на средата, агресивна оптимизация на заявки и кеш, настроени настройки на PHP и уеб сървъра, както и правилните инструменти за отстраняване на грешки – превръща Laravel от „бърз на теория“ в „бърз при реален трафик“ . Със солиден контролен списък за предварителна продукция, ясна рутина за внедряване в продукцията и непрекъснато наблюдение, можете уверено да пускате нови версии, да проследявате проблеми и да поддържате приложението си Laravel адаптивно, дори когато потребителската ви база расте.