[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 882
  • Last Modified:

Calculating SLA times - DB or code?


Hi,
I would like to know what are the cons and pros of calculating the SLA in code each time we present the data vs. running a process, which will update on each day the SLA fields inside the DB.
What is the standard (if exist such(.
0
netformx
Asked:
netformx
  • 4
  • 2
2 Solutions
 
carlnorrbomCommented:
Hi,

Well, the pros of doing it in code at runtime is that you actually can see your preformance in relation to the SLA in real time. If you only calculate say, once per 24 hrs, you can actually be uncompliant for like 23:59:59 without knowing it You're unlucky?!?

Normally the easiest way would be to store the required response / resolution time along with the request once it's created and then simply compare at runtime.

/Carl.
0
 
sybeCommented:
SLA? What does that stand for in this case?

http://en.wikipedia.org/wiki/SLA
0
 
carlnorrbomCommented:
My guess would be Service Level Agreement?
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
sybeCommented:
You don't calculate a Service Level Agreement from values in a database, or do you?

generally however:

Databases can do some simple calculations as SUM, MAX, AVERAGE, but a database is not really meant for complex calculations.

Programming languages (code) are designed to do calculations (among other things), but depending on the complexity of the calculation, you have a performance hit.

So it really depends. If the calculation is complex and the page gets 5,000 hits/minute you are better of to have the calculation done once per minute (or hour) and have people look at a not-totally updated result.

Or you could update the result only when something changes the result, like some changed or new data in the database.
0
 
carlnorrbomCommented:
Hi,

That's why in my recommendation above I suggested to store the target respone / resolution time along with the original request in the DB. This way, the check whether or not things are compliant to SLA (i.e. did we respond in time, resolve in time) is a matter of a simple comparison between the datetime in the DB and datetime.now (simplified i know, but you get the point).

I have done this numerous times for servicedesk applications and such, there's really not right or wrong in this, just different angles and different requirements.

/Carl.
0
 
carlnorrbomCommented:
Hi again (sorry for being a pain ;-),

Just to clarify:

1. Request made -> Check SLA: Response 8 hrs, Resolution: 48 hrs -> Store in DB: Target Response = DateTime.Now.AddHours(8) & TargetResolution = DateTime.Now.AddHours(48)

2. Request checked in real time -> Check Response: Has the response time been stored in the DB? -> If yes, then:

- ResponseTime < TargetResponse = Compliant to SLA
- ResponseTime > TargetResponse = Failed through response

If no response time stored:

- DateTime.Now() < TargetResponse = Compliant to SLA
- DateTime.Now() > TargetResponse = Falied through response.

The same goes for resolution. Normally You would continously update the "status" of a request through the application, i.e.:

- New
- Open
- Pending/Idle
- Closed
- Etc.

You would update the database records for the request to reflect when changes in status are made, i.e:

"New" -> "Open" = Response Time
(("New" -> "Closed") - "Pending/Idle") = Resolution Time

Hope this thinking makes sense.

/Carl.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now