Napisałem ten fragment przewodnika.
Na pewno nie chcesz kompilować na żywo podczas produkcji.
Po kompilacji dzieje się tak:
Każde żądanie pliku w / zasobach jest przekazywane do Sprockets. Na pierwsze żądanie dla każdego zasobu jest on kompilowany i buforowany w cokolwiek, czego Rails używa do buforowania (zwykle system plików).
Przy kolejnych żądaniach Sprockets odbiera żądanie i musi wyszukać nazwę pliku odcisków palców, sprawdzić, czy plik (obraz) lub pliki (css i js), które tworzą zasób, nie zostały zmodyfikowane, a następnie, jeśli istnieje wersja buforowana, obsługuj to.
To wszystko w folderze zasobów i we wszystkich folderach dostawców / zasobów używanych przez wtyczki.
Jest to duże obciążenie, ponieważ, szczerze mówiąc, kod nie jest zoptymalizowany pod kątem szybkości.
Będzie to miało wpływ na szybkość przesyłu danych do klienta i wpłynie negatywnie na czas ładowania strony w Twojej witrynie.
Porównaj z domyślnymi:
Gdy zasoby są wstępnie kompilowane, a kompilacja wyłączona, zasoby są kompilowane i pobierane odciskami palców do pliku public/assets
. Sprockets zwraca Railsowi tabelę mapowania zwykłych na nazwy plików odcisków palców, a Railsy zapisują to w systemie plików. Plik manifestu (YML w Railsach 3 lub JSON z losową nazwą w Railsach 4) jest ładowany do pamięci przez Railsy podczas uruchamiania i buforowany w celu użycia przez metody pomocnika zasobów.
To sprawia, że generowanie stron z prawidłowymi zasobami odcisków palców jest bardzo szybkie, a same serwery plików są szybko obsługiwane przez serwer WWW z systemu plików. Oba są znacznie szybsze niż kompilowanie na żywo.
Aby uzyskać maksymalne korzyści z potoku i pobierania odcisków palców, musisz ustawić dalekosiężne nagłówki na swoim serwerze internetowym i włączyć kompresję gzip dla plików js i css. Sprockets zapisuje skompresowane wersje zasobów, które możesz ustawić dla swojego serwera, eliminując potrzebę, aby robił to dla każdego żądania.
Dzięki temu zasoby są wysyłane do klienta tak szybko, jak to możliwe, w możliwie najmniejszym rozmiarze, przyspieszając wyświetlanie stron po stronie klienta i zmniejszając (przy pomocy nagłówków w przyszłości).
Jeśli więc kompilujesz na żywo, jest to:
- Bardzo wolno
- Brak kompresji
- Wpłynie na czas renderowania stron
Przeciw
- Tak szybko, jak to możliwe
- Sprężony
- Usuń podsłuchaną kompresję z serwera (opcjonalnie).
- Minimalizuj czas renderowania stron.
Edycja: (odpowiedź na komentarz uzupełniający)
Rurociąg może zostać zmieniony w celu prekompilacji na pierwsze żądanie, ale istnieją pewne poważne przeszkody, aby to zrobić. Po pierwsze, musi istnieć tabela odnośników dla nazw odcisków palców lub metody pomocnicze są zbyt wolne. W senario kompilacji na żądanie musiałby istnieć sposób dołączenia do tabeli odnośników, ponieważ każdy nowy zasób jest kompilowany lub żądany.
Ponadto ktoś musiałby zapłacić cenę powolnego dostarczania aktywów przez nieznany okres czasu, dopóki wszystkie aktywa nie zostaną skompilowane i wdrożone.
Domyślnie, gdy cena kompilacji wszystkiego jest płacona jednorazowo w trybie off-line, nie ma wpływu na odwiedzających i gwarantuje, że wszystko zadziała, zanim wszystko zacznie działać.
Przełomem jest to, że bardzo komplikuje systemy produkcyjne.
[Edytuj, czerwiec 2015 r.] Jeśli czytasz to, ponieważ szukasz rozwiązania na długie czasy kompilacji podczas wdrażania, możesz rozważyć lokalną prekompilację zasobów. Informacje na ten temat znajdują się w przewodniku potoku zasobów . Umożliwia to lokalną prekompilację tylko w przypadku zmiany, zatwierdzenie jej, a następnie szybkie wdrożenie bez etapu prekompilacji.