Asiakasta voi hyvinkin kiinnostaa kokeilla, minkälaisia käyttäjämääriä julkaisusovellus kestää ja tällainen ns. kuormitustestaus on hyväksyttävää, kunhan se ei jatku tuntikausia. Minuuttikin joidenkin teoksen kirjoitusten latailua automatisoidusti esim. jollain verkossa käytettävissä olevalla kuormitustestaus-sovelluksella riittää hyvän tuntuman saamiseen. Yhden palvelimen systeemissä pitäisi yhtä kirjoitusta pystyä latailemaan perusresursseilla esim. 8000 krt minuutissa vasteajalla 70 ms tjs. Ottaen huomioon, että esim. useimmat internetin blogikirjoitukset saavat vaikkapa vain muutama sataa lukukertaa kuukaudessa, pitäisi perusresurssien riittää "ihan hyvin" moniin tarkoituksiin. Julkisten teosten kuvat latautuvat aina CDN-palvelun kautta, jos CDN-palveluun on muistettu ladata käyttöaikaa.

Eräs asiakkaan pikaisesti käytettävissä oleva keino vähentää julkaisusovellukseen kohdistuvaa kuormitusta on lisätä teoskohtaisia välimuistitusaikoja, joka on vakiona 5 sekuntia. Tämä välimuistitus tarkoittaa sitä, että esim. yhtä teoksen kirjoitusta ei generoida jokaisella sivulatauksella erikseen, vaan viimeisin generointi tallennetaan palvelimella tiedostoon, jota hyödynnetään esim. seuraavien viiden sekunnin ajan tai sen verran, mitä sen on säädetty olevan. Se voi olla kaksi tuntiakin. Kirjoituksen ja muiden teoksen osien generointi on aina palvelimen prosessoria kohtalaisen paljon kuormittava toimenpide ja ainahan on se mahdollisuus, että sivunlatauspyyntöjä tulee paljon kerralla. Generoidun teoksen osan tiedostosta lukeminen on tähän verrattuna erittäin vähän palvelimen resursseja kuormittavaa.

Palvelinlaitteiden ja ohjelmistojen kuormittumiseen liittyvät säädöt eivät tule täysin hyödynnetyiksi, jos sisääntulevat signaalit ensinnä vastaanottava Linux-palvelin on konfiguroitu outbound-kaistan osalta tiedonsiirtoa runsaasti rajoittavaksi. Tämä tehdään Linuxin tc-käskyllä (sanoista "traffic control") ja syynä sen käytölle voisi olla esim. oletettu uhka sille, että botteja olisi tahallaan ohjelmoitu kuluttamaa kuukausittaisen tiedonsiirron määrää siten, että ne latailevat pitkän ajanjakson aikana erittäin monia kertoja kohtalaisia määriä erilaista sisältöä kuten kuvia ja teosten sivuja. Sitä ei ehkä mielellään maksaisi useita satoja euroja ylimääräistä oletetun esim. kympin sijaan. Käytännössä helpoimmalla pääsee, kun varautuu maksamaan kolme kertaa oletettua enemmän pitämällä kaistaa vain hiukan rajoitettuna ja huomaa toivottavasti toistuvastai, ettei mitään pahaa tapahtunutkaan.

Normaalisti datakeskus-palveluiden tarjoaja Hetzner alkaisi laskuttamaan julkaisusovelluksen palvelimilta ulospäin suuntautuvasta datasta sen jälkeen, kun datan siirtomäärät ylittäisivät 20 TB. Tämä määrä eli 20 000 GB on runsaasti, jos kyse on vähäliikenteisestä julkaisusovelluksen instanssista. Varmuuden vuoksi julkaisusovelluksen palvelimiin tehdään asiakaskohtaisesti sellainen täydentävä rajoitus, mikä estää kuukausittaisten datansiirtomäärien nousemisen yli tuon 20 TB. Tämä tapahtuu rajoittamalla palvelimen virtuaalisen verkkokortin siirtonopeutta tasoon 60 mbps eli 7.5 MB/s (ks. laskelma: https://www.wolframalpha.com/input/?i=60Mbps+in+TB%2Fmo... Määritetyn datansiirtorajan yli menevää osuutta kustannuksista nimitetään englanniksi "overage costs" ja palvelimelta ulospäin suuntautuvasta datasta käytetään joko nimitystä "egress data" tai "outbound data". Siitä voidaan sopia erikseen, josko tämä keinotekoinen rajoite poistettaisiin, mutta se vaatii samalla sopimaan datansiirtokustannuksista maksamisen käytännöistä. Jos datakeskus-palveluiden tarjoajana on jokin muu kuin Hetzner tai 20 TB ei muuten ole overage costs -maksun rajana, siitä mainitaan erikseen ennen palvelusopimuksen tekemistä.

Jos kävijämäärät lisääntyvät yht'äkkiä voi siitä aiheutua vaikeuksia päästä kirjautumaan käyttäjätunnuksella tai tehdä minkäänlaista esim. editoivaa, koska kuormituksen vuoksi kaikki olisi kovin hidasta. Kirjoituksen "Julkaisusovelluksen verkkotopologian muuttaminen" kuvat antanevat muutaman idean vaihtoehdoista verkkotopologian muuttamiseen sellaiseksi, että saavutettaisiin paremmin ulkoista kuormitusta. Muina palvelunlaatua parantavina keinoina ovat yksinkertaisesti vCPU:n lisääminen virtuaalipalvelimien tapauksessa (lisää prosessin käyttöaikaa yhteiskäytössä olevalle palvelinlaitteen prosessorille) ja vaihtaminen dedikoitujen palvelimien käyttöön. Näistä hiukan lisätietoja ohjeiston kirjoituksessa "Julkaisupalvelua käyttämään".