JPEG.webpmini Server recensie

Nadat ik de kans had gehad om de JPEG.webpmini Pro-software te testen en te beoordelen, realiseerde ik me hoe krachtig deze software is, niet alleen voor het exporteren van afbeeldingen en als onderdeel van een Lightroom-workflow, maar ook voor vele andere toepassingen, waaronder het optimaliseren van afbeeldingen die al op onze software staan. grote opslagapparaten. Een ander gebruik waar ik meteen aan dacht, was de webserver waar het Photography-Secret.com-verkeer vandaan komt. Gezien hoeveel verkeer Photography-Secret.com dagelijks wereldwijd bedient en het feit dat afbeeldingen alleen al goed zijn voor ongeveer 5 terabyte aan verkeer per maand, was de gedachte om JPEG.webp-afbeeldingen te kunnen comprimeren met de JPEG.webpmini-engine iets die ik echt vroeg dan laat wilde implementeren. Dus begon ik aan een nieuw project - om op de lange termijn zowel verkeer als geld te besparen voor PL, met behulp van de JPEG.webpmini-server.

Fotografen Pas op: dit is een zeer technische recensie van software die niets met fotografie te maken heeft. Ik besloot de recensie bij PL te publiceren, omdat ik denk dat andere websites met veel fotografie enorm zouden kunnen profiteren van de implementatie van de JPEG.webpmini-server.

1) Overzicht serveromgeving

Voordat ik inga op de recensie, wil ik wijzen op een paar mogelijk belangrijke stukjes informatie over mijn webserverconfiguratie. Allereerst draai ik CentOS Linux op elke server (en er zijn er een paar). Op de twee back-endwebservers die PHP-oproepen van de load-balancer afhandelen, heb ik de JPEG.webpmini-server geïnstalleerd, hoewel alleen de eerste echt van belang is, aangezien deze alle uploads naar de site afhandelt (WordPress kan dit niet rechtstreeks afhandelen, dus het is alleen mogelijk om te kijken naar wp-admin-oproepen en deze naar de juiste server te leiden via nginx / apache). Helaas is er geen gemakkelijke manier om meer dan één WordPress-server te draaien zonder gedoe met het uploaden van bestanden, aangezien het niet is ontworpen om te worden gebruikt in een clusteromgeving (alles verplaatsen naar AWS met EC2-actieve serverinstances, RDS met DB en S3 voor het afhandelen van de bestanden zou een goede oplossing zijn, maar nadat ik het had uitgeprobeerd, was het op geen enkele manier een goedkope oplossing, vooral niet als je een paar EC2-servers begint te spawnen die de back-end-belasting aankunnen). Daarom heb ik alle uploads gesynchroniseerd via rsync. Geen elegante oplossing, maar het werkt redelijk goed. Ik heb rsync bewaking van de "wp-content" -map, dus alle wijzigingen worden in één richting gerepliceerd (in feite, zodra afbeeldingen zijn geüpload naar server01, worden ze automatisch opgepikt door server02). Het duurt een paar seconden om te synchroniseren, maar als het eenmaal gebeurt, worden de afbeeldingen gemakkelijk weergegeven om balancerverzoeken te laden.

Alle webserver-oproepen worden afgehandeld door een load-balancer, die alleen https-webverkeer bedient. Alle afbeeldingen worden afgehandeld door een externe CDN. De belangrijkste reden voor de implementatie van JPEG.webpmini was het verlagen van de CDN-kosten, die alleen maar stijgen elke maand naarmate we meer inhoud publiceren.

Houd er rekening mee dat uw webserver een versie van Linux moet draaien - JPEG.webpmini-server draait niet op Windows-servers. Hier is de lijst met ondersteunde serverplatforms.

2) Installatie van JPEG.webpmini-server

