JPEG.webpmini Server Review

Etter at jeg hadde sjansen til å teste og gjennomgå JPEG.webpmini Pro-programvaren, innså jeg hvor kraftig denne programvaren ikke bare er for å eksportere bilder og være en del av en Lightroom-arbeidsflyt, men også for mange andre bruksområder, inkludert å optimalisere bilder som allerede sitter på vår store lagringsenheter. En annen bruk jeg umiddelbart tenkte på, var webserveren der Photography-Secret.com trafikk stammer fra. Gitt hvor mye trafikk Photography-Secret.com serverer over hele verden på daglig basis og det faktum at bilder alene utgjør omtrent 5 Terabyte trafikk per måned, var tanken på å kunne komprimere JPEG.webp-bilder ved hjelp av JPEG.webpmini-motoren noe som jeg virkelig ønsket å implementere før enn senere. Så jeg begynte på et nytt prosjekt - for å spare både trafikk og penger på sikt for PL, ved hjelp av JPEG.webpmini-serveren.

Fotografer Pass opp: dette er en veldig teknisk gjennomgang av programvare som ikke er relatert til fotografering. Jeg bestemte meg for å publisere anmeldelsen på PL, siden jeg føler at andre fotograferingstunge nettsteder kan ha stor nytte av å implementere JPEG.webpmini-serveren.

1) Oversikt over servermiljø

Før jeg går inn i gjennomgangen, vil jeg påpeke noen potensielt viktige biter av informasjon om webserveroppsettet mitt. Først og fremst kjører jeg CentOS Linux på hver server (og det er noen få av dem). De to back-end webserverne som håndterer PHP-anrop fra lastbalanseren er der jeg installerte JPEG.webpmini-serveren, selv om bare den første virkelig betyr noe, da det er den som håndterer alle opplastinger til nettstedet (WordPress kan ikke håndtere dette direkte, så det er bare mulig å se etter wp-admin-samtaler og dirigere dem til riktig server via nginx / apache). Dessverre er det ingen enkel måte å kjøre mer enn en WordPress-server uten problemer med filopplasting, siden den ikke er designet for å brukes i et klyngemiljø (flytter alt til AWS med EC2-kjørende serverforekomster, RDS som kjører DB og S3 som håndterer filer ville være en god løsning, men etter at jeg hadde testet det ut, var det på ingen måte en billig løsning, spesielt når du begynte å gyte noen få EC2-servere som ville håndtere back-end-belastningen). Derfor har jeg synkronisert alle opplastinger via rsync. Ikke en elegant løsning, men den fungerer ganske bra. Jeg har rsync overvåking av "wp-content" -mappen, så alle endringer replikeres på en måte (når bilder er lastet opp til server01, blir de automatisk hentet av server02). Tar et sekund eller to å synkronisere, men når det skjer, blir bildene enkelt servert for å laste inn forespørsler om balansering.

Alle anrop til webserveren håndteres av en belastningsutjevner, som kun betjener https-nettrafikk. Alle bilder håndteres av en ekstern CDN. Hovedårsaken til implementering av JPEG.webpmini var å redusere CDN-kostnadene, som bare øker hver måned når vi fortsetter å publisere mer innhold.

Husk at webserveren din må kjøre en smak av Linux - JPEG.webpmini-serveren kjører ikke på Windows-servere. Her er listen over støttede serverplattformer.

2) JPEG.webpmini-serverinstallasjon

Installasjonen av JPEG.webpmini-serveren er veldig enkel, spesielt hvis du kjører RHEL, CentOS og andre populære Linux-distribusjoner. For CentOS-serveren min ga JPEG.webpmini en RPM-fil, så det var en enkel installasjon med en enkelt kommando. Når den binære filen var installert (/ usr / bin / jpeg.webpmini som standard), var neste trinn å kopiere .jpeg.webpmini.cfg-lisensfilen i brukerens hjemmekatalog. Derfra skal "jpeg.webpmini" kjøres ut som følgende:

===============================
Start jpeg.webpmini 3.14.2.84235
===============================
-f alternativ kreves: -f =
Bruk -help for hjelp

===============================
Fullfør jpeg.webpmini 3.14.2.84235
===============================

Min første testing startet med JPEG.webpmini-serverversjonen 3.13, men etter noen få forespurte endringer i den kjørbare filen, ga JPEG.webpmini en oppdatert 3.14 RPM-fil. Det viktigste tilskuddet til 3.14-versjonen er muligheten til å hoppe over allerede optimaliserte filer, noe som var en stor avtale for meg, siden jeg bruker skrivebordsversjonen av programvaren og ikke ønsket at JPEG.webpmini-serveren skulle optimalisere opplastede JPEG.webp-bilder på nytt.

