JPEG.webpmini Server Review

Efter att jag fick chansen att testa och granska JPEG.webpmini Pro-programvaran insåg jag hur kraftfull den här programvaran inte bara är för att exportera bilder och vara en del av ett Lightroom-arbetsflöde utan också för många andra användningsområden, inklusive optimering av bilder som redan sitter på vår stora lagringsenheter. En annan användning som jag omedelbart tänkte på var webbservern där Photography-Secret.com-trafiken kommer från. Med tanke på hur mycket trafik Photography-Secret.com serverar över hela världen dagligen och det faktum att bilder ensam står för ungefär 5 Terabyte trafik per månad, var tanken på att kunna komprimera JPEG.webp-bilder med JPEG.webpmini-motorn något som jag verkligen ville implementera förr än senare. Så jag påbörjade ett nytt projekt - för att spara både trafik och pengar på sikt för PL med JPEG.webpmini-servern.

Fotografer Akta dig: detta är en mycket teknisk granskning av programvara som inte är relaterad till fotografering. Jag bestämde mig för att publicera recensionen på PL, eftersom jag känner att andra fotograferings-tunga webbplatser kan ha stor nytta av att implementera JPEG.webpmini-servern.

1) Servermiljööversikt

Innan jag går in i recensionen vill jag påpeka några potentiellt viktiga bitar av information om min webbserverinstallation. Först och främst kör jag CentOS Linux på varje server (och det finns några av dem). De två back-end-webbservrarna som hanterar PHP-samtal från belastningsutjämnaren är där jag installerade JPEG.webpmini-servern, även om bara den första verkligen betyder något, eftersom det är den som hanterar alla uppladdningar till webbplatsen (WordPress kan inte hantera detta direkt, så det är bara möjligt att titta efter wp-admin-samtal och dirigera dem till lämplig server via nginx / apache). Tyvärr finns det inget enkelt sätt att köra mer än en WordPress-server utan problem med filöverföring, eftersom den inte är utformad för att användas i en klustermiljö (flyttar allt till AWS med EC2-körande serverinstanser, RDS som kör DB och S3 hanterar filer skulle vara en bra lösning, men efter att jag testat det var det inte en billig lösning på något sätt, speciellt när du börjar leka några EC2-servrar som skulle hantera backend-belastningen). Därför har jag synkroniserat alla uppladdningar via rsync. Inte en elegant lösning, men det fungerar ganska bra. Jag har rsync-övervakning av mappen "wp-content", så alla ändringar replikeras på ett sätt (i princip, när bilder har laddats upp till server01, plockas de automatiskt upp av server02). Det tar en sekund eller två att synkronisera, men när det händer blir bilderna enkelt serverade för att ladda balanseringsförfrågningar.

Alla webbserversamtal hanteras av en belastningsutjämnare som endast tjänar https-webbtrafik. Alla bilder hanteras av en extern CDN. Den främsta anledningen till att implementera JPEG.webpmini var att minska CDN-kostnaderna, som bara ökar varje månad när vi fortsätter att publicera mer innehåll.

Tänk på att din webbserver måste ha en smak av Linux - JPEG.webpmini-servern körs inte på Windows-servrar. Här är listan över serverplattformar som stöds.

2) Installation av JPEG.webpmini-server

Installationen av JPEG.webpmini-servern är väldigt lätt, särskilt om du kör RHEL, CentOS och andra populära Linux-distributioner. För min CentOS-server tillhandahöll JPEG.webpmini en RPM-fil, så det var en enkel installation med ett enda kommando. När den binära filen var installerad (/ usr / bin / jpeg.webpmini som standard) var nästa steg att kopiera .jpeg.webpmini.cfg-licensfilen i användarens hemkatalog. Därifrån ska körning av "jpeg.webpmini" mata ut något som följande:

===============================
Starta jpeg.webpmini 3.14.2.84235
===============================
-f-alternativ krävs: -f =
Använd -hjälp för hjälp

===============================
Avsluta jpeg.webpmini 3.14.2.84235
===============================

Min första testning började med JPEG.webpmini-serverversion 3.13, men efter några begärda ändringar i den körbara filen tillhandahöll JPEG.webpmini en uppdaterad 3.14 RPM-fil. Det största tillskottet till 3.14-versionen är möjligheten att hoppa över redan optimerade filer, vilket var en stor sak för mig, eftersom jag använder skrivbordsversionen av programvaran och inte ville att JPEG.webpmini-servern skulle återoptimera uppladdade JPEG.webp-bilder.

3) WordPress-filhantering

