Table and Query Classes good or unnecessary?

hi Stene:

careful on this — its a bit misleading since there is an apples an oranges comparison of MULTI THREADED vs MULTI PROCESS

You are right that ONE omnis cannot consume more than 100% of a single CPU core because it is SINGLE THREADED

yet, we demonstrated ONE omnis using 350% of a 4 core machine (call that 400%) — using the pgsql dam workers about 7 or 8 years ago at euromnis with an early demo of threaded workers. Meaning a SINGLE THREADED omnis with MULTI THREADED xcomps could handle some serious data acquisition using an async model. Thats been extended to the web workers.

What Martin was saying to Reg it a truism of MULTI_PROCESSING. if you sparf up enough SINGLE THREADED processes, you can also consume a lot of the CPU. In tests, we’ve been able to spark up 16 or more omnis processes and really max out a quad core machine — in that scenario, omnis, as multi-process, could do a lot of web requests. (we’ve also sparked up more on larger machines to try to find limits).

so, the commentary on the slide, which says:

> The processing load for Omnis is distributed amongst 4 different cores but is not allowed to consume more than 100% of processing power – but the max available processing power is between 400 – 800% (depending on utilisation of hyper threads).

can be altered to be this…

ONE Omnis, can use 100% of ONLY one CPU for omnis 4GL CODE because it is SINGLE THREADED.

ONE Omnis, with postgres or web workers, can be made to use all of power on ALL CPU’s since
— omnis will stay in the one CPU
— the workers will use the other cpu’s because they are MULTI PROCESS

MANY omnis, running in a multi-process environment can use ALL of the CPU’s in the machine, quite handily.

Same as any other language, the developer is left to decide how to mix MULTI PROCESSING and MULTI THREADING to achieve what they need.

you are dead in the water, with any language, if you stick to a single processing model since you are avoiding scaleability of the other cpus.

The above is how we wrote our web services (multi-Process, multi threaded) in omnis.

We had to use a similar development model in Python to get multi process working for web services – in other words, we spark up a lot of python processes to listen to NGINX web requests. That uses all the CPU cores – because of multi processing. The exact same thing was done with omnis in the past where multiple omnis listened to an apache server – and that also worked because of multi processing.

similar design. omnis took 400% of the CPU.

I’m neither defending omnis nor promoting python.

what I am suggesting is that omnis as a server process:
— which is lightweight to start (headless linux — looking forward to this) and
— and continues to get some speed optimizations from engineering (it is getting faster I see) and
— has a front end that distributes load (eg NGINX or Apache)

could function similarly to python.

Omnis will never be a capable MULTI-THREADED language. I hope that nobody even tries. The power, as Martin says, is using these tools in mutli-process design.

not sure if that makes sense.

It took us a few years to get over the ‘make one omnis do all the work’ instead of make ‘many omnis share all the work’. we were boxed in a paradigm and it cost us a few years of development effort …. once we broke out .. its been a breath of fresh air. so, as an example, we are going to implement multi-prcess omnis report servers .. and we can fire a lot of reports to a server and get them done in the background, simultaneously, multi-process style.

Doug Easterbrook
Arts Management Systems Ltd.
mailto:doug@artsman.com
www.artsman.com
Phone (403) 650-1978

see you at the third annual users conference
tickets.proctors.org/TheatreManager/95/online?performance=29086 <tickets.proctors.org/TheatreManager/95/online?performance=29086>

> On Mar 20, 2018, at 6:53 AM, Sten-Erik Björling <s-e.bjorling@enviro.se> wrote:
>
> Regarding multithreading and binding to a single processor core – below is a slide from the German conference presentation covering a test.
>
> To be noted (beyond the comments in the slide):
>
> – The processing load for Omnis is distributed amongst 4 different cores but is not allowed to consume more than 100% of processing power – but the max available processing power is between 400 – 800% (depending on utilisation of hyper threads). It seems that the macOS is utilising Grand Central in the OS to effectively distribute the processing load between the cores. Windows under VMWare Fusion shows the same limitation.
>
> One can imagine what might happen if this limitation is lifted.
>
> Take care, all the best…
>
> Stene
>
> _______
>
>
> _______
>
>> 15 mars 2018 kl. 10:39 skrev Marten Verhoeven <m.verhoeven@van-beek.nl <mailto:m.verhoeven@van-beek.nl>>:
>>
>> Hi Reg,
>>
>> I think there are three problems currently with Omnis as a middle tier (maybe four):
>>
>> 1. Omnis doesn’t handle multi-threading / multi process very well. You have to install multiple instances to get multi process and add an intermediate layer in between to distribute the calls.
>
>
>
> Sten-Erik Björling
> Enviro Data
> Kyrkogatan 5A 2 tr
> SE-972 32 Luleå
> Sweden

_____________________________________________________________
Manage your list subscriptions at lists.omnis-dev.com
Start a new message -> mailto:omnisdev-en@lists.omnis-dev.com