JPEG.webpmini Server Review

Efter at jeg havde haft en chance for at teste og gennemgå JPEG.webpmini Pro-softwaren, indså jeg, hvor kraftig denne software ikke kun er til at eksportere billeder og være en del af en Lightroom-arbejdsgang, men også til mange andre anvendelser, herunder optimering af billeder, der allerede sidder på vores store lagerenheder. En anden anvendelse, jeg straks tænkte på, var webserveren, hvor Photography-Secret.com trafik stammer fra. I betragtning af hvor meget trafik Photography-Secret.com tjener over hele verden på daglig basis og det faktum, at billeder alene tegner sig for cirka 5 Terabyte trafik om måneden, var tanken om at kunne komprimere JPEG.webp-billeder ved hjælp af JPEG.webpmini-motoren noget at jeg virkelig ville implementere hurtigere end senere. Så jeg påbegyndte et nyt projekt - for at spare både trafik og penge i det lange løb for PL ved hjælp af JPEG.webpmini-serveren.

Fotografer Pas på: dette er en meget teknisk gennemgang af software, der ikke er relateret til fotografering. Jeg besluttede at offentliggøre anmeldelsen hos PL, da jeg føler, at andre fotograferingstunge websteder enormt kunne drage fordel af at implementere JPEG.webpmini-serveren.

1) Oversigt over servermiljø

Før jeg går ind i gennemgangen, vil jeg gerne påpege et par potentielt vigtige informationer om min webserveropsætning. Først og fremmest kører jeg CentOS Linux på hver server (og der er et par af dem). De to back-end webservere, der håndterer PHP-opkald fra load balancer, er hvor jeg installerede JPEG.webpmini-serveren, selvom kun den første virkelig betyder noget, da det er den, der håndterer alle uploads til webstedet (WordPress kan ikke håndtere dette direkte, så det er kun muligt at se efter wp-admin-opkald og dirigere dem til den relevante server via nginx / apache). Desværre er der ingen nem måde at køre mere end én WordPress-server uden besvær med filupload, da den ikke er designet til at blive brugt i et klyngemiljø (flytter alt til AWS med EC2-kørende serverinstanser, RDS, der kører DB og S3, der håndterer filer ville være en god løsning, men efter at jeg havde testet det, var det på ingen måde en billig løsning, især ikke når man begynder at gyde et par EC2-servere, der kan håndtere back-end-belastningen). Derfor har jeg synkroniseret alle uploads via rsync. Ikke en elegant løsning, men det fungerer ret godt. Jeg har rsync til at overvåge mappen "wp-content", så alle ændringer replikeres på en måde (dybest set, når billeder først er uploadet til server01, bliver de automatisk hentet af server02). Det tager et sekund eller to at synkronisere, men når det sker, bliver billederne let serveret for at indlæse balanceranmodninger.

Alle webserveropkald håndteres af en load balancer, der kun tjener https-webtrafik. Alle billeder håndteres af en ekstern CDN. Hovedårsagen til implementering af JPEG.webpmini var at reducere CDN-omkostningerne, som kun stiger hver måned, da vi fortsætter med at udgive mere indhold.

Husk, at din webserver skal køre en smag af Linux - JPEG.webpmini-serveren kører ikke på Windows-servere. Her er listen over understøttede serverplatforme.

2) Installation af JPEG.webpmini-server

Installationen af JPEG.webpmini-serveren er meget let, især hvis du kører RHEL, CentOS og andre populære Linux-distributioner. For min CentOS-server leverede JPEG.webpmini en RPM-fil, så det var en nem installation med en enkelt kommando. Når den binære fil blev installeret (/ usr / bin / jpeg.webpmini som standard), var det næste trin at kopiere .jpeg.webpmini.cfg-licensfilen i brugerens hjemmekatalog. Derefter skal køre "jpeg.webpmini" sende noget som følgende:

===============================
Start jpeg.webpmini 3.14.2.84235
===============================
-f option er påkrævet: -f =
Brug -hjælp til hjælp

===============================
Afslut jpeg.webpmini 3.14.2.84235
===============================

Min første test startede med JPEG.webpmini-serverversion 3.13, men efter et par anmodede ændringer til den eksekverbare, leverede JPEG.webpmini en opdateret 3.14 RPM-fil. Den største tilføjelse til 3.14-versionen er muligheden for at springe allerede optimerede filer over, hvilket var en stor ting for mig, da jeg bruger desktopversionen af softwaren, og jeg ikke ønskede, at JPEG.webpmini-serveren skulle genoptimere uploadede JPEG.webp-billeder.

3) Håndtering af WordPress-billedfiler

