Concurrency issue

(Benjamin Keffer) #1

After benchmarking my interface application (built with http api) I encountered the problem with concurrency. A single call will be answered in about 100 ms and has a size of 5 kb. If a second consumer requests the Service at the same time the response time will be more than tripled (between 300-500 ms). The returned data is buffered in memory why there isn’t any other access to a database etc.

Do you have any serialized procedures inside the return mechanism that could be
optimized? ATM I can’t provide a stable performant service.

(EvgenyK) #2


Can you specify your platform (Delphi or .NET)?

(Benjamin Keffer) #3

I’m using Delphi (10.2.2). The service is running on Windows Server 2019 with 8 GB RAM and 8 CPUs

(EvgenyK) #4


By default, each client’s request is processed in new service instance.

You can change default class factory (TROClassFactory) with TROPooledClassFactory or TROSingletonClassFactory.

see the Class Factories for more details about class factories.

we don’t cache client’s requests, but if you want, you can implement some cache on server-side.

(Benjamin Keffer) #5

I therefore think that both requests have to be answered within the same time. Unfortunately it’s not the case… Although I cache the data on server-side.

The service method looks like below:

function TTicketService.GetTariffs: TTariffs;
  Result:= TTariffs(FTariffs.Clone);

(EvgenyK) #6


what is FTariffs? private variable inside service ? it wasn’t work as cache with default class factory.
you cache implementation may work only if FTariffs is global variable

(Benjamin Keffer) #7

Sorry, missunderstanding.With caching I meant the data is already available and stored as FTariffs which is a private variable. Thus each client has it’s own thread, every response should have the same time regardless how many calls run simultaneous.

(Benjamin Keffer) #9

Sorry, your tool works perfectly! I have some network issues… :man_facepalming: