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

Richard Sargent via Glass glass at lists.gemtalksystems.com
Wed Nov 29 09:27:33 PST 2017


Marten, when you write "sort 300000 addresses", that is a good indicator
that you may benefit from indexes on your collection(s). I think the
Programming Guide has an entire chapter on indexes.


On Nov 29, 2017 09:00, "Marten Feldtmann via Glass" <
glass at lists.gemtalksystems.com> wrote:

> Considering the fact, that I am not an expert in interpretation of the
> statistics of the system I noticed, that the time is indeed needed for
> reloading pages to get access to all data needed for the computation
> (PageIOCount, PageLocateCount, PageReads)
>
> In one case I sort around 300000 addresses and this needs at least 3
> seconds - when lots of data has to be loaded (from disc) it goes up to more
> than 20 seconds (and this is only early experiences) - and this on a system
> without load. I think on a system with heavy load this will goes up even
> higher.
>
> Marten
>
> Marten Feldtmann via Glass <glass at lists.gemtalksystems.com> hat am 27.
> November 2017 um 21:49 geschrieben:
>
> This is a typical "any idea" question :-)
>
> I'm now in the process of doing heavy performance tests and I notice a
> strange effect - the time for responding a query varies very much and I've
> no idea how to find out, where the reason for the performance problems are.
>
> I've a system of 8 responding topaz processes answering http requests (2
> core license on a 4 core cpu witrh 8GB RAM). The load tests are around 50
> transactions/second. Normally a specific query can be answered within 1-2
> ms, but when this query is not executed for some time the time needed for
> an answer increases and I found answering times with up to 12000ms. The
> system s located on a SSD, has been defined to have a 2GB of cache. The
> system has lots of transactions (commit and abort). If I have no
> transactions the system answers the query within 1-2 ms. So I assume, that
> this association a thrown out of the shared cache (even though 2 GB cache
> is pretty much) - but how can I proove this ?
>
> Any further idea with the statmonitor and/or how to interpret the results ?
>
> Marten
>
>
>
>
> _______________________________________________ Glass mailing list
> Glass at lists.gemtalksystems.com http://lists.gemtalksystems.
> com/mailman/listinfo/glass
>
>
> _______________________________________________
> 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/20171129/63458715/attachment.html>


More information about the Glass mailing list