Når et billede uploades til WordPress, bruger admin-scripts enten GD eller ImageMagick til at behandle disse billeder. Som standard opretter WordPress billeder i tre størrelser ud over det uploadede billede (miniaturebillede, mellemstørrelse og stor størrelse), men afhængigt af hvor mange add_image_size-opkald der muligvis tilføjes af temaet og plugins, kan der være mange flere! På grund af dette kan en enkelt billedoverførsel gyde en masse filer på serveren og lade mappen Uploads vokse meget hurtigt. Og de mindre billeder oprettes af enten GD eller ImageMagick, så filerne som standard fjernes for både ICC-farveprofiler og EXIF-data, hvilket ikke er ønskeligt på et fotograferingswebsted. De vil heller ikke blive optimeret korrekt til størrelse, da hverken GD eller ImageMagick har en smart algoritme som JPEG.webpmini for at kunne komprimere JPEG.webp-billeder korrekt. Faktisk gør WordPress et ret forfærdeligt job med at ændre størrelse på billeder, hvilket ofte resulterer i dårligt farvede (på grund af stripping af ICC-profiler), bløde og mudrede billeder (på grund af kraftig komprimering). For at undgå dette problem hos PL har jeg kun brugt ImageMagick til at optimere billeder med specielle muligheder. Vi fjerner kun EXIF-data fra miniaturer og komprimerer dem lidt mere aggressivt for en hurtig browseroplevelse. En gang i et indlæg fjernes hverken ICC-profiler eller EXIF-data fra større billeder for at få dem til at se så godt ud som muligt. På denne måde tvinger vi ikke vores læsere til at klikke på et billede for at se den "rigtige version" - billeder ser ensartede ud fra eksempler til oprindelige uploadede størrelser.

For at udnytte JPEG.webpmini-serveren fuldt ud er det bedst at køre den eksekverbare fil for hver ændringsstørrelsesproces - ikke kun for den enkelt uploadede version, da du vil have, at hver fil bliver optimeret af motoren, uanset om det er en miniaturebillede, et medium eller en stor version af originalen. Dette betyder i det væsentlige, at JPEG.webpmini skal opfange hvert opkald til image_resize.

4) JPEG.webpmini Server og WordPress-integration

Desværre giver JPEG.webpmini ikke et plugin, der automatisk integreres i WordPress for at gøre det, så jeg var nødt til at komme med en løsning alene. Jeg startede med ImageMagick Engine-plugin-kodebasen (et ret forældet plugin, men det fungerer stadig) og tilføjede derefter opkald til JPEG.webpmini-eksekverbar i ime_im_cli_resize-funktionen (jeg kører en kommandolinieversion af ImageMagick i stedet for et PHP-modul). Hvis denne ændrede version af pluginet er noget, der interesserer dig, så lad mig det vide i kommentarfeltet nedenfor, og jeg vil sende dig plugin-filen. Jeg er ikke sikker på, om folk på JPEG.webpmini planlægger at frigive et WordPress-plugin, men jeg vil med glæde bidrage med noget kode til en god sag.

Koden fungerer, og den er testet med JPEG.webpmini 3.14. Så snart hver ændret størrelse er oprettet, optimerer koden først disse billeder, derefter optimeres og overskriver det originale JPEG.webp-billede.

5) JPEG.webpmini-server testresultater

Der har været meget teknisk mumbo-jumbo indtil videre, så lad os komme ned til kødet. Hvor meget drevplads kunne jeg redde, og hvor meget sparede jeg i CDN-omkostninger? For at køre den JPEG.webpmini eksekverbare rekursivt på hver mappe, måtte jeg anmode om et script fra JPEG.webpmini-ingeniører, som de leverede meget hurtigt. Den leverede fil var et Python-script kaldet “jpeg.webpmini_recursive.py”, som kun havde brug for to kommandoer - en til at indtaste kildemappen og en til at indtaste målmappen (jeg ændrede scriptet lidt efter at have fået den nye RPM-version, der automatisk kan springe over allerede optimerede JPEG.webp-billeder). Efter at have sikkerhedskopieret alt oprettede jeg en mappe kaldet “uploads_jpeg.webpmini”, og det var det, jeg brugte som målmappe. Jeg kørte scriptet, og det tog et stykke tid at gennemgå hver eneste fil. Jeg kom tilbage efter et par timer, og scriptet blev udført.

Da JPEG.webpmini kun optimerer JPEG.webp-billeder, og den ikke rører ved PNG, GIF eller andre filoverførsler som f.eks. Video, var jeg nødt til at sørge for at kopiere den resulterende mappe tilbage til min uploadmappe. Igen skal du sørge for at sikkerhedskopiere alt, inden du tager dette trin, da det er irreversibelt. Før jeg gjorde det, ændrede jeg rekursivt tilladelser til mappen uploads_jpeg.webpmini ved at køre "chown -R ingen: ingen / uploads_jpeg.webpmini". Derefter var den næste kommando “/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /”, som overskrev eksisterende billedfiler med deres JPEG.webpmini-optimerede versioner.

