Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: the IS-A function Date: Sat, 20 Aug 2016 19:36:58 -0700 Organization: A noiseless patient Spider Lines: 30 Message-ID: <87oa4msv91.fsf@jester.gateway.pace.com> References: <88d81f07-03f4-4297-9e7e-953ac3bfeead@googlegroups.com> <9dfd5cb4-6975-40cb-ab72-756030623ee1@googlegroups.com> <51226078-dad2-4319-a37e-5f5c388aeed7@googlegroups.com> <84edde73-1b5d-4fc8-8395-d463d48f1437@googlegroups.com> <810b8836-ef38-45c6-849e-60a281485f3c@googlegroups.com> <53168bfe-8dcd-46cb-9fa1-cc369b9b9db9@googlegroups.com> <87pop4to9x.fsf@jester.gateway.pace.com> <062906a4-6b6b-4017-9d8b-02ca93bab295@googlegroups.com> <878tvrtjgq.fsf@jester.gateway.pace.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="e3de301d7f270f19e44cbaddb3a92e97"; logging-data="1881"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/380/rlMpLM7bkRBbLDrMc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:wF9AvRdQM3H7oK38huTW+6WmZ88= sha1:M1Qd3uHQdodvqkTJrWe/AuJvZAw= Xref: csiph.com comp.lang.forth:50304 Julian Fondren writes: > However, as the N servers are each running at 100% CPU "as desired", > they can receive no additional requests. That's not how it works. You can receive as many requests as you want. They just take longer to process. Since later requests are often dependent on the results of earlier requests, your throughput stays the same but you get fewer requests per minute from a given client. There are also scheduling priorities: you can have a long-running background task that gives up cycles as needed to shorter requests. I know I run my own machines at 100% on large computational tasks lots of the time, but I can still do other stuff on the machine. I don't notice any difference in interactive response on most quick operations. Bigger operations like compiles take noticably longer when the machine is loaded but it's still not too bad. > Load balancing changes nothing. If you're at 100% CPU, then you > either 1) need additional CPUs, or 2) need to squash a massive > abuse/performance issue, If you have persistent overload then you do add more CPU's, such as by calling an API to spin up additional VM's. If it's sporadic then you can choose to just live with it. Think of rush hour on the freeway. > 3) are running some kind of self-contained system where both resources > and demands on resources are entirely under your control and balanced > by you. This is in fact often the situation. Think of a video transcoding farm.