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

[Mariano Martinez Peck via Glass]

On Wed, Nov 29, 2017 at 4:48 PM, Marten Feldtmann via Glass <
glass at lists.gemtalksystems.com> wrote:

> Well, yes I could benefit from that - but considering, that I can sort
> that number of items in 3 seconds on my machine when nothing else happens -
> but the time gets up dramatically when working on other parts on the
> database and come back I do not assume, that index may help that much !?
>

I think so. Because the index is NOT only for sorting it but also to avoid
page faulting the (complete?) underlying objects. Say you have 300k objects
and you want to sort by a  single string. As far as I understand, when
using indexes, you do NOT need to object fault each of those 300k as you
can access the indexes structures directly (you can avoid fetching the
object completely).  So I think that page faulting the indexes structures
should be much cheaper than having to page fault ALL the underlying objects.

Does that make sense?



> Marten
>
> Richard Sargent <richard.sargent at gemtalksystems.com> hat am 29. November
> 2017 um 18:27 geschrieben:
>
>
> 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.co
> m/mailman/listinfo/glass
>
>
> _______________________________________________
> 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
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20171129/dcddbd96/attachment.html>