3) Håndtering av WordPress-bildefiler

Når et bilde blir lastet opp til WordPress, vil administratorskriptene enten bruke GD eller ImageMagick til å behandle disse bildene. Som standard lager WordPress bilder i tre størrelser, i tillegg til det opplastede bildet (miniatyrbilde, middels størrelse og stor størrelse), men avhengig av hvor mange add_image_size samtaler det kan legges til av temaet og plugins, kan det være mange flere! På grunn av dette kan en enkelt bildeopplasting gyte en haug med filer på serveren, slik at opplastingsmappen vokser veldig raskt. Og de mindre bildene er laget av enten GD eller ImageMagick, så filene blir som standard fjernet fra både ICC-fargeprofiler og EXIF-data, noe som ikke er ønskelig på et fotograferingsnettsted. De kommer heller ikke til å være riktig optimalisert for størrelse, siden verken GD eller ImageMagick har en smart algoritme som JPEG.webpmini for å kunne komprimere JPEG.webp-bilder riktig. Faktisk gjør WordPress en ganske forferdelig jobb med å endre størrelse på bilder, noe som ofte resulterer i dårlig fargede (på grunn av stripping av ICC-profiler), myke og gjørmete bilder (på grunn av tung komprimering). For å unngå dette problemet hos PL, har jeg bare brukt ImageMagick til å optimalisere bilder, med spesielle alternativer. Vi fjerner bare EXIF-data fra miniatyrbilder og komprimerer dem litt mer aggressivt for en rask nettopplevelse. En gang i et innlegg blir verken ICC-profiler eller EXIF-data fjernet fra større bilder for å få dem til å se så bra ut som mulig. På denne måten tvinger vi ikke våre lesere til å klikke på et bilde for å se den “riktige versjonen” - bilder ser konsistente ut fra forhåndsvisning til opprinnelige opplastede størrelser.

Derfor, for å dra full nytte av JPEG.webpmini-serveren, er det best å kjøre den kjørbare for hver endringsprosess - ikke bare for den enkeltopplastede versjonen, da du vil at hver fil skal bli optimalisert av motoren, enten det er en miniatyrbilde, et medium eller en stor versjon av originalen. Dette betyr i hovedsak at JPEG.webpmini skal fange opp alle anrop til image_resize.

4) JPEG.webpmini Server og WordPress-integrasjon

Dessverre gir JPEG.webpmini ikke et plugin som automatisk integreres i WordPress for å gjøre det, så jeg måtte komme med en løsning på egen hånd. Jeg startet med ImageMagick Engine-plugin-kodebasen (et ganske utdatert plugin, men det fungerer fremdeles), og la deretter til anrop til JPEG.webpmini-kjørbar i ime_im_cli_resize-funksjonen (jeg kjører en kommandolinjeversjon av ImageMagick i stedet for en PHP-modul). Hvis denne modifiserte versjonen av pluginet er noe som interesserer deg, gi meg beskjed i kommentarfeltet nedenfor, så sender jeg plugin-filen. Jeg er ikke sikker på om folk på JPEG.webpmini planlegger å gi ut et WordPress-plugin, men jeg vil gjerne bidra med litt kode for en god sak.

Koden fungerer, og den er testet med JPEG.webpmini 3.14. Så snart hver endrede størrelseversjon er opprettet, optimaliserer koden først bildene, deretter optimaliserer den og overskriver det originale JPEG.webp-bildet.

5) Resultater av JPEG.webpmini-servertest

Det har vært mye teknisk mumbo-jumbo så langt, så la oss komme ned til kjøttet. Hvor mye stasjonsplass klarte jeg å berges og hvor mye sparte jeg i CDN-kostnader? For å kjøre JPEG.webpmini-kjørbarheten rekursivt på hver mappe, måtte jeg be om et skript fra JPEG.webpmini-ingeniører, som de ga veldig raskt. Den medfølgende filen var et Python-skript kalt “jpeg.webpmini_recursive.py”, som bare trengte to kommandoer - en for å legge inn kildemappen og en for å legge inn målmappen (jeg endret skriptet litt etter å ha fått den nye RPM-versjonen som automatisk kan hoppe over allerede optimaliserte JPEG.webp-bilder). Etter å ha sikkerhetskopiert alt, opprettet jeg en mappe som heter "uploads_jpeg.webpmini", og det var det jeg brukte som målmappe. Jeg kjørte skriptet, og det tok litt tid å gå gjennom hver fil. Jeg kom tilbake etter noen timer, og manuset ble ferdig utført.