De installatie van de JPEG.webpmini-server is erg eenvoudig, vooral als u RHEL, CentOS en andere populaire Linux-distributies gebruikt. Voor mijn CentOS-server leverde JPEG.webpmini een RPM-bestand, dus het was een gemakkelijke installatie met een enkele opdracht. Nadat het binaire bestand was geïnstalleerd (standaard / usr / bin / jpeg.webpmini), was de volgende stap het kopiëren van het .jpeg.webpmini.cfg-licentiebestand naar de homedirectory van de gebruiker. Van daaruit zou het uitvoeren van "jpeg.webpmini" iets als het volgende moeten opleveren:

===============================
Start jpeg.webpmini 3.14.2.84235
===============================
-f optie is vereist: -f =
Gebruik -help voor hulp

===============================
Voltooi jpeg.webpmini 3.14.2.84235
===============================

Mijn eerste tests begonnen met de JPEG.webpmini-server versie 3.13, maar na een paar aangevraagde wijzigingen in het uitvoerbare bestand, leverde JPEG.webpmini een bijgewerkt 3.14 RPM-bestand. De belangrijkste toevoeging aan de 3.14-versie is de mogelijkheid om reeds geoptimaliseerde bestanden over te slaan, wat een groot probleem voor mij was, aangezien ik de desktopversie van de software gebruik en ik niet wilde dat de JPEG.webpmini-server geüploade JPEG.webp-afbeeldingen opnieuw optimaliseerde.

3) Afhandeling van WordPress-afbeeldingsbestanden

Wanneer een afbeelding wordt geüpload naar WordPress, gebruiken de admin-scripts GD of ImageMagick om die afbeeldingen te verwerken. Standaard maakt WordPress afbeeldingen van drie formaten, naast de geüploade afbeelding (miniatuur, middelgroot en groot formaat), maar afhankelijk van hoeveel add_image_size aanroepen er kunnen worden toegevoegd door het thema en plug-ins, kunnen er nog veel meer zijn! Hierdoor kan het uploaden van een enkele afbeelding een aantal bestanden op de server voortbrengen, waardoor de map Uploads erg snel groeit. En die kleinere afbeeldingen worden gemaakt door GD of ImageMagick, dus de bestanden worden standaard ontdaan van zowel ICC-kleurprofielen als EXIF-gegevens, wat niet wenselijk is op een fotografiewebsite. Ze zullen ook niet goed worden geoptimaliseerd voor grootte, aangezien noch GD noch ImageMagick een slim algoritme zoals JPEG.webpmini hebben om JPEG.webp-afbeeldingen correct te kunnen comprimeren. In feite doet WordPress behoorlijk vreselijk werk met het wijzigen van het formaat van afbeeldingen, wat vaak resulteert in slecht gekleurde (vanwege het strippen van ICC-profielen), zachte en modderige afbeeldingen (vanwege zware compressie). Om dit probleem bij PL te voorkomen, heb ik ImageMagick alleen gebruikt om afbeeldingen te optimaliseren, met speciale opties. We verwijderen alleen EXIF-gegevens van miniaturen en comprimeren ze iets agressiever voor een snelle browse-ervaring. Eenmaal in een bericht worden noch ICC-profielen, noch EXIF-gegevens verwijderd van grotere afbeeldingen om ze er zo goed mogelijk uit te laten zien. Op deze manier dwingen we onze lezers niet om op een afbeelding te klikken om de "juiste versie" te zien - afbeeldingen zien er consistent uit van previews tot native geüploade formaten.

Om ten volle te profiteren van de JPEG.webpmini-server, is het daarom het beste om het uitvoerbare bestand uit te voeren voor elk formaatwijzingsproces - niet alleen voor de enkele geüploade versie, aangezien u wilt dat elk bestand wordt geoptimaliseerd door de engine, ongeacht of het een miniatuur, een middelgrote of een grote versie van het origineel. Dit betekent in wezen dat JPEG.webpmini elke oproep naar image_resize zou moeten onderscheppen.

4) JPEG.webpmini-server en WordPress-integratie

