[Glass] Time to responds varies very much (performance problems)

[Richard Sargent via Glass]

That's great news Marten!
Thanks for the update.

On Dec 23, 2017 03:26, "Marten Feldtmann via Glass" <
glass at lists.gemtalksystems.com> wrote:

> Well, it turned out, that the virtual machine (the database was running
> on) was ONE virtual machine out of four machines - and all were running
> Gemstone/S and all were running on an HDD based server system and the image
> only had 8GB. So nearly all considerations we made for our installations
> were broken (16GB, SSD, dedicated root server) - and the general question I
> had to answer - " 'with mysql' this configuration would work without
> problems - why does your database needs so much power".
>
> Putting the database back to an old 4-year old Laptop with four cores and
> SSD and everything is ok.
>
> We rolled out the software before Christmas - and some days before we
> added our first java-based application, connecting to our database via our
> API and the automatically generated Java-Model/API. Due to a little bug in
> that program, the 2-core license had to show, that it was able to handle
> 300 application-transactions/seconds - which I think is pretty good. Both
> cores were running with 100% over an hour before we noticed this bug.
>
> One of the most difficult problems - in thr last stage of the rollout -
> was the correct load balancing using Apache2: to deliver the API calls to
> different topaz processes. The normal approach "lbmethod=byrequest" did not
> work very well - but "lbmethod=bybusyness" was much better.
>
> The problem here is in general are the long-time-consuming-API calls (e.g.
> 10 Minutes), those calls make the scheduling very difficult. We rewrote the
> logic of our system to handle background jobs - so the API is not actually
> doing the work - but registers a background job - doing the work later.
>
>
> Just some informations ...
>
> Marten
>
>
> Marten Feldtmann via Glass <glass at lists.gemtalksystems.com> hat am 29.
> November 2017 um 22:12 geschrieben:
>
> I tried a new license with 4GB cache, but that did not help at all. The
> extend is around 7GB large. I noticed, that the topaz processes are very
> often in the "D" state, which means, that IO is done - when I execute that
> statement very often, the responding topaz process does not need to go into
> "D" and I get the full expected speed. That's getting an interesting point
> of learning.
>
> Marten
>
>
>
> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171223/2fdd9566/attachment.html>