i have tcp/ip datasnap server running service [session based lifecycle] continuously chews memory , never comes starting memory size when there no connections it.
in order eliminate code culprit, have modeled basic tcp/ip datasnap server running vcl [session based lifecycle] serves server method class [tdsservermodule] contains basic mathematical functions using native data types [no objects create or free].
when connect said datasnap server thin client same results. memory usage continuously grows each connection , sporadically grows when executing server side methods client. once connections closed datasnap server never reduces memory usage [even when left running without connections 8 hrs].
any suggestions why occurs or more importantly how curtail it?
i using rad studio xe2 update 4 hotfix 1.
let me quote "must read" article datasnap. xe3 hope code here work xe2 well.
memory consumption
one of issues observed related memory consumption. why datasnap server consumes memory if method called absolutely nothing?
maybe don’t know how explain try. datasnap creates session each http connection receives. session destroyed after 20 minutes, in other words, on first 20 minutes of test memory consumption go up, after has tendency of stabilize itself. have no idea why datasnap this. in rest application don’t see sense in these sessions default configuration. of course, sessions can helpful, can’t understand why it’s default configuration. indeed, datasnap doesn’t have configuration that. appears have use session control, without being able choose otherwise (there no documentation). mormot framework has session control it’s configurable , doesn’t consumes memory.
anyway, there way around problem. daniele teti wrote article on blog, take look. solution show here placed him on blog. daniele.
uses system.strutils, datasnap.dssession, data.dbxplatform; function tservermethods1.helloworld: string; begin result := 'hello world'; getinvocationmetadata.closesession := true; end; after running method session close , memory consumption lower. of course still exists overhead creating , destroying session.
so seems best course ending every server method explicit memory cleanup, if possible in xe2. you'd better read thosee articles again , prepare future scalability challenges.
Comments
Post a Comment