Преглед на JPEG.webpmini сървър

Anonim

След като имах възможност да тествам и прегледам софтуера JPEG.webpmini Pro, разбрах колко мощен е този софтуер не само за експортиране на изображения и като част от работния процес на Lightroom, но и за много други приложения, включително оптимизиране на изображения, които вече се намират на нашия големи устройства за съхранение. Друга употреба, за която веднага се сетих, беше уеб сървърът, откъдето произхожда трафикът Photo-Secret.com. Като се има предвид колко трафик Photo-Secret.com обслужва ежедневно в световен мащаб и фактът, че само изображенията представляват приблизително 5 терабайта трафик на месец, мисълта за възможността да компресирате JPEG.webp изображения с помощта на JPEG.webpmini двигател беше нещо че наистина исках да приложа по-рано от по-късно. Затова се заех с нов проект - да спестя трафик и пари в дългосрочен план за PL, използвайки JPEG.webpmini сървъра.

Фотографи Внимавайте: това е много технически преглед на софтуер, който не е свързан с фотографията. Реших да публикувам рецензията в PL, тъй като смятам, че други уебсайтове с тежка фотография могат да се възползват изключително много от внедряването на JPEG.webpmini сървъра.

1) Преглед на сървърната среда

Преди да вляза в прегледа, бих искал да посоча няколко потенциално важни бита информация за настройката на моя уеб сървър. На първо място, стартирам CentOS Linux на всеки сървър (и има няколко от тях). Двата back-end уеб сървъра, които обработват PHP повиквания от балансиращото натоварване, е мястото, където инсталирах JPEG.webpmini сървър, въпреки че само първият наистина има значение, тъй като той е този, който обработва всички качвания на сайта (WordPress не може да се справи директно с това, така че възможно е само да наблюдавате повиквания на wp-admin и да ги насочвате към съответния сървър чрез nginx / apache). За съжаление, няма лесен начин да стартирате повече от един WordPress сървър без качване на файлове, тъй като той не е проектиран да се използва в клъстерна среда (преместване на всичко в AWS с екземпляри на сървър на EC2, RDS с DB и S3, обработващи файловете би било добро решение, но след като го тествах, това по никакъв начин не беше евтино решение, особено след като започнете да хвърляте хайвера на няколко EC2 сървъра, които биха се справили с натоварването отзад). Следователно синхронизирам всички качвания чрез rsync. Не е елегантно решение, но работи доста добре. Имам rsync наблюдение на папката “wp-content”, така че всички промени се репликират по един начин (основно, след като изображенията бъдат качени на server01, те автоматично се взимат от server02). Синхронизирането отнема секунда или две, но след като се случи, изображенията се обслужват лесно за зареждане на заявки за балансиране.

Всички обаждания към уеб сървъра се обработват от балансиращ товар, който обслужва само https уеб трафик. Всички изображения се обработват от външен CDN. Основната причина за внедряването на JPEG.webpmini беше да се намалят разходите за CDN, които нарастват само всеки месец, тъй като продължаваме да публикуваме повече съдържание.

Имайте предвид, че вашият уеб сървър трябва да работи с вкус на Linux - JPEG.webpmini сървърът не работи на Windows сървъри. Ето списъка на поддържаните сървърни платформи.

2) Инсталиране на JPEG.webpmini сървър

Инсталирането на JPEG.webpmini сървър е много лесно, особено ако стартирате RHEL, CentOS и други популярни дистрибуции на Linux. За моя сървър CentOS JPEG.webpmini предостави RPM файл, така че беше лесна инсталация с една команда. След като бе инсталиран двоичният файл (/ usr / bin / jpeg.webpmini по подразбиране), следващата стъпка беше да копирате лицензионния файл .jpeg.webpmini.cfg в домашната директория на потребителя. Оттам, стартирането на „jpeg.webpmini“ трябва да изведе нещо като следното:

===============================
Стартирайте jpeg.webpmini 3.14.2.84235
===============================
-f опция се изисква: -f =
Използвайте -help за помощ

===============================
Завършете jpeg.webpmini 3.14.2.84235
===============================

Първоначалното ми тестване започна с JPEG.webpmini сървър версия 3.13, но след няколко поискани промени в изпълнимия файл, JPEG.webpmini предостави актуализиран 3.14 RPM файл. Основното допълнение към версията 3.14 е възможността да пропускам вече оптимизирани файлове, което беше голяма работа за мен, тъй като използвам настолната версия на софтуера и не исках сървърът JPEG.webpmini да оптимизира отново качените JPEG.webp изображения.

3) Работа с файлове с изображения на WordPress