När en bild laddas upp till WordPress kommer administratörsskripten antingen att använda GD eller ImageMagick för att bearbeta dessa bilder. Som standard skapar WordPress bilder i tre storlekar, utöver den uppladdade bilden (miniatyr, medelstor och stor storlek), men beroende på hur många add_image_size-samtal det kan läggas till av temat och plugins, kan det finnas många fler! På grund av detta kan en uppladdning av en enda bild skapa ett gäng filer på servern, vilket gör att Uploads-mappen växer mycket snabbt. Och de mindre bilderna skapas av antingen GD eller ImageMagick, så filerna kommer som standard att tas bort från både ICC-färgprofiler och EXIF-data, vilket inte är önskvärt på en fotograferingswebbplats. De kommer inte heller att optimeras ordentligt för storlek, eftersom varken GD eller ImageMagick har en smart algoritm som JPEG.webpmini för att kunna komprimera JPEG.webp-bilder korrekt. Faktum är att WordPress gör ett ganska hemskt jobb med att ändra storlek på bilder, vilket ofta resulterar i dåligt färgade (på grund av strippning av ICC-profiler), mjuka och leriga bilder (på grund av tung komprimering). För att undvika detta problem på PL har jag bara använt ImageMagick för att optimera bilder med speciella alternativ. Vi tar bara bort EXIF-data från miniatyrer och komprimerar dem lite mer aggressivt för en snabb surfupplevelse. En gång i ett inlägg tas varken ICC-profiler eller EXIF-data bort från större bilder för att få dem att se så bra ut som möjligt. På det här sättet tvingar vi inte våra läsare att klicka på en bild för att se "rätt version" - bilder ser konsekvent ut från förhandsgranskningar till ursprungliga uppladdade storlekar.

För att dra full nytta av JPEG.webpmini-servern är det bäst att köra körbarheten för varje storleksprocess - inte bara för den enskilt uppladdade versionen, eftersom du vill att varje fil ska optimeras av motorn, oavsett om det är en miniatyrbild, ett medium eller en stor version av originalet. Detta innebär i huvudsak att JPEG.webpmini ska fånga upp varje samtal för att bildstorlek.

4) JPEG.webpmini Server och WordPress-integration

Tyvärr tillhandahåller JPEG.webpmini inte ett plugin som automatiskt integreras i WordPress för att göra det, så jag var tvungen att komma på en lösning på egen hand. Jag började med ImageMagick Engine-plugin-kodbasen (ett ganska föråldrat plugin, men det fungerar fortfarande) och lade sedan till samtal till JPEG.webpmini-körbar i ime_im_cli_resize-funktionen (jag kör en kommandoradsversion av ImageMagick istället för en PHP-modul). Om den här modifierade versionen av plugin är något som intresserar dig, låt mig veta i kommentarfältet nedan så skickar jag plugin-filen. Jag är inte säker på om folk på JPEG.webpmini planerar att släppa ett WordPress-plugin, men jag skulle gärna kunna bidra med lite kod för ett gott ändamål.

Koden fungerar och den har testats med JPEG.webpmini 3.14. Så snart varje ändrad version har skapats optimerar koden först bilderna, sedan optimeras och skrivs över original JPEG.webp-bilden.

5) JPEG.webpmini-servertestresultat

Det har varit mycket teknisk mumbojumbo hittills, så låt oss gå ner till köttet. Hur mycket hårddiskutrymme kunde jag rädda och hur mycket sparade jag i CDN-kostnader? För att kunna köra JPEG.webpmini-körningen rekursivt i varje mapp var jag tvungen att begära ett skript från JPEG.webpmini-ingenjörer, som de gav mycket snabbt. Den medföljande filen var ett Python-skript som heter “jpeg.webpmini_recursive.py”, som bara behövde två kommandon - en för att mata in källmappen och en för att mata in målmappen (jag ändrade skriptet lite efter att ha fått den nya RPM-versionen som automatiskt kan hoppa över redan optimerade JPEG.webp-bilder). Efter att ha säkerhetskopierat allt skapade jag en mapp som heter "uploads_jpeg.webpmini" och det är vad jag använde som målmapp. Jag körde skriptet och det tog ett tag att gå igenom varje fil. Jag kom tillbaka efter några timmar och manuset slutfördes.

Eftersom JPEG.webpmini bara optimerar JPEG.webp-bilder och det inte rör vid PNG-, GIF- eller andra filuppladdningar som video, var jag tvungen att se till att kopiera den resulterande mappen tillbaka till min uppladdningsmapp. Återigen, se till att du säkerhetskopierar allt innan du tar det här steget, eftersom det är irreversibelt. Innan jag gjorde det ändrade jag rekursivt behörigheterna i mappen uploads_jpeg.webpmini genom att köra "chown -R ingen: ingen / uploads_jpeg.webpmini". Därefter var nästa kommando “/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /”, som skrivit över befintliga bildfiler med sina JPEG.webpmini-optimerade versioner.

