roland@f.haeder.net
Administrator of this instance
- Location:
-
Krefeld, Nordrhein-Westfalen
Germany
- XMPP:
- roland@f.haeder.net
- Gender:
- Male
-----BEGIN PUBLIC KEY-----
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAmCcTC/9layKjMlzRmA8D
e21V+GqTRRUYWZrfMy7vKyaDCqZNWa9RUCe/wP+dDj7uusU1cAsNtKN0bKFjRh2u
2okQJ1nzkkqYD467wjkEEo34nXFX5LIBKExwIfVTVrhDRkc2nsUE6BomdbGcDhL0
kHWXuMIgRsdUi0XSqmsYhjEuxlYQxqmxfZ1iDJxevaHgncdHBpumjvbvAoyHLR1Q
UDNN8a9cZ11r1usCEIJ5+aYFUPTIXDqxNDjgwSwEz4BCe+UYxWqmBlcGS0ryA74A
KEdSEdh1Z/8CTDsGcF3mLPV9O6UNPoPK4TPJ4Av2Xivf8q743SzawMPcNEV9nv5H
kGeUmrN4RGeViJerAPEiMNdKVggp0E5CLFXc1BzWAb9vAsqQozH5qc9RQYWEzRKs
aU9nrHDX3yfDMsF/IB8fL0HJwuW+xilD5wX+jiaYwYuti77kxxp4mFMApArTBXFa
aPeYBk7JzA6EgBPY5RkMre6/f4lBZVuZr9vcg5KEa2WoDEzb2E9sjaaXNE828W35
ttiUk0PSBektxUoXk6CIkGSr9+sFSkTsZGh+m1Kqyj0v0igVFQHHBoZBZvBScyLG
B0TkILeia17CwfZe9xTTt5HKyEvWQyvjh3s4dNRnAoxF5j9ZDgUzGWrwBVYq8qwf
A6UPZCF65LPDdBIaMygpekcCAwEAAQ==
-----END PUBLIC KEY-----
124
2019-02-17T16:09:31+01:00
- ♥Status:
- It's complicated
- Homepage:
- http://mxchange.org
- About:
- Love my pinay/filipina wife and first child.
Love free software, freedom, decentralization and no capitalism.
- Uid
-
adbba6c61456b79fdfd135b760919610
- Nickname
-
roland
- Full_name
-
Roland Häder
- Searchable
-
true
- First_name
-
Roland
- Family_name
-
Häder
- Url
-
https://f.haeder.net/
- Photo
-
- Photo_medium
-
- Photo_small
-
This gives great performance improvement due to not with every request (POST/GET) data is not being loaded from database but taken from cache. This is what I call asynchronous loading of data, most PHP applications however are synchronous, means with every click data is fetched from database and scripts are loaded and parsed (OpCache is maybe a bit improving here) and are being "forgotten" after the request was finished.
But with a JSF application, the "controller" (backing bean) remains instanced (and wrapped) in the web container's heap until you redeploy the application or restart the web container.
So sure I want to use that advantage of having all loaded at "all" (not at the beginning, but you can implement a ServletContextListener interface where you can "hook" on the initialization phase) times. Still this issue is there.
As you can see, not on every request these SQL queries are performed (which is very good for overall performance) but still they are really a lot. Just imagine 1,000 users on your web server (you may need a cluster then) and several 10,000 records.
Sure, when you cache them all in RAM, then you need a lot RAM. The #Payara application server uses here #Hazelcast ( https://hazelcast.com/ ) for having a distributed heap (cluster members contribute their heap to the cluster) and JCache (JSR107).
So what now? I still found this a bit to much. Currently I use eager fetch-mode, I could switch to lazy but that only delays the problem as foreign entities are being lazyless (on getter invocation) loaded.
Back to your issue. Initial data load takes more RAM. This actually was the subject of a recent performance improvement in Friendica: should we load all the configuration values at once at the start of each script or should we query each individual values? it turns out RAM consumption rarely is the bottleneck in a PHP application because of the "fire and forget" architecture you described: the script is loaded, executed, forgotten. So a increase in memory consumption wouldn't be significant, especially if it implies a reduction in script execution because the memory consumption pike will be shorter. However, for a long-running server application, using more RAM probably is a bigger deal.
No matter what, here are the general axes of improvement to reduce the number of requests:
Back to my issue, the #JPA (Java Persistence API) fetches records from database, creates an instance for each record of your entity class and wraps it into a proxy class. Then that proxy class is being compiled and most JPA implementations are caching them (the entity manager does this). This has nothing to do with the application or that it uses AJAX. My main goal is to reduce invocations of EJB business methods as this is "expensive" (a lot code need to be executed).
Just imagine, you can deploy your model classes on an other server or even data center and from your backing bean's perspective you have to change nothing at all as all is encapsulated away for you (most #JavaEE application servers use #CORBA for serializing and deserializing data).
Means on one server (or cluster, doesn't make a difference in Java code) you have your web "controllers" (they are not called controllers, backing beans are the right words for them) and on the other your model classes are running. This means one thing: distributed application load.
Okay, I'm explaining to much off-topic. With "synchronous" I mean with every request (even AJAX requests as they are basically HTTP requests. too) data is being fetched from the database. With "asynchronous" this is not the case. And I mean with this, that data is not being fetched from on each database, but maybe from a cache (that needs to stay updated, of course).
Anyway, I probably would go the caching way, it seems more in the spirit of Java (adding a middle block between two atomic blocks) than trying to coerce an atomic block into doing a non-atomic task.
ALL
to the existingEAGER
andLAZY
. That would have to go into JPA specification, of course which made all persistence providers, like #eclipselink , #hibernate, #datanucleus and so on unified as before every provider did it on their way.This is why I like the JPA, because it is dbms-independent and provider-independent at the same time. No need to worry if your data is stored in a SQLite, MsSQL, Oracle DB or good-old MySQL or even "exotic" database systems like MongoDB.
Have you seen such pattern professionally?
To answer your question, I like both, if that satisfies your question.