ugrás a tartalomhoz

IIS Express vs IIS

DarkHcK · 2018. Ápr. 27. (P), 07.41
Sziasztok!

Nemrégiben fejeztem be egy ASP.NET C# alkalmazás fejlesztését. Fejlesztő eszközként a VS2017 Community -t használtam, s mindig onnan indítottam az alkalmazást tesztelés céljából. Ilyenkor egy IIS Express indult el és az indítást követően az oldalak olyan 2-3 mp alatt töltődtek be.

Ami a nagy problémám, hogy ezt most felraktam egy IIS -re. Itt az indítást követően az oldalak betöltése kb 9-15 mp.

Persze ha már egyszer végig kattogtatja az ember, akkor utána cache -ből az oldal betöltés 800-900 ms.

Már engedélyeztem a prod szerveren az "Az előzetes betöltés engedélyezése" opciót, de egyéb gyorsításra szolgáló opciót nem találtam.

Esetleg tudna valaki valami tanáccsal szolgálni, hogy mit lehetne még konfigurálni a prod szerveren, hogy ne legyen ennyire lomha?

Az prod szerver egy HypreV -ben futtatott Windows Server 2012 R2 + IIS 8.5
A HyperV kikerülhetetlen.

Próbáltam külön fizikai szerveren, ami nem HyperV -ben fut, de a hatás ugyan az :(

Előre is köszönöm a tanácsokat.

Üdv,
DarkHcK
 
1

hyper-v / erőforrások

Pepita · 2018. Ápr. 27. (P), 16.16
Magához az IIS-hez én nem tudok hozzászólni, Hyper-v alatt érdemes checkolni, hogy emnnyi és milyen erőforráshoz fér hozzá.

- van-e annyi CPU a rendelkezésére, mint neked?
- fizikai RAM mérete (konkrétan mennyi van a virtgépnek)
- SSD vs HDD, ráadásul ugye a virtgép meghajtóját (fizikait) másik oprendszer / szolgáltatás is használhatja, ilyenkor ugye lényegesen lassabb egy - egy I/O, mert "többen állnak sorba".
2

Rossz

Hidvégi Gábor · 2018. Ápr. 27. (P), 22.40
Amit írsz, az alapján nekem úgy tűnik, valamit nagyon elrontottatok.

Összehasonlításképp: az általunk fejlesztett rendszerben egy nyolcszáz elemből álló űrlap megjelenítése adatokkal együtt nagyjából négyszáz ezredmásodperc egy 2015-ös Atom processzoros gépen, ez egy HD felbontású képernyőt teljesen kitölt. Ebből az adatok összeállítása és elküldése a kliensnek a teljes időnek nagyjából a harmadát teszi ki. A háttérrendszert PHP-ban készítettük, és egy nagyjából tizenöt éves Xeon processzoros szerveren fut.

Ha ti duplaennyi adattal dolgoztok oldalanként, akkor az értékeitek elfogadhatóak. Ha nem, akkor lásd az első mondatomat.

Amit én tennék a helyedben, az az, hogy megnézném, mi tart ennyi ideig, azaz logikai részekre bontanám a programot, és lemérném, hogy az egyes egységek meddig futnak. Ami lassú, ott kell optimalizálni. Nem javasolnám a hardver bővítését/tuningolását/konfigurálását, mert azzal csak elodázod a probléma megoldását.
3

Optimalizáció

Pepita · 2018. Ápr. 29. (V), 09.19
Erre akkor lenne szükség, ha az lenne a problémája (önmagában), hogy "az oldalak olyan 2-3 mp alatt töltődtek be".
De DarkHcK ezt nem problémaként, hanem kiindulási adatként írta. A problémája ott van, hogy egy másik (éles) szerveren, nem pontosan ugyanolyan környezetben ez az idő 9-15 mp-re nőtt.
Mivel a forráskód ugyanaz, a 6-13 mp-es különbség okát keresi, nem a 2-3 mp-ét.

Egy .net backendet űrlapelemek száma alapján összehasonlítani egy php backenddel - ne haragudj, de enyhén szólva furcsa (vagy inkább szakmaiatlan), főleg azért, mert azt sem tudjuk, hogy neki az "oldalak" tartalmaznak-e egyáltalán űrlapot.
Szerintem már minden weblabor látogató tisztában van vele, hogy a Ti szoftveretek még commodore 16 - on is csodálatosan hasít, de ez nem jelenti azt, hogy minden problémára megoldás lenne. ;)
4

Debug vagy Release módban

smokey · 2018. Május. 3. (Cs), 11.02
Debug vagy Release módban ment ki a build?