September/October 2018 issue of acmqueue The September/October issue of acmqueue is out now

Subscribers and ACM Professional members login here


  Download PDF version of this article PDF

Error 526 Ray ID: 47d1762f1823c5fe • 2018-11-21 07:32:18 UTC

Invalid SSL certificate








What happened?

The origin web server does not have a valid SSL certificate.

What can I do?

If you're a visitor of this website:

Please try again in a few minutes.

If you're the owner of this website:

The SSL certificate presented by the server did not pass validation. This could indicate an expired SSL certificate or a certificate that does not include the requested domain name. Please contact your hosting provider to ensure that an up-to-date and valid SSL certificate issued by a Certificate Authority is configured for this domain name on the origin server. Additional troubleshooting information here.


Originally published in Queue vol. 12, no. 1
see this item in the ACM Digital Library



Richard L. Sites - Benchmarking "Hello, World!"

Noor Mubeen - Workload Frequency Scaling Law - Derivation and Verification
Workload scalability has a cascade relation via the scale factor.

Theo Schlossnagle - Monitoring in a DevOps World
Perfect should never be the enemy of better.

Ulan Degenbaev, Jochen Eisinger, Manfred Ernst, Ross McIlroy, Hannes Payer - Idle-Time Garbage-Collection Scheduling
Taking advantage of idleness to reduce dropped frames and memory consumption


(newest first)

William Louth | Mon, 28 Apr 2014 12:26:20 UTC

William Louth | Mon, 28 Apr 2014 03:11:44 UTC

I don't believe the above points adequately address the problem as it is simply infeasible to measure "everything" such as a HashMap.get() to detect variation from the norm which is otherwise extremely fast and far faster than even a single clock counter access. Though I am delighted that this issue has been brought to the attention of many.

The main problem is surprisingly one of communication and awareness. The API developer has no way of communicating various signals (and their quantities) to the caller to without pushing (exposing) this to the surface of the API that represent key drivers in the servicing of a particular caller. The caller has no way of collecting these signals across far broader and extended interactions, possibly encompassing other further delegated interactions which also expose their own signals. Then there is the problem of the code not being able to identity the caller, or type of caller, within some conversation context, that can be used to on the fly predict and adapt behavior. Surprisingly, or maybe not, I actually designed a possibly solution for this that finally brings self adaptive technology to the software world. Unfortunately I've not been terribly successful in getting the Java platform team on board this concept.

"This working document introduces the reasoning, thinking and concepts behind a technology we call Signals, which we believe has the potential to have a profound impact on the design and development of software, the performance engineering of systems and the management of distributed interconnected applications and services. We originally designed Signals to address the sub-microsecond execution performance variation analysis of software in extremely low latency high frequency transaction and messaging environments but subsequently evolved our design to incorporate support for the development of new software components, libraries and platforms that are self adaptive."

David Collier-Brown | Sun, 09 Feb 2014 14:31:53 UTC

May I suggest a point 7: have a performance budget.

If you chose a function so that it's typical of others in a group, assign it a time budget. Let's say it typically takes just under 1/10 of a second when it's tested with single requests. Let's also say that it's a low-level function, and the middleware and tophamper only increase its service time to one full tenth. Your overall budget is therefor a tenth of a second. For each processor (queueing center) in your machine, you will get a maximum of 10 requests serviced per second. You can't get 11/10 into one second! Therefor you need to give this function a budget in CPU-seconds that will keep it below 10/10s. Traditionally people use 8/10, to keep down the probability that a whole bunch or request will arrive at overlapping times.

If your function is reasonably (not perfectly!) representative, and you can see from your logs how prevalent it is, you can approximate how the rest of the system will behave, not counting outliers. This kind of time-based calculation is what capacity planning software like pdq or Teamquest does, with the extra advantage that it also predicts the degradation when you overspend your time budget, and tell you how much slower your function and system are going to be under normal overload (;-))

Once you know your budget, it becomes easy to look at the logs and say "we're 40% slower that planned for this load", instead of "something bad is happening, and we don't know why"

Leave this field empty

Post a Comment:

© 2018 ACM, Inc. All Rights Reserved.