webForumDet fria alternativet

mtom - out of memory

.NET

9 svar · 764 visningar · startad av lucgo446

Medlem sedan aug. 2002221 inlägg
Frågan#1

Hej!

We have succesfully made an java applet that sends an mtom with a file to the server (asp.net 2.0), but the server aspnet_wp process is going up to 500mb and going out of memory.... any clue?

Thanx

Ni kan svara på svenska ;)

Medlem sedan aug. 2002221 inlägg
#2

Förtydling: den kastar felet out of memory när jag i ws anropar System.Drawing.Image.FromFile(String filename) för att kolla höjd och bredd bla.

Medlem sedan aug. 2002221 inlägg
#3

Nedan kan ha löst det!

skriv gärna in om det löste ert Out of memory problem oxå

	</system.web>
                     <caching>
			<cache disableMemoryCollection = "true"
			  disableExpiration = "false"
			  privateBytesLimit = "0"
			  percentagePhysicalMemoryUsedLimit = "90"
			  privateBytesPollTime = "00:02:00"/>
		</caching>
	</system.web>
Medlem sedan maj 2003352 inlägg
#4

Tar upp tråden på nytt!

Jag trodde att detta löste mitt problem, då jag sitter med samma fel... Men icke!

Efter att jag lagt till denna kod i min web.config så fungerade det plötsligt att ladda upp 4 bilder samtidigt á 3 mb, vilket inte fungerade tidigare. Dagen efter samma tid fungerade det inte ens att ladda upp 1 bild på 3 MB. I morse kl 8 fungerade det att ladda upp 4 bilder á 3 MB.

Verkar som denna kod bara gav mig lite "extra", utan att lösa hela problemet.

Mitt projekt ligger hos Loopia och allt fungerar alltså bra då trafiken på deras server är minimal. Men så fort det är trafik (där min app pool säkerligen delas mellan ett antal andra kunder), så kastar den "Out of memory"-fel på bilder över 1-2 MB. Hjälper det att byta server, inom rimliga kostnader såklart, eller är det ett generellt problem att hantera (komprimera) stora bilder (3-4 MB) på en webbserver? Ska man tvingas till att använda ActiveX för att komprimera bilderna lokalt innan man skickar upp dom?
Någon mer måste vara insatt i detta ständiga problem!?

Medlem sedan aug. 2002221 inlägg
#5

Hej!

vet inte vad vi gjorde men vi har inte haft problemet nåt mer. det vi har lagt in i webconfig ser ni nedan.

sen har vi installerat självklart microsoft.web.services3, men utan det funkar ju inte mtom...


  <system.web>
    <!-- För filuppladdningen, 100 MB -->
    <httpRuntime maxRequestLength="102400"/>

<microsoft.web.services3>
		<messaging>
			<mtom serverMode="optional" clientMode="On"/>
			<!-- Anger maxstorleken på filer som skickas via soap. -1 innebär ingen begränsning -->
			<maxMessageLength value="-1" />
		</messaging>
		<diagnostics>
			<trace enabled="false" input="InputTrace.xml" output="OutputTrace.xml"/>
		</diagnostics>
		<tokenIssuer>
			<statefulSecurityContextToken enabled="true"/>
		</tokenIssuer>
	</microsoft.web.services3>
Medlem sedan maj 2003352 inlägg
#6

Hm. OK.

Vad är MTOM?

Medlem sedan maj 20012 812 inlägg
#7

MTOM = SOAP Message Transmission Optimization Mechanism

http://www.w3.org/TR/soap12-mtom/

- M

Medlem sedan maj 2003352 inlägg
#8

Ok

Vilka användningsområden har MTOM?
Fungerar det i webbapplikationer?

Medlem sedan dec. 19996 522 inlägg
#9

Ja om du använder webservices

Det är en metod för skicka binärdata till och från en ws. med hjälp av XOP (xml-binary optimized packaging)

Medlem sedan maj 2003352 inlägg
#10

Ok, skulle det hjälpa mig i mitt fall? Dvs, att jag kan hantera bilder jag laddar upp på servern bit för bit istället för att läsa in hela bilden i serverns minne, vilket kraschar för mig... Att byta från webbhotell till dedikerad server lär ju hjälpa just nu, men vid hård trafik och många filuppladdningar samtidigt kanske jag återkommer till detta problem framöver?

Kan man arbeta med Threads och allokera mindre minne åt gången per uppladdning och istället låta processen ta längre tid istället för att få minneskrascher?

Uppskattar verkligen all hjälp då jag verkligen sitter fast!

262 ms totalt · 4 externa anrop · v20260731065814-full.6fe65c25
124 ms — deklarationer (db)
0 ms — hämta statistik (cache)
133 ms — hämta tråd, inlägg och bilagor (db)
126 ms — ändringar (db)