Låt oss ta en titt på före och efter. Här ser mina mappar ut innan jag kopierade allt innehåll över:

 
du --max-depth = 1 | sortera -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 storlek: 20 945 855

Ungefär 21 gigabyte bilder. Låt oss nu titta på hur mappen såg ut efter att alla bilder var optimerade av JPEG.webpmini:

 
du --max-depth = 1 | sortera -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 storlek: 14 375 944

Det är bara 14,4 gigabyte nu! Bara på hårddiskutrymmet ensam kunde jag återvinna över 6,5 spelplatser, vilket motsvarar ungefär 31% i utrymmesbesparingar. Det är i grunden en tredjedel av min CDN-räkning, vilket är ett stort antal. Och kom ihåg att de senaste två + åren inte fick lika mycket platsbesparingar som tidigare, eftersom jag redan började optimera mina bilder på mitt skrivbord med JPEG.webpmini Pro innan jag laddade upp, så siffrorna du ser laddas upp av andra lagmedlemmar som inte använder JPEG.webpmini.

Här är en sammanfattande rapport från JPEG.webpmini för juni 2012:

----------------------------------
INFO: Sammanfattningsrapport för mappen photographylife.com/wp-content/uploads/2012/06 (inklusive undermappar):
INFO: Totalt antal filer: 372
INFO: Total storlek på inmatningsfiler: 42900 KB
INFO: Total storlek på utdatafiler: 28480 kB
INFO: Komprimeringsförhållande: 1,51X (34% besparing)
INFO: ----------------------------------

Olika mappar gav olika nummer, men i genomsnitt låg det mellan 30-35%, vilket är mycket, med tanke på att vårt team är ganska kunnigt om att hålla filstorlekar små under exportprocessen (vi håller vanligtvis våra exportinställningar på nivå 10 i Photoshop , vilket motsvarar Lightrooms 77-84% “kvalitet”, enligt våra JPEG.webp-komprimeringsnivåer i Photoshop och Lightroom-artikeln).

5) Inställningar för JPEG.webpmini serverkvalitet och metadata

För webbplatser som inte nödvändigtvis bryr sig om att bevara högkvalitativa JPEG.webp-bilder med sina metadata kan JPEG.webpmini faktiskt optimera bilder mycket mer aggressivt. Jag ville inte att JPEG.webp-bilder skulle se sämre ut än ursprungligen uppladdade, så jag behöll standardinställningen ”qual = 0”, vilket bibehåller bästa kvalitet. Andra webbplatser kan välja att köra med hög eller medelhög kvalitet, vilket minskar fotavtrycket för JPEG.webp-filer mycket mer aggressivt. Man kan också ta bort alla metadata helt med kommandot “rmt = 1” och om det inte räcker finns det till och med ett alternativ att tvinga fram progressiv JPEG.webp-utmatning på varje bild. Jag är säker på att sociala medier som Facebook använder sådana verktyg i hög grad, eftersom bilder och videor är en stor del av deras värdräkningar. Besök den här sidan för en lista med kommandon som finns tillgängliga med JPEG.webpmini-servern.

6. Sammanfattning

Även om JPEG.webpmini Server-produkten inte riktar sig till fotografer är programvaran ett mycket mångsidigt verktyg för dem som äger stora webbplatser med mycket bilder och trafik. Som framgår av mitt implementeringsprojekt kunde JPEG.webpmini Server spara mer än 6,5 gigabyte utrymme, vilket översattes till cirka 31% i utrymme och CDN-kostnadsbesparingar, vilket är mycket för ett företag av alla storlekar. Till ett pris på 199 USD per månad är JPEG.webpmini Server inte billigt för ett litet företag, men för ett växande företag med ett stort värdavtryck där en enda serverinstans kan kosta mer än det varje månad, kan produkten vara värt en seriös titt . Om du är en del av ett värdföretag, om du äger en webbplats laddad med många bilder som PL, eller om dina CDN-kostnader blir upprörande, kanske du vill kontakta folk på JPEG.webpmini och prata med dem om hur de kan hjälpa dig. Till att börja med kan du prova den här sidan, där du kan skriva in din webbplats och se hur mycket du kan förvänta dig att spara i CDN-kostnader.

Om du har några frågor om något av ovanstående är du välkommen att skicka mig en kommentar nedan.