Hi,
I do not have the T5 source checked out / buildable - so thats not a
very easy task for me. I will see if I find time for that.
Our app is not particular lightweight - more a J2EE monster style app -
650 entities, over 2500 spring beans
The pages we are initializing in Tapestray are consuming several hundred
MB of RAM holding thousends of components - this make this issue so
visible to us. I understand that 99% of Tapestry Apps will not face that
problem.
I would guess following behaviour with normal references:
Test case 1 (2GB): same as before
Test case 2 (1.4GB): not sure about that - maybe GC overhead warning
Test case 3 (1.2GB): OutOfMemory
Robert
Am 02.04.2015 um 03:11 schrieb Kalle Korhonen:
Actually Robert, I'd love it if you could patch/override T5 core just
enough to disable SoftReferences and re-run your test. The results may
surprise you. I could almost guarantee you'd see the same performance
pattern for any modern jpa 2.x application. At 1.2GB, it doesn't look like
your test setup is just a synthetic, lightweight t5 app with no back end,
is it?
Kalle
On Apr 1, 2015 3:44 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote:
A configurable cache might be ok but what Robert is showing is a highly
typical performance degradation pattern for any sufficiently large Java
application. Tapestry's page cache is hardly the only place where soft
references are used. When your memory budget is too small, most system
engineers would argue that it's far better to slow down the application
than OoM, but obviously that depends on the type of application and the
traffic patterns you are facing. For the consumer facing application, it's
not uncommon to see peak traffic 30-100 times over the averages at least
with the applications I've been involved with and I would hate to to budget
all resources based on peak consumption only. On the other hand, if the
number of pages on the site is small and the site is evenly in use, then
sure, it'd make sense to never purge.
Kalle
On Wed, Apr 1, 2015 at 3:01 PM, Howard Lewis Ship hls...@gmail.com
wrote:
I'm feeling that Robert is making a very good case here. I could imagine a
page-level annotation to either enable or disable evication of a page
instance after a period of time ... but that can come later. I do think
that hard-caching of pages will leading to more predictable response
performance.
On Wed, Apr 1, 2015 at 7:31 AM, Robert Schmelzer rob...@schmelzer.cc
wrote:
Hi,
I now found time to sum up a short report about that topic.
I summarized my results in following pdf file:
http://www.schmelzer.cc/Downloads/Files/Tapestry-Memory-Performance.pdf
The main issue is, that you are able to bring a Tapestry based system
into
a situation where it gets slower and slower and finally event not
responding any more, just be decreasing memory on the JVM and you DO NOT
get any error message or OutOfMemory warning or GC overhead warning.
And
that only because the PageImpl instances are held in SoftReferences. My
opinion is still, that this does not work as it is supposed to do and I
keep with my example about other infrastructure. You would not expect
e.g.
Spring beans or a hibernate configuration to get thrown away under
memory
preasure - you would expect them to fail with OutOfMemory if they are
not
able to hold their necassary static information in memory.
Regards
Robert
Am 19.03.2015 um 17:55 schrieb Kalle Korhonen:
On Thu, Mar 19, 2015 at 12:24 AM, Robert Schmelzer rob...@schmelzer.cc
wrote:
Sorry, I was unprecise - my example should have referenced to the
EntityManagerFactory (SessionFactoryImpl in Hibernate). You would not
expect them, to throw away its cached configuration on memory
preasure. I
do not either expect that from Tapestry.
I cannot make our results public because of regulatory issues. I will
try
to setup a show case for that and will offer a patch. This will take
me a
few days.
I don't think we are going to simply do away with the SoftReferences
without any replacements so I wouldn't even attempt at offering such a
patch. I just don't agree that a memory cache should be permanent
construct. If your object is not in a cache, you'll simply incur a
cache
miss and re-create the object on the fly. It is not typical that a
cache
will grow indefinitely. If you are adamant on this approach, you could
probably convince us to add a symbol to control the cache behavior
(i.e.
to
never purge objects from it). Guava has excellent, easily configurable
cache implementations.
Kalle
Robert
Am 18.03.2015 um 18:19 schrieb Kalle Korhonen:
On Wed, Mar 18, 2015 at 12:44 AM, Robert Schmelzer
rob...@schmelzer.cc
wrote:
I do not agree with you on that point. Tapestry is designed to
cache
the
page. When you do not have enough memory to hold your pages cached
basically the system does not work as designed so you should fail
early.
Otherwise you possible defer the problem to production use. Fail