Helaas biedt JPEG.webpmini geen plug-in die automatisch in WordPress wordt geïntegreerd om dat te doen, dus ik moest zelf een oplossing bedenken. Ik begon met de codebase van de ImageMagick Engine-plug-in (een behoorlijk verouderde plug-in, maar het werkt nog steeds), en voegde vervolgens aanroepen toe aan het uitvoerbare bestand JPEG.webpmini in de functie ime_im_cli_resize (ik voer een opdrachtregelversie van ImageMagick uit in plaats van een PHP-module). Als deze gewijzigde versie van de plug-in iets is dat je interesseert, laat het me dan weten in de comments hieronder en ik zal je het plug-in-bestand sturen. Ik weet niet zeker of mensen bij JPEG.webpmini van plan zijn een WordPress-plug-in uit te brengen, maar ik zou graag wat code bijdragen voor een goed doel.

De code werkt en is getest met JPEG.webpmini 3.14. Zodra elke versie met aangepaste grootte is gemaakt, optimaliseert de code eerst die afbeeldingen en vervolgens wordt de originele JPEG.webp-afbeelding geoptimaliseerd en overschreven.

5) Testresultaten JPEG.webpmini-server

Er is tot nu toe veel technische mumbo jumbo geweest, dus laten we naar het vlees gaan. Hoeveel schijfruimte heb ik kunnen redden en hoeveel heb ik op CDN-kosten bespaard? Om het uitvoerbare bestand JPEG.webpmini recursief op elke map uit te voeren, moest ik een script aanvragen bij de technici van JPEG.webpmini, die ze zeer snel leverden. Het verstrekte bestand was een Python-script genaamd "jpeg.webpmini_recursive.py", waarvoor slechts twee opdrachten nodig waren: een om de bronmap in te voeren en een om de doelmap in te voeren (ik heb het script een beetje aangepast nadat ik de nieuwe RPM-versie had die automatisch kan overslaan reeds geoptimaliseerde JPEG.webp-afbeeldingen). Nadat ik een back-up van alles had gemaakt, heb ik een map gemaakt met de naam "uploads_jpeg.webpmini" en dat is wat ik als doelmap heb gebruikt. Ik heb het script uitgevoerd en het duurde even om elk bestand te doorlopen. Ik kwam na een paar uur terug en het script was klaar met uitvoeren.

Omdat JPEG.webpmini alleen JPEG.webp-afbeeldingen optimaliseert en PNG, GIF of andere bestandsuploads zoals video niet aanraakt, moest ik ervoor zorgen dat de resulterende map terug naar mijn uploadmap werd gekopieerd. Nogmaals, zorg ervoor dat u een volledige back-up van alles maakt voordat u deze stap zet, aangezien deze onomkeerbaar is. Voordat ik dat deed, veranderde ik recursief de permissies op de uploads_jpeg.webpmini map door "chown -R niemand: niemand / uploads_jpeg.webpmini" uit te voeren. De volgende opdracht was "/ bin / cp -Rpf uploads_jpeg.webpmini / * uploads /", die bestaande afbeeldingsbestanden overschreef met hun voor JPEG.webpmini geoptimaliseerde versies.

Laten we eens kijken naar het voor en na. Hier is hoe mijn mappen eruit zagen voordat ik alle inhoud kopieerde:

 
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 Totale grootte: 20.945.855

Ongeveer 21 gigabyte aan afbeeldingen. Laten we nu eens kijken hoe de map eruit zag nadat alle afbeeldingen waren geoptimaliseerd door 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 Totale grootte: 14.375.944

Ho, dat is nu maar 14,4 gigabyte! Alleen al op de harde schijf kon ik meer dan 6,5 gig aan ruimte terugwinnen, wat zich vertaalt naar ongeveer 31% aan ruimtebesparing. Dat is eigenlijk een derde van mijn CDN-rekening, wat een groot aantal is. En houd er rekening mee dat de afgelopen twee + jaar niet zoveel ruimtebesparing hebben opgeleverd als eerder, aangezien ik al begon met het optimaliseren van mijn afbeeldingen op mijn desktop met JPEG.webpmini Pro voordat ik ze uploadde, dus de getallen die je ziet zijn uploads door andere teamleden die geen gebruik maken van JPEG.webpmini.

