load balancing experience

CLIFFORD ILKAY clifford_ilkay at dinamis.com
Sat Dec 21 16:35:59 EST 2013


On 12/20/2013 02:55 PM, Dave Braford wrote:
> Here are some things I think about when I think of using OMNIS as a delivery mech for content/data, etc:
>
> 1) AFAIK, the OMNIS Web Server a single threaded app spawning processes that use time-slicing, not true parallelism.
> Is this still the case? Anyone with more info?
>
> 2) From my experience, most load balancing is done at the TIP level, not with web server proxying. aka: Zeus/StingRay.

The nginx to Apache proxying that I mentioned wasn't for load balancing.
It was for performance and also to reduce the memory footprint of the
application. Apache is resource hungry. A bunch of slow clients hitting
Apache can bring almost any sized server to its knees. It also doesn't
degrade gracefully like nginx does under heavy load.

> 3) Considering that Postgres does not natively replicate, I would still find MySQL, Oracle or even MS-SQL
> necessary for large volume or HA installations.
> Any thoughts on this?


I don't know what "natively replicate" means. I know that PG has had
replication for some time and it is in production use in very large
installations.


> My initial tests with the Web Server on CentoOS (quite some time ago) showed it to be
> SIGNIFICANTLY slower in response and delivery that an identical app using PHP/PDO.
> Not to mention that it consumed far more resources than PHP.


It's not a surprise it would be slower. Abstraction layers are
expensive. The trade-off is productivity and maintainability. Caching
solves a lot of performance problems.


> While I do like Omnis Studio for desktop/installable apps, I can't see using the Web Server
> as a viable data/mobile delivery platform. There's just too much out there that's simpler,
> cheaper, more reliable and better performing (at this time).


I agree completely. I've never seen the point of Omnis on the web.

-- 
Regards,

Clifford Ilkay

647-778-8696

Dinamis

<http://dinamis.com>




More information about the omnisdev-en mailing list