CODEWITHSUNDEEP
multithreadingperformancearchitectureconcurrency
manash
manash

Reputation: 7106

Architecture and performance issue

I have an question about architecture/performance. I'm talking about a SIP server that processes multiples client requests concurrently. I suppose that each request is treated in a dedicated thread. At the end of the process, the concerned thread log request specific infos in a file. I want to optimize the last part of processing. I mean I want to know what alternatives you propose instead of logging these infos in a file. Why? Because writing in a file after processing uses resources that I would use to process other arriving requests.

First, what do you think about the question? And, if you think that it's a "true" question (I mean that an alternative may optimize the performances), what do you propose?

I thought about logging the data into a queue and to use another process IN ANOTHER MACHINE that would read from the queue and write to a file.

Thanks for your suggestions

Upvotes: 0

Views: 93

Answers (2)

Martin James
Martin James

Reputation: 24847

I suspect that network overhead involved in moving the logging to another machine is problably going to create more problems than it solves. I would go with @Nicholas' solution - queue off the logs to one thread on the same machine. The queue allows slack so that occasional disk latency is mitigated and the logging thread can make its own optimizations, eg. waiting until it has a cluster-size of logs before writing. Other stuff, like opening a new log file every day or whenever the log-file reaches a limiting size are also much easier without affecting the performance of the main server.

Even if you log on another machine, you should still queue off the logging to mitigate network latency.

If the log objects on the queue contain, say, a 'request' enumeration, (eg. ElogWrite, ElogNewFile, ElogPath, ElogShutdown), you could try both - you could queue up a request for the log thread to close its current log file and open a path to a file on a networked machine at runtime - the queue buffer would absorb the delay of doing this.

Upvotes: 0

Nick Butler
Nick Butler

Reputation: 24383

If it is NOT a requirement that the log is written before the request returns - i.e. the logging is not part of the atomic response - then you have the option of returning the response and just initiating the logging action.

Putting the logging data in a queue in memory seems reasonable. You can read that queue and write to disk either on the same machine or another. I would start with a thread in your app as this is easiest to implement and since the disk I/O is going to be the limiting factor, it shouldn't impact your server much.

If the log is required to be written BEFORE the response is returned, you still have the option of using a reliable queue like MSMQ.

Upvotes: 1

Related Questions