Lad os se på det før og efter. Sådan ser mine mapper ud, før jeg kopierede alt indholdet over:

 
du --max-depth = 1 | sorter -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 Samlet størrelse: 20.945.855

Cirka 21 gigabyte billeder. Lad os nu se på, hvordan mappen så ud, efter at alle billederne var optimeret af JPEG.webpmini:

 
du --max-depth = 1 | sorter -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 Samlet størrelse: 14.375.944

Whoa, det er kun 14,4 gigabyte nu! Bare i harddiskpladsen alene var jeg i stand til at genvinde over 6,5 optagelser plads, hvilket svarer til cirka 31% i pladsbesparelser. Det er dybest set en tredjedel af min CDN-regning, hvilket er et stort tal. Og husk, at de sidste to + år ikke fik så meget pladsbesparelser som tidligere, da jeg allerede begyndte at optimere mine billeder på mit skrivebord med JPEG.webpmini Pro inden upload, så de numre, du ser, uploades af andre teammedlemmer, der ikke bruger JPEG.webpmini.

Her er en eksempeloversigt fra JPEG.webpmini for juni 2012:

----------------------------------
INFO: Resumérapport for mappen photographylife.com/wp-content/uploads/2012/06 (inklusive undermapper):
INFO: Samlet antal filer: 372
INFO: Total størrelse af inputfiler: 42900 KB
INFO: Total størrelse af outputfiler: 28480 KB
INFO: Komprimeringsforhold: 1,51X (34% besparelse)
INFO: ----------------------------------

Forskellige mapper gav forskellige tal, men i gennemsnit var det mellem 30-35%, hvilket er meget, i betragtning af at vores team er ret vidende om at holde filstørrelser små under eksportprocessen (vi holder normalt vores eksportindstillinger på niveau 10 i Photoshop , hvilket svarer til Lightrooms 77-84% “kvalitet” i henhold til vores JPEG.webp-kompressionsniveauer i Photoshop og Lightroom-artiklen).

5) JPEG.webpmini serverkvalitet og metadataindstillinger

For websteder, der ikke nødvendigvis er interesserede i at bevare JPEG.webp-billeder i høj kvalitet med deres metadata, kan JPEG.webpmini faktisk optimere billeder meget mere aggressivt. Jeg ønskede ikke, at JPEG.webp-billeder skulle se dårligere ud end oprindeligt uploadet, så jeg bevarede standardindstillingen "qual = 0", hvilket bevarer den bedste kvalitet. Andre websteder vælger muligvis at køre med høj eller medium kvalitet, hvilket vil reducere JPEG.webp-filernes fodaftryk meget mere aggressivt. Man kan også helt fjerne alle metadataene med kommandoen “rmt = 1”, og hvis det ikke er nok, er der endda en mulighed for at tvinge progressiv JPEG.webp-output på hvert billede. Jeg er sikker på, at sociale mediesider som Facebook i høj grad bruger sådanne værktøjer, da billeder og videoer er en stor del af deres hostingregninger. Besøg denne side for en liste over kommandoer, der er tilgængelige med JPEG.webpmini-serveren.

6) Konklusion

Mens JPEG.webpmini Server-produktet bestemt ikke er rettet mod fotografer, er softwaren et meget alsidigt værktøj til dem, der ejer store websteder med mange billeder og trafik. Som det kan ses af mit implementeringsprojekt, var JPEG.webpmini Server i stand til at spare over 6,5 gigabyte plads, hvilket oversatte til omkring 31% i plads og CDN-omkostningsbesparelser, hvilket er meget for en virksomhed af enhver størrelse. Til en pris på $ 199 pr. Måned er JPEG.webpmini Server ikke billig for en lille virksomhed, men for et voksende firma med et stort hostingfodaftryk, hvor en enkelt serverforekomst måske koster mere end det hver måned, kan produktet være et seriøst værd værd . Hvis du er en del af et hostingfirma, hvis du ejer et websted, der er fyldt med mange billeder som PL, eller dine CDN-omkostninger bliver uhyrlige, vil du muligvis nå ud til folk på JPEG.webpmini og tale med dem om, hvordan de kan hjælpe dig. Til at begynde med kan du prøve denne side, hvor du kan indtaste dit websted og se, hvor meget du kan forvente at spare i CDN-omkostninger.

Hvis du har spørgsmål om noget af ovenstående, er du velkommen til at sende mig en kommentar nedenfor.