Когато изображението се качи в WordPress, администраторските скриптове ще използват GD или ImageMagick за обработка на тези изображения. По подразбиране WordPress създава изображения с три размера, в допълнение към каченото изображение (миниизображение, среден размер и голям размер), но в зависимост от това колко обаждания add_image_size може да бъдат добавени от темата и приставките, може да има много повече! Поради това качването на едно изображение може да породи куп файлове на сървъра, позволявайки на папката Качвания да расте много бързо. А тези по-малки изображения се създават или от GD, или от ImageMagick, така че файловете по подразбиране ще бъдат премахнати както от ICC цветни профили, така и от EXIF ​​данни, което не е желателно на уебсайта за фотография. Те също няма да бъдат правилно оптимизирани за размер, тъй като нито GD, нито ImageMagick имат интелигентен алгоритъм като JPEG.webpmini, за да могат правилно да компресират JPEG.webp изображения. Всъщност WordPress върши доста ужасна работа с преоразмеряване на изображения, което често води до лошо оцветяване (поради премахване на ICC профили), меки и кални изображения (поради тежко компресиране). За да избегна този проблем в PL, използвам ImageMagick само за оптимизиране на изображения със специални опции. Изваждаме само EXIF ​​данни от миниатюри и ги компресираме малко по-агресивно за бързо преглеждане. Веднъж в публикация, нито ICC профилите, нито EXIF ​​данните се изваждат от по-големи изображения, за да изглеждат възможно най-добре. По този начин ние не принуждаваме нашите читатели да кликват върху изображение, за да видят „правилната версия“ - изображенията изглеждат последователни от визуализациите до естествено качените размери.

Ето защо, за да се възползвате пълноценно от JPEG.webpmini сървъра, най-добре е да стартирате изпълнимия файл за всеки процес за преоразмеряване - не само за единично качената версия, тъй като искате всеки файл да бъде оптимизиран от двигателя, независимо дали е миниатюра, средна или голяма версия на оригинала. Това по същество означава, че JPEG.webpmini трябва да прихваща всяко повикване към image_resize.

4) JPEG.webpmini сървър и интеграция на WordPress

За съжаление, JPEG.webpmini не предоставя плъгин, който автоматично се интегрира в WordPress, за да го направи, така че трябваше да измисля решение сам. Започнах с кодовата база на приставката ImageMagick Engine (доста остаряла приставка, но все още работи), след това добавих извиквания към изпълнимия файл JPEG.webpmini във функцията ime_im_cli_resize (стартирам версия на командния ред на ImageMagick вместо PHP модул). Ако тази модифицирана версия на приставката ви интересува, уведомете ме в раздела за коментари по-долу и ще ви изпратя файла на приставката. Не съм сигурен дали хората от JPEG.webpmini планират да пуснат плъгин за WordPress, но с удоволствие ще дам малко код за добра кауза.

Кодът работи и е тестван с JPEG.webpmini 3.14. Веднага след създаването на всяка преоразмерена версия кодът първо оптимизира тези изображения, след което оптимизира и презаписва оригиналното JPEG.webp изображение.

5) Резултати от теста на JPEG.webpmini сървър

Досега има много технически мумбо джъмбо, така че нека да стигнем до месото. Колко дисково пространство успях да спася и колко спестих в разходи за CDN? За да стартирам изпълнимия файл JPEG.webpmini рекурсивно във всяка папка, трябваше да поискам скрипт от инженерите на JPEG.webpmini, който те предоставиха много бързо. Предоставеният файл беше скрипт на Python, наречен „jpeg.webpmini_recursive.py“, който се нуждаеше само от две команди - една за въвеждане на папката източник и една за въвеждане на целевата папка (модифицирах скрипта малко след като получих новата версия на RPM, която може автоматично да пропусне вече оптимизирани JPEG.webp изображения). След като архивирах всичко, създадох папка, наречена „uploads_jpeg.webpmini“ и това използвах като целевата папка. Пуснах скрипта и отне известно време, за да прегледам всеки файл. Върнах се след няколко часа и скриптът завърши изпълнението.

Тъй като JPEG.webpmini оптимизира само JPEG.webp изображения и не докосва качването на PNG, GIF или други файлове, като видео, трябваше да се уверя, че копирам получената папка обратно в папката си за качване. Отново, уверете се, че сте архивирали напълно всичко, преди да предприемете тази стъпка, тъй като тя е необратима. Преди да направя това, промених рекурсивно разрешенията в папката uploads_jpeg.webpmini, като стартирах “chown -R nobody: nobody / uploads_jpeg.webpmini”. След това следващата команда беше “/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /”, която замени съществуващите файлове с изображения с техните оптимизирани за JPEG.webpmini версии.

