Selbst die meisten erfahrenen Ruby on Rails-Entwickler vergaßen manchmal lästige Fehler, die sie in den langen Entwicklungsprozessen verursachten, wie z. B.
n + 1- Abfragen, oder verlieren viel Zeit mit unerwarteten Abfragen aus dem Nichts.
Nicht alle diese Fehler können vor der Produktion vermieden werden, aber zumindest können Sie versuchen :)
Ja, das ist eine weitere Liste vergessener oder weniger beliebter Juwelen für bessere Entwicklungsprozesse.
Fangen wir an.
1. Kugel
Bullet - eine der beliebtesten und einfachsten Lösungen für den Kampf mit
n + 1- Abfragen.
Dieses Juwel bietet verschiedene Möglichkeiten, um zu zeigen, dass einige Abfragen nicht effizient sind. Browser (Konsolenprotokoll), Entwicklungsprotokoll, Ausgabedatei. Ich entscheide mich lediglich für die Verwendung eines
Entwicklungsprotokolls, da es nicht so nervig ist (einige Probleme treten nur zu spät auf oder können mit der aktuellen Architektur nicht einfach behoben werden).
So funktioniert es : Sie haben beispielsweise eine
Indexanforderung für ein Modell (
Dienste ). Und dieses Modell hat viele verschiedene Beziehungen (
Dienste haben viele Gruppen ), sie haben auch Beziehungen. (
Gruppen haben viele Benutzer ,
Benutzer haben viele Logos usw.). Und es kann wiederholtes ineffizientes Laden von Daten (
n + 1 ) verursachen. Sie möchten logo_url anzeigen und es werden für jeden Benutzer unnötige Abfragen erstellt (manchmal sehen Sie es sofort, manchmal ist es nicht so klar). In den meisten Fällen wirft das
Aufzählungszeichen die nächsten Zeilen in Ihren Entwicklerprotokollen:
GET /api/services USE eager loading detected Service => [:groups] Add to your finder: :includes => [:groups] Call stack /home/projects/test_app_name/app/services/index.rb:18:in `perform' /home/projects/test_app_name/app/controllers/services_controller.rb:7:in `index'
Wie Sie sehen können, zeigt es die Anfrage, was gefunden wurde (eifriges Laden), das Modell und was genau mehrmals geladen wurde. Und call stack natürlich.
Gut genug, um anzufangen!
Bullet kann ungenutzte eifrige Lade- und Gegen-Caches finden. Und ermöglicht es Ihnen, einen seiner Detektoren zu deaktivieren.
In meinen Projekten
deaktiviere ich
ungenutzte eifrige Ladeabfragen lieber, da ein Lademodell-Service häufig an vielen Orten verwendet wird und Sie für verschiedene Orte keine Relationen vorladen müssen, die an anderen Orten eindeutig erforderlich sind. Und diese Situation ist am Ende sehr ärgerlich. Sie sollten einige Informationen vorab laden und dann vergessen, sie irgendwo richtig zu laden.
Meine Konfiguration (in
development.rb ):
config.after_initialize do Bullet.enable = true Bullet.rails_logger = true Bullet.unused_eager_loading_enable = false end
Weitere Infos :
2. ActiveRecordQueryTrace (active_record_query_trace)
active_record_query_trace - Ein Juwel, das eine Rückverfolgung aller von Active Record ausgeführten SQL-Abfragen protokolliert / anzeigt
(Ich habe gerade den Teil der Beschreibung von ihrer Github-Seite kopiert, weil sie alles haben, was du wissen musst.)
Zeigt eine Rückverfolgung für jede Abfrage in der Rails-Entwicklungskonsole und im Rails-Protokoll an. Ermöglicht es Ihnen, herauszufinden, wo Abfragen in Ihrer Anwendung ausgeführt werden. Nützlich für Leistungsoptimierungen und um herauszufinden, wo Sie anfangen sollen, wenn Sie Änderungen an einer großen Anwendung vornehmen.Wenn diese Option aktiviert ist, wird jede Abfrage wie folgt protokolliert:
Started GET "/" for 172.19.0.1 at 2019-09-29 07:08:04 +0000 Processing by HomeController
Von meiner Seite aus möchte ich sagen, dass dieses Juwel sehr nützlich ist, wenn Sie nicht von Anfang an an dem Projekt arbeiten und nicht wissen können, wie alles funktioniert (oder nur mit Funktionen von Kollegen), und dass einige Abfrageaufrufe nicht einfach zu verstehen sind. Das könnte wirklich viel Zeit sparen.
Auch ein kleiner Hinweis:
Für jede ActiveRecord-Abfrage gibt es eine zusätzliche Rückverfolgung in der Protokolldatei. Standardmäßig ist es 5, was groß genug ist, um Ihre Protokolle vollständig unlesbar zu machen.
Aber es kann gesteuert werden:
ActiveRecordQueryTrace.lines = 1
Weitere Infos:3.rails_panel
RailsPanel ist eine
Chrome-Erweiterung für die Rails-Entwicklung, mit
der Sie die Entwicklung von development.log beenden können. Verfügen Sie über alle Informationen zu Ihren Rails-App-Anforderungen im Browser - im Developer Tools-Bereich. Bietet Einblick in DB / Rendering / Gesamtzeiten, Parameterliste, gerenderte Ansichten und mehr.
Um diese Erweiterung zu verwenden, müssen Sie
meta_request gem zur
Gemfile Ihrer App hinzufügen:
group :development do gem 'meta_request' end
Installieren Sie die RailsPanel-Erweiterung aus dem
Chrome WebStore . Dies ist die empfohlene Methode zum Installieren der Erweiterung, da diese bei jeder neuen Version automatisch aktualisiert wird.
Dies ist das Beispiel für die aktivierte rail_panel gem / extension:
Weitere Infos:4. Rack-Mini-Profiler
Nach der Installation des Gems und dem Öffnen Ihres Projekts sehen Sie das Popup in der linken oberen Ecke (kann neu konfiguriert werden) auf der Seite:
Nachdem Sie darauf geklickt haben, sehen Sie detailliertere Informationen:
Wie Sie sehen, finden Sie hier viele nützliche Informationen für ein effizienteres Arbeiten. Es funktioniert auch mit SPA-Anwendungen.
Weitere Infos:5. newrelic / datadog
New Relic ist ein
Performance-Management-System , das von New Relic, Inc. entwickelt wurde. Sie erhalten detaillierte Informationen über die Leistung Ihrer Rails- oder Ruby-Anwendung, während diese
in der Produktion ausgeführt wird, und werden an newrelic.com übertragen, wo Sie
sie in Echtzeit überwachen können . (AUCH SIE HABEN KEIN BEZAHLTES KONTO)
Datadog als Alternative ist auch eine sehr gute Wahl. Sie bieten die gleiche Funktionalität wie New Relic. Prüfen Sie einfach deren Möglichkeiten, Benutzeroberfläche, Preise und wählen Sie, was Sie bevorzugen.
Weitere Infos:Danke fürs Lesen!