Siden JPEG.webpmini bare optimaliserer JPEG.webp-bilder og den ikke berører PNG, GIF eller andre filopplastinger som video, måtte jeg sørge for å kopiere den resulterende mappen tilbake til opplastingsmappen. Igjen, sørg for at du sikkerhetskopierer alt før du tar dette trinnet, siden det er irreversibelt. Før jeg gjorde det, endret jeg rekursivt tillatelsene til mappen uploads_jpeg.webpmini ved å kjøre "chown -R none: none / uploads_jpeg.webpmini". Så var neste kommando “/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /”, som overskrev eksisterende bildefiler med sine JPEG.webpmini-optimaliserte versjoner.

La oss ta en titt på før og etter. Slik så mappene mine ut før jeg kopierte alt innholdet:

 
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 Total størrelse: 20 945 855

Omtrent 21 gigabyte bilder. La oss nå se på hvordan mappen så ut etter at alle bildene ble optimalisert av 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 Total størrelse: 14 375 944

Whoa, det er bare 14,4 gigabyte nå! Bare på harddiskplassen alene klarte jeg å gjenvinne over 6,5 konserter, noe som tilsvarer omtrent 31% av plassbesparelsene. Det er i utgangspunktet en tredjedel av CDN-regningen min, som er et stort tall. Og husk at de siste to + årene ikke fikk så mye plassbesparelser som tidligere, siden jeg allerede begynte å optimalisere bildene mine på skrivebordet mitt med JPEG.webpmini Pro før du lastet opp, så tallene du ser er lastet opp av andre lagmedlemmer som ikke bruker JPEG.webpmini.

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

----------------------------------
INFO: Sammendragsrapport for mappen photographylife.com/wp-content/uploads/2012/06 (inkludert undermapper):
INFO: Totalt antall filer: 372
INFO: Total størrelse på inndatafiler: 42900 KB
INFO: Total størrelse på utdatafiler: 28480 KB
INFO: Kompresjonsforhold: 1,51X (34% besparelse)
INFO: ----------------------------------

Ulike mapper ga forskjellige tall, men i gjennomsnitt var det mellom 30-35%, noe som er mye, med tanke på at teamet vårt er ganske kunnskapsrik om å holde filstørrelser små under eksportprosessen (vi holder vanligvis eksportinnstillingene våre på nivå 10 i Photoshop. , som tilsvarer Lightrooms 77-84% “kvalitet”, i henhold til JPEG.webp-kompresjonsnivåene i Photoshop og Lightroom-artikkelen).

5) Innstillinger for JPEG.webpmini serverkvalitet og metadata

For nettsteder som ikke nødvendigvis bryr seg om å bevare JPEG.webp-bilder av høy kvalitet med metadataene sine, kan JPEG.webpmini faktisk optimalisere bilder mye mer aggressivt. Jeg ønsket ikke at JPEG.webp-bilder skulle se dårligere ut enn opprinnelig lastet opp, så jeg beholdt standardinnstillingen "qual = 0", som bevarer den beste kvaliteten. Andre nettsteder kan velge å kjøre med høy eller middels kvalitet, noe som vil redusere fotavtrykket til JPEG.webp-filer mye mer aggressivt. Man kan også fjerne alle metadataene også med kommandoen "rmt = 1", og hvis det ikke er nok, er det til og med et alternativ å tvinge progressiv JPEG.webp-utgang på hvert bilde. Jeg er sikker på at sosiale medier som Facebook i stor grad bruker slike verktøy, siden bilder og videoer er en stor del av deres hostingregninger. For en liste over kommandoer som er tilgjengelige med JPEG.webpmini-serveren, besøk denne siden.

6) Konklusjon

Mens JPEG.webpmini Server-produktet absolutt ikke er rettet mot fotografer, er programvaren et veldig allsidig verktøy for de som eier store nettsteder med mye bilder og trafikk. Som det fremgår av implementeringsprosjektet mitt, var JPEG.webpmini Server i stand til å spare over 6,5 gigabyte plass, oversatt til omtrent 31% i plass og CDN-kostnadsbesparelser, noe som er mye for en virksomhet i alle størrelser. Til en pris på $ 199 per måned, er JPEG.webpmini Server ikke billig for en liten bedrift, men for et voksende selskap med et stort hostingavtrykk der en enkelt serverforekomst kan koste mer enn det hver måned, kan produktet være verdt å se seriøst . Hvis du er en del av et vertsfirma, hvis du eier et nettsted lastet med mange bilder som PL, eller hvis CDN-kostnadene dine blir opprørende, vil du kanskje kontakte folk på JPEG.webpmini og snakke med dem om hvordan de kan hjelpe deg. For en start kan du prøve denne siden, der du kan legge inn nettstedet ditt og se hvor mye du kan forvente å spare i CDN-kostnader.

Hvis du har spørsmål om noe av det ovennevnte, kan du gjerne sende meg en kommentar nedenfor.