On 15.07.21 10:12, Greg Huber wrote:
You are correct, it is easy to read, and a good one liner.
Alas, like most frameworks nowadays, we lean how the framework works
(former) rather than programming (latter).
....having the main class WeblogEntry getTag() initially from the db
in the correct order (by pubtime) would save some work.
right. A few things could be put to "on write" instead of "on read",
since data is read more often than written in typical web apps. Since
JPA itself can return streams, we could go streams all the way to the DB
without collections in between if a perf bottle neck is identified.
Although, in this particular case of tags, sorting is basically a no-op
perf wise since a blog entry has 4 tags or so - so i would not bother.
I am running the blog (and 2 other JVMs) on a raspberry pi 3 with JFR
and some performance metrics enabled and it is "fast enough for me".
Rendering perf is ok (most time is spent in velocity) and once its in
the cache, all this doesn't matter anymore.
(I run a post-start task which warms up all entries in the feed to load
everything into the cache)
larger deployments like the apache blog would probably have proper
caching in front of roller anyway without even hitting the roller cache.
+ the PR was large enough already.
btw if you want to review a few commits of this PR please do so on github.
-michael
