When serializing large response, client receives ServiceStack exception, Out of Memory, - serialization

I have a ServiceStack RESTful web service on a linux box with apache/mod_mono.
public DataSetResponse Get(DataRequest req)
{
DataSetResponse Response = new DataSetResponse();
DataSet BigData = new DataSet();
this.Status = this.DataFetcher(ref BigData);
Response.Data = BigData;
Response.Status = this.Status;
System.Threading.Thread.Sleep(30000);
return Response;
}
When the thread sleeps I can see that mono is at 8% of the memory as reported by top. 30+ seconds later when the mono has cpu activity again the memory ramps up to 90% and an Out of Memory Exception is thrown. Mono continues to run but does not release its memory.
On small data sets (1/10 of the size) it seems to work fine and mono has 1% of memory. I think the memory growth occurs as the data object is serialized to Json, before it is streamed to the client.
Is this correct? And more important, how can I solve this?

I don't know how much RAM your server has but if it's maxing out on a single request, and I'm presuming that since it's a web service you expect to serve to multiple clients so you could be getting 2 or more of these requests at around the same time, you may want to consider some way to stream or chunk up the data (ie, the client can request a page of data at a time, and they can keep asking for more pages until they have the entire data set).
So your request DTO might include a page #, your data fetcher would would grab that next page (based upon whatever you decide to be the number of records per page), and return it.
Your response would need to include total # of pages, and page returned so the client could decide to keep fetching data.
The reason you probably see 8% prior to serialization is that the object is in its binary format - converting it to a big, JSON string is going to really balloon it out.
You could also consider some of the other binary formats ServiceStack supports - ProtoBuf and MessagePack.

Related

Recovering from OOM on DirectByteBuffer allocation on a WebFlux Web Server

I'm not sure if this makes sense so please comment if I need to provide more info:
My webserver is used to upload files (receives files as Multipart/form-data and uploads them to another service). Using WebFlux, the controller defines the argument as a #RequestPart(name = "payload") final Part payload which wraps the header and Flux.
Reactor / Netty uses DirectByteBuffers to accomodate the payload. If the request handler cannot get enough direct memory to handle the request, it's gonna fail on an OOM and return 500. So this is normal / expected.
However, what's supposed to happen after?
I'm running load tests by sending multiple requests at the same time (either lots of requests with small files or less requests with bigger files). Once I get the first 500 due to an OOM, the system becomes unstable. Some requests will go through, and other fails with OOM (even requests with very small payload can fail).
This behaviour leds me to believe the allocated Pooled buffers are not shared between IO Channels? However this seems weird, it makes the system very easy to DDOS?
From the tests I did, I get the same behaviour using unpooled databuffers, although for a different reason. I do see the memory being unallocated when doing jcmd <PID> VM.native_memory but they aren't released to the OS according to metrics & htop. For instance, the reserved memory shown by jcmd goes back down but htop still reports the previous-high amount and it eventually OOM.
So Question :
Is that totally expected or am I missing a config value somewhere?
Setup :
Spring-boot 2.5.5 on openjdk11:jdk-11.0.10_9
Netty config :
-Dio.netty.allocator.type=pooled -Dio.netty.leakDetectionLevel=paranoid -Djdk.nio.maxCachedBufferSize=262144 -XX:MaxDirectMemorySize=1g -Dio.netty.maxDirectMemory=0

Determine the memory usage in actual server through its header response size

I have a log traces file from a server, there is a field header response size for a requests lets say 4585 etc, is there any relationship between the response size and the actual memory size in the server to generate this response?? I need to know the real size of a request when it processes it in the server, and after finish process, it generates response size, any idea or calculation method will be highly appreciated, thanks
There is no way to determine memory usage on the server from the response size.
The (hypothetical) way to determine memory usage for a request would be to directly measure it in the server's request handling code. But even that is difficult because it would be difficult the memory used by each request from other things. It would only be feasible if your server processed (strictly) one request at a time.

Cancelling WCF calls with large data?

I'm about to implement a FileService using WCF. It should be able to upload files by providing the filecontent itself and the filename. The current ServiceContract looks like the following
[ServiceContract]
public interface IFileService
{
[OperationContract]
[FaultContract(typeof(FaultException))]
byte[] LoadFile(string relativeFileNamePath);
[OperationContract]
[FaultContract(typeof(FaultException))]
void SaveFile(byte[] content, string relativeFileNamePath);
}
It works fine at the moment, but i want to be able to reduce the network payload of my application using this Fileservice. I need to provide many files as soon as the user openes a specific section of my application, but i might be able to cancel some of them as soon as the user navigates further through the application. As many of mine files are somewhere between 50 and 300 MB, it takes quite a few seconds to transfer the files (the application might run on very slow networks, it might take up a minute).
To clarify and to outline the difference to all those other WCF questions: The specific problem is that providing the data between client <-> server is the bottleneck, not the performance of the service itself. Is changing the interface to a streamed WCF service reasonable?
It is a good practice to use a stream if the file size is above a certain amount. At my work on the enterprise application we are writing, if it is bigger than 16kb then we stream it. If it is less than that, we buffer. Our file service is specially designed to handle this logic.
When you have the transfer mode of your service set to buffer, it will buffer on the client as well as on the service when you are transmitting your data. This means if you are sending a 300mb file, it will buffer all 300mb during the call on both ends before the call is complete. This will definitely create bottlenecks. For performance reasons, this should only be when you have small files that buffer quickly. Otherwise, a stream is the best way to go.
If the majority or all of your files are larger files I'd switch to using a stream.

WCF best practises in regards to MaxItemsInObjectGraph

I have run into the exception below a few times in the past and each time I just change the configuration to allow a bigger object graph.
"Maximum number of items that can be serialized or deserialized in an object graph is '65536'. Change the object graph or increase the MaxItemsInObjectGraph quota."
However I was speaking to a colleague and he said that WCF should not be used to send large amounts of data, instead the data should be bite sized.
So what is the general consensus about large amounts of data being returned?
In my experience using synchronous web service operations to transmit large data sets or files leads to many different problems.
Firstly, you have performance related issues - serialization time at the service boundary. Then you have availability issues. Incoming requests can time out waiting for a response, or may be rejected because there is no dispatcher thread to service the request.
It is much better to delegate large data transfer and processing to some offline asynchronous process.
For example, in your situation, you send a request and the service returns a URI to the eventual resource you want. You may have to wait for the resource to become available, but you can code your consumer appropriately.
I haven't got any concrete examples but this article seems to point to WCF being used for large data sets, and I am aware of people using it for images.
Personally, I have always had to increase this property for any real world data.

WCF Service wtih Stream response

I have a WCF service and one of the method returns Stream.
Now the question is while I try to consume that Stream object, am I trying to use the stream over the network or the client had received the full stream on its own side?
Will it make any difference if I would have used RESTful instead of WCF?
The whole point of using the streaming interface in WCF is that the client gets a stream from which it can read blocks of bytes. The whole return object (file, picture, video) will NOT be assembled in full on the server and sent back as once huge chunk, instead, the client can retrieve chunks at a time from the stream returned from the WCF service.
Your client gets back a "Stream" instance, from which it can then read the data, like from a FileStream or a MemoryStream. That way, the amount of memory needed at any given time is reduced to a manageable size (instead of potentially multiple gigabytes in the buffered mode, you'll transfer a large file in e.g. 1 MB chunks or something like that).
Marc