There are various reasons to your page loading for the first time call will get slow.
The first request to a publication requires downloading & parsing of a lot of binary files with publication configuration after that page and used images and components links resolving calls for that page.
To gain the performance caching is important to enable in your ...
I got rid of that error from the logs by adding the TokenService back to the cd_client_conf.xml on the webapp side.
<TokenService ClientId="clientID" ClientSecret="encrypted:password"/>
This seems like a bug with DXA where even after you have the oAuth disabled, you need the token service tag with client id and client secret in the webapp. For some ...
This is used to inject markup from entity views to placeholders in page views, for example additional CSS/JS includes, JS snippets to be executed after jQuery has been initialised etc. This makes it easier to make DXA modules more self-contained when it comes to needed resources. This is used for example in the Instant Campaign module to inject campaign ...
This is expected behaviour as you shouldn’t be able to use the same url for two sites (within Topology Manager).
You’re going to have to either:
Specify a different port
Use a different hosts name (and probably update your hosts file /DNS), or
Use the machine name / machine IP Address (e.g. http://192.168.0.22:9080)
Try to use http://127.0.0.1:9080
The DXA 2.1 release provides updates only to the .NET version of DXA. The Java version is planned for release soon after 2.1 in the subsequent 2.2 release. Until the 2.2 release is available, all references to the Java version should be assumed to be unchanged and as provided in the prior release 2.0.
Refer to the DXA 2.1 release notes
I hope ...
This is a bug with DXA 2.0 release - see https://github.com/sdl/dxa-content-management/issues/14. The issue has been closed, as there has been a fix made, but this is post 2.0. You will either have to upgrade your TBBs to DXA 2.1, or bake your own TBBs containing the (simple) code fix: https://github.com/sdl/dxa-content-management/pull/15
The Component content is stored in XML format in the DB.
If you update a schema XML name then the XML for that component no longer maps to that new field.
You can synchronize the content against the updated schema.  
If you're not allowed to do that, then you could create a new field and write something to copy the content of the original field (...
DXA decomposes TCM URIs; the ID of Entity Models correspond to the item reference ID of the TCM URI of the Component. In case of a DCP, the Entity Model ID is a combination of Component and Template ID.
Furthermore, you will find TCM URIs in the XpmMetadata but that is intended for (guess what?) XPM and not included on a Live environment.
Here’s an example ...
Yes. It's good to apply and important to understand the new changes and fixes included in the hotfix.
@Rick Pannekoek did a great presentation about "Beyond SDL Tridion Sites DXA 2.0" and explained about this Hotfix releases of DXA 2.0 changes.
DXA Model Service "in-process"
Much better performance using in-process CD APIs instead of CIL
No HTTP/OData (...
After doing a lot of trial and error, I was finally able to cache my object. Here are my findings for anyone trying to implement caching in DXA. These are not specific to DXA but common for Springs+EHCache.
@EnableCaching annotation on your context configuration class,
provide appropriate cache manager beans,
separate service bean into interface and ...
Found the problem, an extra UrlBasedViewResolver bean is in place with viewClass JstlView and order 5. Because of this new UrlBasedViewResolver the BeanNameViewResolver is never reached. This is why we get HTTP Status 404 – Not Found.
The Model Service will remove all component links which cannot be resolved to a proper html link.
The only work around I'm aware of of is to disable RTF component link resolving completely.
This can be done by changing the dxa.properties value -> "dxa.defaults.rich-text-resolve=false".
That way all Component links will be sent across unresolved.
Now the ...
change the mapping of the jsp servlet to /WEB-INF/Views/* so that the JSP servlet is only used for views, and leaves all other requests for the dispatcher servlet.
update the web.xml on webapp level
Just as your question is vague, I am afraid that the answer is also. What you need to do is basically do a stress test. See how your app behaves with this number of requests.
In general, bottleneck can happen in few places:
CD microservices - you can scale them up really easily - just add more servers and you are good to go. You can use different scaling ...
Refer to the SDL Documentation Content Delivery client configuration of ServiceConfig for Redis CIL cache.
A configuration sample for using Distributed Caching with Redis.
Please update the following fields:
CacheUri - in case of Redis is set to Redis hostname with a port number;
CacheClientId - should be the same for a bunch of ...
Like Alvin already mentioned, your requirements sound quite similar to what Experience Optimization does; you may want to take a look at the XO/SmartTarget Module to see how this kind of functionality is implemented there.
Spoiler: the XO/SmartTarget Module leverages the concept of Regions and can dynamically populate "SmartTarget Regions" with the results ...
Option1: Try to use the persistent storage mapping in your web app, for example, try to use EFS (NFS storage) symbolic or soft link folder map to your web application for BinaryData folder so that every time if you do deployment it will not be getting deleted images folder.
Option2: Alternatively, a possibility OOTB you could also achieve this by publishing ...
The below content service query was not returning any data. So, that none of the files were not generating since it's was throwing null exception
BasicEndpointCaller - Preparing the call endpoint for given url: http://domain:8081/client/v2/content.svc/BinaryContents%28PublicationId%3D826%2CBinaryId%3D216112%2CVariantId%3DY29uZmlnLWJvb3RzdHJhcA%3D%3D%...
According to the Stack Trace, the Model Service thinks that the raw Page content is DD4T JSON. Is that really the case?
Note that the Model Service makes this assumption as soon as it determined that the Page content is not DXA R2 JSON.
A typical way to end up in this situation is if you accidentally used the Default Page Template (which renders HTML).
Try enabling these following properties in dxa.properties file
#adf.context.provider - Activates ADF instead of Context Service for context claims.
ADF is needed for XPM Session Preview, Experience Optimization and Context Expressions. Values: [true, false]:
Note that the img XHTML element is supposed to be converted to an Entity Model (MediaItem-derived) which in turn should get rendered to HTML (using an appropriate View).
From what you are showing, it seems that the MediaItem-derived Entity Model is properly constructed (class Image), but it is not properly rendered as HTML, but instead its toString ...
The Component Link doesn’t get resolved (to a Page URL) because of setting dxa.defaults.rich-text-resolve=false.
If that setting is changed to true, the DXA Model Service will resolve Component Links to Page URL, assuming the linked Component is on a published Page. If not, hyperlinks in Rich Text are suppressed (i.e. the HTML a tag is removed).
It was an environment issue. DXA web application was deployed on load balance environment have two windows application server and we configured one cluster between two application that cluster was causing issue so we have added localhost entry in host file and resolved the issue
You have already pointed out that it's impossible to publish individual Keywords and you are correct. What you publish is a Category which in turn "publishes" all its keywords. Since there is no templating involved when publishing Categories, the output of the publish action is purely defined by a default taxonomy renderer Tridion.ContentManager.Publishing....
This is weird; for sure, the ability to retrieve A JSON representation by means of specifying format=json in the URL query string has not been removed in DXA 2.0 (as proven by automated regression tests).
I don’t know why you are getting that error, though. AFAIK, the JSON representation does not use a JSP view, but my knowledge of the Java implementation ...