Hier is een voorbeeld van een samenvattend rapport van JPEG.webpmini voor juni 2012:

----------------------------------
INFO: Samenvattend rapport voor map Photographylife.com/wp-content/uploads/2012/06 (inclusief submappen):
INFO: Totaal aantal bestanden: 372
INFO: Totale grootte van invoerbestanden: 42900 KB
INFO: Totale grootte van uitvoerbestanden: 28480 KB
INFO: Recompressieverhouding: 1,51X (34% besparing)
INFO: ----------------------------------

Verschillende mappen leverden verschillende cijfers op, maar gemiddeld was het tussen de 30-35%, wat veel is, aangezien ons team behoorlijk goed geïnformeerd is over het klein houden van bestandsgroottes tijdens het exportproces (we houden onze exportinstellingen meestal op niveau 10 in Photoshop , wat overeenkomt met Lightroom's 77-84% "Kwaliteit", volgens ons artikel over JPEG.webp-compressieniveaus in Photoshop en Lightroom).

5) JPEG.webpmini-serverkwaliteit en metagegevensinstellingen

Voor sites die niet per se JPEG.webp-afbeeldingen van hoge kwaliteit met hun metadata willen behouden, kan JPEG.webpmini afbeeldingen veel agressiever optimaliseren. Ik wilde niet dat JPEG.webp-afbeeldingen er slechter uitzien dan oorspronkelijk geüpload, dus heb ik de standaardinstelling "qual = 0" behouden, waardoor de beste kwaliteit behouden blijft. Andere sites kunnen ervoor kiezen om met hoge of gemiddelde kwaliteit te werken, waardoor de footprint van JPEG.webp-bestanden veel agressiever wordt verkleind. Je kunt ook alle metadata volledig verwijderen met de opdracht "rmt = 1" en alsof dat nog niet genoeg is, is er zelfs een optie om progressieve JPEG.webp-uitvoer op elke afbeelding te forceren. Ik ben er zeker van dat sociale mediasites zoals Facebook dergelijke tools veel gebruiken, aangezien afbeeldingen en video's een groot deel van hun hostingrekeningen uitmaken. Bezoek deze pagina voor een lijst met opdrachten die beschikbaar zijn met de JPEG.webpmini-server.

6. Conclusie

Hoewel het JPEG.webpmini Server-product zeker niet op fotografen is gericht, is de software een zeer veelzijdige tool voor degenen die grote websites met veel afbeeldingen en verkeer hebben. Zoals blijkt uit mijn implementatieproject, kon JPEG.webpmini Server meer dan 6,5 gigabyte aan ruimte besparen, wat zich vertaalt naar ongeveer 31% aan ruimte en CDN-kostenbesparingen, wat veel is voor een bedrijf van elke omvang. Met een startprijs van $ 199 per maand is JPEG.webpmini Server niet goedkoop voor een klein bedrijf, maar voor een groeiend bedrijf met een grote hostingvoetafdruk waar een enkele server-instantie elke maand meer kost dan dat, is het product misschien de moeite waard om eens serieus te bekijken . Als u deel uitmaakt van een hostingbedrijf, als u een website heeft met veel afbeeldingen zoals PL, of als uw CDN-kosten schandalig worden, wilt u misschien contact opnemen met de mensen van JPEG.webpmini en met hen praten over hoe ze dat kunnen doen. je helpen. Om te beginnen kunt u deze pagina uitproberen, waar u uw website kunt invoeren en kunt zien hoeveel u kunt verwachten te besparen op CDN-kosten.

Als je vragen hebt over het bovenstaande, kun je hieronder een reactie achterlaten.