Нека да разгледаме преди и след. Ето как изглеждаха папките ми, преди да копирам цялото съдържание:

 

du --max-дълбочина = 1 | сортиране -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 г. Общ размер: 20,945,855

Приблизително 21 гигабайта изображения. Сега нека да разгледаме как изглежда папката, след като всички изображения бяха оптимизирани от JPEG.webpmini:

 

du --max-дълбочина = 1 | сортиране -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 г. Общ размер: 14 375 944

Уау, това са само 14,4 гигабайта сега! Само на място на твърдия диск успях да си върна над 6,5 концерта пространство, което означава около 31% спестяване на пространство. Това е основно една трета от моята сметка за CDN, което е голямо число. И имайте предвид, че последните две + години не спестиха толкова място, колкото по-рано, тъй като вече започнах да оптимизирам изображенията си на работния си плот с JPEG.webpmini Pro преди качването, така че числата, които виждате, са качвания от други членове на екипа, които не използват JPEG.webpmini.

Ето примерен обобщен доклад от JPEG.webpmini за юни 2012 г .:

----------------------------------
ИНФО: Обобщен отчет за папка photographylife.com/wp-content/uploads/2012/06 (включително подпапки):
ИНФОРМАЦИЯ: Общ брой файлове: 372
ИНФОРМАЦИЯ: Общ размер на входните файлове: 42900 KB
ИНФОРМАЦИЯ: Общ размер на изходните файлове: 28480 KB
ИНФО: Съотношение на рекомпресия: 1,51X (34% спестяване)
ИНФОРМАЦИЯ: ----------------------------------

Различните папки дадоха различни числа, но средно това беше между 30-35%, което е много, като се има предвид, че нашият екип е доста добре запознат с поддържането на малки размери на файловете по време на процеса на експортиране (обикновено поддържаме настройките си за експортиране на ниво 10 във Photoshop , което се равнява на 77-84% „качество“ на Lightroom, според нашите JPEG.webp нива на компресия в статията на Photoshop и Lightroom).

5) JPEG.webpmini качество на сървъра и настройки на метаданни

За сайтове, които не се грижат непременно за запазване на висококачествени JPEG.webp изображения с техните метаданни, JPEG.webpmini всъщност може да оптимизира изображенията много по-агресивно. Не исках JPEG.webp изображенията да изглеждат по-зле от първоначално качените, затова запазих настройката по подразбиране “qual = 0”, която запазва най-доброто качество. Други сайтове могат да изберат да работят с високо или средно качество, което ще намали отпечатъка на JPEG.webp файловете много по-агресивно. Също така, човек може да премахне напълно всички метаданни, както и с командата „rmt = 1“ и ако това не е достатъчно, има дори опция за принудително прогресивно извеждане на JPEG.webp на всяко изображение. Сигурен съм, че сайтовете за социални медии като Facebook активно използват такива инструменти, тъй като изображенията и видеоклиповете са огромна част от техните хостинг сметки. За списък на командите, достъпни със сървъра JPEG.webpmini, моля, посетете тази страница.

6) Заключение

Въпреки че продуктът JPEG.webpmini Server определено не е насочен към фотографи, софтуерът е много гъвкав инструмент за тези, които притежават големи уебсайтове с много изображения и трафик. Както се вижда от моя проект за внедряване, JPEG.webpmini Server успя да спести над 6,5 гигабайта пространство, което означава около 31% в пространството и CDN икономии на разходи, което е много за бизнес от всякакъв размер. На $ 199 на месец начална цена, JPEG.webpmini Server не е евтин за малък бизнес, но за развиваща се компания с голям хостинг отпечатък, където един сървър може да струва повече от този всеки месец, продуктът може да си струва сериозен поглед . Ако сте част от хостинг компания, ако притежавате уебсайт, натоварен с много изображения като PL, или разходите ви за CDN стават скандални, може да искате да се свържете с хора в JPEG.webpmini и да говорите с тях за това как могат да ти помогна. За начало можете да изпробвате тази страница, където можете да въведете своя уебсайт и да видите колко можете да очаквате да спестите от разходите за CDN.

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

JPEG.webpmini сървър
  • Характеристика- 100% / 100
  • Стойност- 100% / 100
  • Лесно използване- 80% / 100
  • Скорост и производителност- 100% / 100
  • Стабилност- 100% / 100
  • поддържа- 100% / 100

Обща оценка на Photography-Secret.com

4.8- 96% / 100