Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Logs and Performance.
I will say first up this is no longer an ongoing issue so I am posting this only out of curiosity.
I came across an issue today onsite where a client complained about response via our WebApp (OECGI4 JSON request to HTTP Framework 4.0.9.7)
The very first thing we do in our WebApp is a call to the Framework's version endpoint (unauthenticated) and display it on the login page so that we know we are communicating with the data engine (shout out to Jared for that).
Unfortunately, the client started to complain it was taking 'ages' before they were able to login. We could see that version was taking a very long time to return.
On a side night, this server is running 2 other systems with OEngine Services for APIs configured the same (obviously different ports), both which behaved normally.
To cut a long diagnostic story short, it turns out that someone, once upon a time, had turned on debugging and forgot to turn it off when they were done. This resulted in MILLIONS of log files and many GB of data. The moment we disabled logging for thet environment we saw immediate performance response. We obviously then cleaned up the actual logs as well.
I would have thought the Framework would only need to check for the folder's existence and would need to parse the whole log directory (which windows did horrendously badly). My question is what, in the process of writing out the log files, might be stumbling over mass amounts of data?
I came across an issue today onsite where a client complained about response via our WebApp (OECGI4 JSON request to HTTP Framework 4.0.9.7)
The very first thing we do in our WebApp is a call to the Framework's version endpoint (unauthenticated) and display it on the login page so that we know we are communicating with the data engine (shout out to Jared for that).
Unfortunately, the client started to complain it was taking 'ages' before they were able to login. We could see that version was taking a very long time to return.
On a side night, this server is running 2 other systems with OEngine Services for APIs configured the same (obviously different ports), both which behaved normally.
To cut a long diagnostic story short, it turns out that someone, once upon a time, had turned on debugging and forgot to turn it off when they were done. This resulted in MILLIONS of log files and many GB of data. The moment we disabled logging for thet environment we saw immediate performance response. We obviously then cleaned up the actual logs as well.
I would have thought the Framework would only need to check for the folder's existence and would need to parse the whole log directory (which windows did horrendously badly). My question is what, in the process of writing out the log files, might be stumbling over mass amounts of data?
Comments
Sorry, I wasnt being clear (I was probably just having the full conversation in my head and not 'on paper').
What I meant to say was "had turned on HTTP logging for debugging purposes". I used the term debugging in a generic sense of the process of tracing through an issue from source to destination. SRP's HTTP Framework logging is just one 'tool' used in the chain in this type of scenario, as well as Postman, Chrome Dev Tools, command-line OESocketServer.jar (rather than as a service) and the OI Debugger. I often, in the voices in my head, just package that all up together and refer to the process rather than the individual elements!
So, I definately mean the built-in logging of the HTTP Framework in this case.
Turning that logging off via the off the HTTP Framework Setup window immediately returned responsiveness to API calls so I know it wasnt just the existance of the log files. After clearing out the log directory via the file system and then turning the HTTP logging back on (only temporarily as I don't actually want it left on), the restored responsiveness remained.
My conclusion was that something in the process of writing out the log files for the HTTP Framework was having a negative affect on API responsiveness when the log directory had many entries. The client only started to complain by the time the log statistics were pretty massive but I can only assume that responsiveness was getting progressively worse for them.
This whole post therefore came down to trying to satisfy my curiosity as to what, behind the scenes, might account for that.