Ni estis laboranta en uzanta akcepta elprovado (UAT) Medio kiu, Kiel komparita al evoluado, Estas senvive malrapida.
Ĝi estas komplika medio uzanta FBA, SQL 2008, SSRS kaj plilongigitaj araneaĵaj aplikoj alirebla super la interreto uzanta https, Do ĝi estas estita malfacile spuri malsupren la aferon.
Por antaŭa kliento, Ni uzis FBA kun LDAPa rola provizanto (Kaj membriĝa provizanto). Unu el miaj kolegoj, Ege pli lerta ol I, Determinita ke la "ekstere de la skatolo" LDAPa rolo provizanto, Kiam uzita en tiu medio, Ne estis grimpanta puton. Solvi ĉi tiun problemon por tiu kliento, Li efektivigis belan caching plano en laŭmenda rola provizanto.
Ĉi tiu situacio ŝajnis simila, Do ni rigardis en reproduktanta ke solvo al la hodiaŭa kliento. Kiel mi estis elpuriganta tion, Mi rimarkis ke ĉi tiu mesaĝo ofte aperus en la Sistema ŝtipo (De Eventa Spektanto):
Laborista procezo kun proceza identigaĵo de ‘XXX’ Servanta aplikan naĝejon ‘Hejmo – 80’ Petis recikli ĉar ĝi atingis ĝian virtualan memoran limon.
Mi prenis tion ĉi signifi ke la app naĝejo estis reciklanta ege, Ege tro ofte kaj ke klarigus elfaran problemon.
Mi rigardis la nemoveblaĵojn de la app naĝejo kaj ĝia "Reciklado" Paĝo montris ke la nemoveblaĵo "Maksimuma virtuala memoro (En megabajtoj)" Estis fiksita al vera kaj estis fiksita al 5000. Kiu ŝajnas kiel sufiĉa, Sed mi decidis al unset la valoro kaj ke havis tujan pozitivan efikon. Ne pli da app naĝeja reciklado. Ne pli da mistera malrapida-faligas kaj paŭzoj.
Mi ne vere komprenas la fundamentan "aĵon" Tio estas daŭriganta tie, Sed klare iu speco de afera/efiko afero estas okazanta kaj nuntempe, La UATa medio estas uzebla.
</Fino>
Phil Wicklund