Po tym, jak miałem okazję przetestować i przejrzeć oprogramowanie JPEG.webpmini Pro, zdałem sobie sprawę, jak potężne jest to oprogramowanie nie tylko do eksportowania obrazów i bycia częścią przepływu pracy Lightroom, ale także do wielu innych zastosowań, w tym do optymalizacji obrazów, które już znajdują się na naszym duże urządzenia pamięci masowej. Innym zastosowaniem, o którym od razu pomyślałem, był serwer WWW, z którego pochodzi ruch Photography-Secret.com. Biorąc pod uwagę, jak duży ruch w Photography-Secret.com obsługuje codziennie na całym świecie oraz fakt, że same obrazy stanowią około 5 terabajtów ruchu miesięcznie, myśl o możliwości kompresowania obrazów JPEG.webp za pomocą silnika JPEG.webpmini była czymś które naprawdę chciałem wdrożyć wcześniej niż później. Zacząłem więc od nowego projektu - aby w dłuższej perspektywie zaoszczędzić zarówno ruch, jak i pieniądze dla PL, korzystając z serwera JPEG.webpmini.
Uwaga fotografów: jest to bardzo techniczna recenzja oprogramowania niezwiązana z fotografią. Postanowiłem opublikować recenzję w PL, ponieważ uważam, że inne strony internetowe z dużą ilością fotografii mogłyby bardzo skorzystać na wdrożeniu serwera JPEG.webpmini.
1) Przegląd środowiska serwera
Zanim przejdę do recenzji, chciałbym wskazać kilka potencjalnie ważnych informacji na temat konfiguracji mojego serwera internetowego. Przede wszystkim uruchamiam CentOS Linux na każdym serwerze (a jest ich kilka). Dwa back-endowe serwery WWW, które obsługują wywołania PHP z load balancera, to miejsce, w którym zainstalowałem serwer JPEG.webpmini, chociaż tylko pierwszy naprawdę ma znaczenie, ponieważ to on obsługuje wszystkie operacje przesyłania do witryny (WordPress nie obsługuje tego bezpośrednio, więc możliwe jest tylko obserwowanie połączeń wp-admin i kierowanie ich do odpowiedniego serwera za pośrednictwem nginx / apache). Niestety, nie ma łatwego sposobu na uruchomienie więcej niż jednego serwera WordPress bez kłopotów z przesyłaniem plików, ponieważ nie jest on przeznaczony do użytku w środowisku klastrowym (przenoszenie wszystkiego do AWS z uruchomionymi instancjami serwerów EC2, RDS z DB i S3 obsługujące plików byłoby dobrym rozwiązaniem, ale po przetestowaniu go w żaden sposób nie było to tanie rozwiązanie, zwłaszcza gdy zaczniesz tworzyć kilka serwerów EC2, które będą obsługiwać obciążenie zaplecza). Dlatego synchronizowałem wszystkie przesłane pliki przez rsync. Nie jest to eleganckie rozwiązanie, ale działa dość dobrze. Mam rsync monitorujący folder „wp-content”, więc wszystkie zmiany są replikowane w jedną stronę (w zasadzie, po przesłaniu obrazów do server01, są one automatycznie pobierane przez server02). Synchronizacja zajmuje sekundę lub dwie, ale gdy to się stanie, obrazy są łatwo dostarczane do żądań modułu równoważenia obciążenia.
Wszystkie wywołania serwera WWW są obsługiwane przez moduł równoważenia obciążenia, który obsługuje tylko ruch internetowy https. Wszystkie obrazy są obsługiwane przez zewnętrzną sieć CDN. Głównym powodem wdrożenia JPEG.webpmini było zmniejszenie kosztów CDN, które rosną z każdym miesiącem, ponieważ nadal publikujemy więcej treści.
Pamiętaj, że Twój serwer WWW musi działać w wersji Linuksa - serwer JPEG.webpmini nie działa na serwerach Windows. Oto lista obsługiwanych platform serwerowych.
2) Instalacja serwera JPEG.webpmini
Instalacja serwera JPEG.webpmini jest bardzo łatwa, zwłaszcza jeśli używasz RHEL, CentOS i innych popularnych dystrybucji Linuksa. Dla mojego serwera CentOS JPEG.webpmini dostarczyło plik RPM, więc była to łatwa instalacja za pomocą jednego polecenia. Po zainstalowaniu pliku binarnego (domyślnie / usr / bin / jpeg.webpmini) następnym krokiem było skopiowanie pliku licencji .jpeg.webpmini.cfg do katalogu domowego użytkownika. Stamtąd uruchomienie „jpeg.webpmini” powinno spowodować wyświetlenie czegoś podobnego do następującego:
===============================
Uruchom jpeg.webpmini 3.14.2.84235
===============================
-f opcja jest wymagana: -f =
Użyj -help, aby uzyskać pomoc
===============================
Zakończ jpeg.webpmini 3.14.2.84235
===============================
Moje wstępne testy rozpoczęły się od serwera JPEG.webpmini w wersji 3.13, ale po kilku żądanych zmianach w pliku wykonywalnym JPEG.webpmini dostarczyło zaktualizowany plik RPM 3.14. Głównym dodatkiem do wersji 3.14 jest możliwość pomijania już zoptymalizowanych plików, co było dla mnie dużym problemem, ponieważ używam wersji oprogramowania na komputery stacjonarne i nie chciałem, aby serwer JPEG.webpmini ponownie optymalizował przesłane obrazy JPEG.webp.
3) Obsługa plików graficznych WordPress
Gdy obraz zostanie przesłany do WordPress, skrypty administratora będą używać GD lub ImageMagick do przetwarzania tych obrazów. Domyślnie WordPress tworzy obrazy w trzech rozmiarach, oprócz przesłanego obrazu (miniatura, średni rozmiar i duży rozmiar), ale w zależności od tego, ile wywołań add_image_size może zostać dodanych przez motyw i wtyczki, może być ich znacznie więcej! Z tego powodu przesyłanie pojedynczego obrazu może spowodować powstanie wielu plików na serwerze, umożliwiając bardzo szybki wzrost folderu Uploads. Te mniejsze obrazy są tworzone przez GD lub ImageMagick, więc pliki zostaną domyślnie pozbawione zarówno profili kolorów ICC, jak i danych EXIF, co nie jest pożądane w witrynie fotograficznej. Nie będą również odpowiednio zoptymalizowane pod kątem rozmiaru, ponieważ ani GD, ani ImageMagick nie mają inteligentnego algorytmu, takiego jak JPEG.webpmini, aby móc prawidłowo kompresować obrazy JPEG.webp. W rzeczywistości WordPress wykonuje dość okropną robotę przy zmianie rozmiaru obrazów, często powodując słabe kolory (z powodu usuwania profili ICC), miękkie i zamglone obrazy (z powodu dużej kompresji). Aby uniknąć tego problemu w PL, korzystałem tylko z ImageMagicka do optymalizacji obrazów, ze specjalnymi opcjami. Usuwamy tylko dane EXIF z miniatur i kompresujemy je nieco bardziej agresywnie, aby zapewnić szybkie przeglądanie. W poście ani profile ICC, ani dane EXIF nie są usuwane z większych obrazów, aby wyglądały jak najlepiej. W ten sposób nie zmuszamy naszych czytelników do klikania obrazu, aby zobaczyć „odpowiednią wersję” - obrazy wyglądają spójnie od podglądu do natywnych rozmiarów przesłanych na serwer.
Dlatego, aby w pełni wykorzystać możliwości serwera JPEG.webpmini, najlepiej jest uruchamiać plik wykonywalny dla każdego procesu zmiany rozmiaru - nie tylko dla pojedynczej przesłanej wersji, ponieważ chcesz, aby każdy plik został zoptymalizowany przez silnik, niezależnie od tego, czy jest to plik miniatura, medium lub duża wersja oryginału. Zasadniczo oznacza to, że JPEG.webpmini powinno przechwytywać każde wywołanie image_resize.
4) Integracja z serwerem JPEG.webpmini i WordPress
Niestety, JPEG.webpmini nie zapewnia wtyczki, która automatycznie integruje się z WordPressem, aby to zrobić, więc musiałem sam wymyślić rozwiązanie. Zacząłem od bazy kodu wtyczki ImageMagick Engine (dość przestarzała wtyczka, ale nadal działa), a następnie dodałem wywołania do pliku wykonywalnego JPEG.webpmini w funkcji ime_im_cli_resize (zamiast modułu PHP uruchamiam wersję wiersza poleceń programu ImageMagick). Jeśli ta zmodyfikowana wersja wtyczki jest czymś, co Cię interesuje, daj mi znać w sekcji komentarzy poniżej, a wyślę Ci plik wtyczki. Nie jestem pewien, czy ludzie z JPEG.webpmini planują wypuścić wtyczkę WordPress, ale byłbym szczęśliwy, mogąc wnieść trochę kodu w słusznej sprawie.
Kod działa i został przetestowany z JPEG.webpmini 3.14. Po utworzeniu każdej wersji o zmienionym rozmiarze kod najpierw optymalizuje te obrazy, a następnie optymalizuje i zastępuje oryginalny obraz JPEG.webp.
5) Wyniki testu serwera JPEG.webpmini
Do tej pory było wiele technicznych mumbo jumbo, więc przejdźmy do sedna. Ile miejsca na dysku udało mi się uratować i ile zaoszczędziłem na kosztach CDN? Aby uruchomić plik wykonywalny JPEG.webpmini rekurencyjnie w każdym folderze, musiałem poprosić inżynierów JPEG.webpmini o skrypt, który dostarczyli bardzo szybko. Dostarczony plik był skryptem Pythona o nazwie „jpeg.webpmini_recursive.py”, który wymagał tylko dwóch poleceń - jednego do wprowadzenia folderu źródłowego i jednego do wprowadzenia folderu docelowego (zmodyfikowałem skrypt trochę po uzyskaniu nowej wersji RPM, która może automatycznie pomijać już zoptymalizowane obrazy JPEG.webp). Po wykonaniu kopii zapasowej wszystkiego utworzyłem folder o nazwie „uploads_jpeg.webpmini” i właśnie tego użyłem jako folderu docelowego. Uruchomiłem skrypt i przeglądanie każdego pliku zajęło trochę czasu. Wróciłem po kilku godzinach i skrypt zakończył wykonywanie.
Ponieważ JPEG.webpmini optymalizuje tylko obrazy JPEG.webp i nie dotyka plików PNG, GIF ani innych przesyłanych plików, takich jak wideo, musiałem upewnić się, że skopiowałem wynikowy folder z powrotem do mojego folderu przesyłania. Ponownie upewnij się, że wykonałeś pełną kopię zapasową wszystkiego przed wykonaniem tego kroku, ponieważ jest to nieodwracalne. Zanim to zrobiłem, rekurencyjnie zmieniałem uprawnienia do folderu uploads_jpeg.webpmini, uruchamiając „chown -R nobody: nobody / uploads_jpeg.webpmini”. Następnie następnym poleceniem było „/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /”, które nadpisało istniejące pliki obrazów ich zoptymalizowanymi wersjami JPEG.webpmini.
Przyjrzyjmy się przed i po. Oto, jak wyglądały moje foldery, zanim skopiowałem całą zawartość:
du --max-depth = 1 | sort -k2 1252 ./2006 5272 ./2007 23332 ./2008 154872 ./2009 819580 ./2010 599084 ./2011 2124952 ./2012 2176548 ./2013 4504720 ./2014 6164472 ./2015 3812759 ./2016 559012 ./ 2017 Całkowity rozmiar: 20,945,855
Około 21 gigabajtów obrazów. Przyjrzyjmy się teraz, jak wyglądał folder po zoptymalizowaniu wszystkich obrazów przez JPEG.webpmini:
du --max-depth = 1 | sort -k2 1000 ./2006 2852 ./2007 15972 ./2008 127708 ./2009 647896 ./2010 461800 ./2011 1099676 ./2012 1252836 ./2013 3049696 ./2014 4378464 ./2015 2858628 ./2016 479416 ./ 2017 Całkowity rozmiar: 14.375.944
Ojej, to teraz tylko 14,4 gigabajta! Tylko na samym dysku twardym udało mi się odzyskać ponad 6,5 gigabajta przestrzeni, co przekłada się na mniej więcej 31% oszczędności miejsca. To w zasadzie jedna trzecia mojego rachunku CDN, co jest dużą liczbą. I pamiętaj, że ostatnie dwa + lata nie przyniosły tak dużej oszczędności miejsca jak wcześniej, ponieważ zacząłem już optymalizować moje obrazy na moim pulpicie za pomocą JPEG.webpmini Pro przed przesłaniem, więc liczby, które widzisz, są przesyłane przez innych członków zespołu, którzy nie używają JPEG.webpmini.
Oto przykładowy raport podsumowujący JPEG.webpmini za czerwiec 2012:
----------------------------------
INFO: Raport podsumowujący dla folderu Photographerylife.com/wp-content/uploads/2012/06 (w tym podfoldery):
INFO: Całkowita liczba plików: 372
INFO: Całkowity rozmiar plików wejściowych: 42900 KB
INFO: Całkowity rozmiar plików wyjściowych: 28480 KB
INFO: Współczynnik rekompresji: 1,51X (34% oszczędności)
INFORMACJE: ----------------------------------
Różne foldery dawały różne liczby, ale średnio było to między 30-35%, co jest dużo, biorąc pod uwagę, że nasz zespół ma dużą wiedzę na temat utrzymywania małych rozmiarów plików podczas procesu eksportu (zwykle utrzymujemy nasze ustawienia eksportu na poziomie 10 w Photoshopie , co odpowiada „jakości” Lightrooma na poziomie 77–84%, zgodnie z naszym artykułem dotyczącym poziomów kompresji JPEG.webp w programie Photoshop i Lightroom).
5) Jakość i ustawienia metadanych serwera JPEG.webpmini
W przypadku witryn, które niekoniecznie dbają o zachowanie wysokiej jakości obrazów JPEG.webp wraz z ich metadanymi, JPEG.webpmini może w rzeczywistości optymalizować obrazy znacznie agresywniej. Nie chciałem, aby obrazy JPEG.webp wyglądały gorzej niż pierwotnie przesłane, więc zachowałem domyślne ustawienie „qual = 0”, co pozwala zachować najlepszą jakość. Inne witryny mogą zdecydować się na działanie w wysokiej lub średniej jakości, co znacznie bardziej agresywnie zmniejszy rozmiar plików JPEG.webp. Ponadto można całkowicie usunąć wszystkie metadane za pomocą polecenia „rmt = 1”, a jeśli to nie wystarczy, istnieje nawet opcja wymuszenia progresywnego wyjścia JPEG.webp na każdym obrazie. Jestem pewien, że serwisy społecznościowe, takie jak Facebook, w dużym stopniu wykorzystują takie narzędzia, ponieważ obrazy i filmy stanowią ogromną część ich rachunków za hosting. Aby zapoznać się z listą poleceń dostępnych na serwerze JPEG.webpmini, odwiedź tę stronę.
6) Wniosek
Chociaż produkt JPEG.webpmini Server zdecydowanie nie jest przeznaczony dla fotografów, oprogramowanie to jest bardzo wszechstronnym narzędziem dla tych, którzy są właścicielami dużych witryn internetowych z dużą ilością obrazów i ruchu. Jak widać z mojego projektu wdrożeniowego, JPEG.webpmini Server był w stanie zaoszczędzić ponad 6,5 gigabajta miejsca, co przekłada się na około 31% oszczędności miejsca i kosztów CDN, co jest dużo dla firmy dowolnej wielkości. Przy cenie początkowej 199 USD miesięcznie, JPEG.webpmini Server nie jest tani dla małej firmy, ale dla rozwijającej się firmy z dużą powierzchnią hostingową, w której pojedyncza instancja serwera może kosztować więcej każdego miesiąca, produkt może być wart poważnego przyjrzenia się . Jeśli jesteś częścią firmy hostingowej, jeśli posiadasz stronę internetową zawierającą wiele obrazów, takich jak PL, lub Twoje koszty CDN stają się oburzające, możesz skontaktować się z ludźmi z JPEG.webpmini i porozmawiać z nimi o tym, jak mogą pomóc Ci. Na początek możesz wypróbować tę stronę, na której możesz wprowadzić swoją witrynę i zobaczyć, ile możesz się spodziewać zaoszczędzenia na kosztach CDN.
Jeśli masz jakiekolwiek pytania dotyczące któregokolwiek z powyższych, napisz do mnie komentarz poniżej.
Serwer JPEG.webpmini
- funkcje- 100% / 100
- Wartość- 100% / 100
- Łatwość użycia- 80% / 100
- Szybkość i wydajność- 100% / 100
- Stabilność- 100% / 100
- Wsparcie- 100% / 100
Photography-Secret.com Ogólna ocena
4.8- 96% / 100