[External] : Re: jstack, profilers and other tools

[Alex Otenko]

The "other laws" don't contradict Little's law, they only explain that you
can't have an equals sign between thread count and throughput.

Let me remind you what I mean.

1 thread, 10ms per request. At request rate 66.667 concurrency is 2, and at
request rate 99 concurrency is 99. Etc.  All of this is because response
time gets worse as the "other laws" predict. But we already see thread
count is not a cap on concurrency, as was one of the claims earlier in this
thread.

If we increase thread count we can improve response times. But at thread
count 5 or 6 you are only 1 microsecond away from the "optimal" 10ms
response time. Whereas arithmetically the situation keeps improving (by an
ever smaller fraction of a microsecond), the mathematics of it cannot
capture the notion of diminished returns.

So that answers why we are typically fine with a small thread count.

Alex

On Sun, 24 Jul 2022, 15:18 Ron Pressler, <ron.pressler at oracle.com> wrote:

> Little’s law dictates that concurrency must rise with throughput (=
> request rate) assuming latency doesn’t drop, i.e. the number of requests
> being served rises. If your program is thread-per-request then, by
> definition, if the number of requests rises so must the number of threads.
> Of course, while we’re only talking about thread-per-request here, if you
> choose to do something else you can disentangle requests from threads and
> then concurrency is not tied to the number of threads (but then you give up
> on synchronous code and on full platform support).
>
> All this is covered in JEP 425, which explains that to reach higher
> throughputs you must either abandon the thread as the unit of concurrency
> and write asynchronous code, or use threads that can be plentiful. The
> reasons we invested to much in making threads that can be plentiful are: 1.
> There are many people who prefer the synchronous style, and 2. The
> asynchronous style is fundamentally at odds with the design of the language
> and the platform, which cannot support it as well as they can the
> synchronous style (at least not without an overhaul to very basic
> concepts).
>
> BTW, I don’t understand your point about there being “other laws at play.”
> Little’s law is not a physical law subject to refutation by observation,
> but a mathematical theorem. As such, short of an inconsistency in the
> foundation of mathematics, all other mathematical theorems must be
> consistent with it. To accommodate higher request rates, latency must drop
> or concurrency must rise — that must always be true. Other laws may state
> other things that must also be true, but they cannot contradict this.
>
> — Ron
>
> On 24 Jul 2022, at 14:07, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>
> I think none of this statement has anything to do with Little's law.
>
> On Sat, 23 Jul 2022, 02:04 Ron Pressler, <ron.pressler at oracle.com> wrote:
>
>> We’re talking about thread-per-request programs. In such programs, one
>> thread has a concurrency of one (i.e. it handles one request, hence
>> “thread-per-request”). As I explained, to get higher concurrency than
>> what’s allowed by the number of OS threads you can *either* use user-mode
>> threads *or* not represent a unit of concurrency as a thread, but here
>> we’re talking about the former. All that is covered in JEP 425.
>>
>> — Ron
>>
>> On 23 Jul 2022, at 00:25, Alex Otenko <oleksandr.otenko at gmail.com> wrote:
>>
>> I think the single threaded example I gave speaks for itself. 1 thread
>> can sustain various throughputs with various concurrency. I've shown a case
>> with 99 concurrent requests, as per Little's law (and I agree with it),
>> and it's easy to see how to get any higher concurrency.
>>
>> There are other laws at play, too, so my example latency wasn't random.
>> But this has been long enough.
>>
>>
>> On Thu, 21 Jul 2022, 12:30 Ron Pressler, <ron.pressler at oracle.com> wrote:
>>
>>> Little’s law has no notion of threads, only of “requests.” But if you’re
>>> talking about a *thread-per-request* program, as I made explicitly clear,
>>> then the number of threads is equal to or greater than the number of
>>> requests.
>>>
>>> And yes, if the *maximum* thread count is low, a thread-per-request
>>> program will have a low bound on the number of concurrent requests, and
>>> hence, by Little’s law, on throughput.
>>>
>>> — Ron
>>>
>>> On 20 Jul 2022, at 19:24, Alex Otenko <oleksandr.otenko at gmail.com>
>>> wrote:
>>>
>>> To me that statement implies a few things:
>>>
>>> - that Little's law talks of thread count
>>>
>>> - that if thread count is low, can't have throughput advantage
>>>
>>>
>>> Well, I don't feel like discussing my imperfect grasp of English.
>>>
>>> On Tue, 19 Jul 2022, 23:52 Ron Pressler, <ron.pressler at oracle.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On 19 Jul 2022, at 18:38, Alex Otenko <oleksandr.otenko at gmail.com>
>>>> wrote:
>>>>
>>>> Agreed about the architectural advantages.
>>>>
>>>> The email that triggered my rant did contain the claim that using
>>>> Virtual threads has the advantage of higher concurrency.
>>>>
>>>> > The throughput advantage to virtual threads comes from one aspect —
>>>> their *number* — as explained by Little’s law.
>>>>
>>>>
>>>>
>>>>
>>>> Yes, and that is correct. As I explained, a higher maximum number of
>>>> threads does indeed mean it is possible to reach the higher concurrency
>>>> needed for higher throughput, so virtual threads, by virtue of their
>>>> number, do allow for higher throughput. That statement is completely
>>>> accurate, and yet it means something very different from (the incorrect)
>>>> “increasing the number of threads increases throughput”, which is how you
>>>> misinterpreted the statement.
>>>>
>>>> This is similar to saying that AC allows people to live in areas with
>>>> higher temperature, and that is a very different statement from saying that
>>>> AC increases the temperature (althoughI guess it happens to also do that).
>>>>
>>>> — Ron
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20220724/51a6ff4a/attachment-0001.htm>