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 early
means you should try to see the problem in the early stages on dev, where
you try out all your pages. As I mentioned in my other post - you would
also not expect the EntityManager to work soft-refereences or spring
application context to work soft referenced.
That's the definition of a memory cache - it trades memory for better
performance. The primary use case for soft refences is for caching so
seems
to me it works exactly as designed. Your comparison to the EntityManager
is
flawed since it's created per request. An EntityManager is designed to be
inexpensive to create. There are many areas that need improvements in
Tapestry but this is not one in my opinion. However, you seem to strongly
think otherwise, so you probably have some data to back this up. Do you
have a memory dump and trending cpu/memory charts of a sufficiently large
system you can share with us to demonstrate the problem? Jvisualvm
snapshots should work fine. And furthermore - how would you like this
changed? If it's just adding a Page as a threadlocal, perhaps you can just
write a patch for it.
Kalle
Am 18.03.2015 um 04:23 schrieb Kalle Korhonen:
In my opinion, soft referencing page objects is highly appropriate
usage
here. If there's pressure on the available memory, it makes sense to
trade
performance for memory instead of exiting with OoM. This is simple
condition to detect and should be visible with any reasonable monitoring
tool. If you are hitting memory limits, you'll need to allocate more
memory
for the application for optimal performance. Soft references are
especially
useful here because you can optimize its behavior with the
-client/-server
setting depending on your preferences.
Kalle
On Tue, Mar 17, 2015 at 4:26 PM, Howard Lewis Ship <hls...@gmail.com>
wrote:
Possibly we need something more advanced; our own reference type that
can
react to memory pressure by discarding pages that haven't been used in
configurable amount of time.
Or perhaps we could just assume that any page that has been used once
need
to be used in the future and get rid of the SoftReference entirely (or
otherwise janitorize it in some way).
On Tue, Mar 17, 2015 at 1:24 AM, Robert Schmelzer <rob...@schmelzer.cc
wrote:
Hello,
I recently came accross the implementation of PageSourceImpl where
PageImpl instances are softly refereneced into the pageCache:
private final Map<CachedPageKey, SoftReference<Page>> pageCache =
CollectionFactory.newConcurrentMap();
This implementation caused troubles, when you bring your system into
memory preassure. The JVM will start to throw away the PageImpl to
free
up
memory - but during request processing he needs the PageImpl again and
starts creating it again. So basically you end up loosing your
pageCache
at
all and start creating the PageImpl instances on every request, which
take
way to much time and takes load onto the CPU. So basically you are
hiding a
memory problem by making the system slow and raise CPU load.
I would suggest to use "normal" references for the PageCache or at
least
only do SoftReferences only when not in production mode. Otherwise we
are
going to cover memory problems for too long.
What do you think about that?
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
@hlship
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
