Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • Isomorphic
    replied
    Blama is correct for separate <script src=> tags with the DataSourceLoader servlet. <loadDS> JSP tags are different, in that they inline the DataSource definition into the initial page, not as a separate request.

    So for <loadDS> tags, we would expect a very small effect (if even measurable) for combining tags.

    However, as noted above, it's usually better to use the <script src=> approach with DataSourceLoader, because it allows the browser to start on other tasks in parallel.

    Leave a comment:


  • Blama
    replied
    Hi claudiobosticco,

    most definitely, otherwise it means MANY network requests and you really don't want that. See also here.

    Best regards
    Blama

    Leave a comment:


  • claudiobosticco
    replied
    Hello, I did notice some improvements in speed, but since I also made some application optimizations, I wasn’t sure if the changes were due to the framework as well. After running some tests, I can confirm there’s a noticeable improvement—thank you very much!

    Regarding the loadDS tag, can I expect any differences between using a separate tag for each data source versus a single tag with a comma-separated list of data source names as the ID?

    Leave a comment:


  • Isomorphic
    replied
    Actually, we did make improvements in this area back in March and April. deepClone() now has optimizations in place to avoid Reflection in common cases, and we find that deep cloning of a typical DataSource config now takes around half the time it did previously. However, we have also optimized this particular flow - cloning config for security annotations - so that it no longer does a deep clone at all.

    As mentioned, this has all been in place in 13.1 since April, so you should see it spending a lot less time in _cloneConfigForSecurityAnnotations() with 13.1 builds more recent than that

    Leave a comment:


  • Isomorphic
    replied
    Sorry, this fell through the cracks somewhat. Somebody will take a look soon, and we'll post back on this thread

    Leave a comment:


  • claudiobosticco
    replied
    Hello, may I ask if there has been some change development in this area?

    Leave a comment:


  • claudiobosticco
    replied
    Hello, just chiming in to ask if there's some update

    Leave a comment:


  • Isomorphic
    replied
    Nothing more is needed from you for now - we're going to try to figure out why that Reflection call is appearing in the middle of your DataSourceLoader processing, as it's probably possible for the framework to avoid it.

    Note that Reflection can be radically more or less expensive in different environments. One factor is a long classpath with duplicates, so you could look at reducing the cost of Reflection calls if you want.

    Leave a comment:


  • claudiobosticco
    replied
    Hello, are you investigating this problem, or do you need more debugging by my side?

    Leave a comment:


  • claudiobosticco
    replied
    Originally posted by claudiobosticco View Post
    which so far seems relative to fields with validators using <applyWhen>, or to fields with custom simple types which I have defined, ie like:
    actually they're relative to fields with validators using <applyWhen>, and to the loading of my custom Simple Types xml definitions

    Leave a comment:


  • claudiobosticco
    replied
    as a side note, only on first load I've got a bunch of logs like these:

    Code:
    WARN DefaultValidators Field 'name' not found in data source 'ServerObject'
    WARN DefaultValidators Field 'name' not found in data source 'AdvancedCriteria'
    WARN DefaultValidators Field 'name' not found in data source 'Criterion'
    which so far seems relative to fields with validators using <applyWhen>, or to fields with custom simple types which I have defined, ie like:

    Code:
    <SimpleType name="trimText" inheritsFrom="text" editorType="TextItem">
        <validators>
            <validator type="serverCustom">
                <serverObject lookupStyle="new" className="com.my.types.TrimDMI"/>
            </validator>
        </validators>
    </SimpleType>

    Leave a comment:


  • claudiobosticco
    replied
    Nope to both questions.

    Actually I see many calls to Reflection.findMethod, as in this debugger screenshot:

    Click image for larger version

Name:	2024-01-02 22.35.22.jpg
Views:	181
Size:	52.0 KB
ID:	271474

    smartClient version is 'v13.0p_2023-12-08/Enterprise Deployment'

    Leave a comment:


  • Isomorphic
    replied
    Hmm, there normally should not be a Reflection call in that codepath. Do you have any custom (non-framework) properties in your .ds.xml definitions - anything that isn't just a simple String value? Or do you do anything like use DSField.put() to put custom objects into your fields or DataSource definition (note this wouldn't be valid, due to pooling).

    Leave a comment:


  • claudiobosticco
    replied
    Hello, about dataSource pooling, what I see is a log like this, for every dataSource, on first load:

    Code:
    DEBUG PoolableDataSourceFactory Created DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712' and assigned it to thread https-jsse-nio-8443-exec-8
    DEBUG PoolableDataSourceFactory Created DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712' in the pooling flow
    DEBUG PoolableDataSourceFactory Activated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
    DEBUG PoolableDataSourceFactory Cleared and passivated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
    on the second load I see this, for the same dataSources:

    Code:
    DEBUG PoolableDataSourceFactory Activated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
    DEBUG PoolableDataSourceFactory Cleared and passivated DataSource 52 of type 'ANAG_GRAFICI_MATCH_ANALYSIS' with hashCode '145547712'
    does this seem correct?

    About the java profiler, unfortunately I'm not an expert, at a first glance it seems that a lot of time is spent in that _cloneConfigForSecurityAnnotations method, does this even make sense?


    Click image for larger version

Name:	2024-01-02 17.39.06.jpg
Views:	174
Size:	73.3 KB
ID:	271471
    Attached Files

    Leave a comment:


  • Isomorphic
    replied
    Pooling is on by default, with certain exceptions (like DynamicDSGenerator). As we mentioned, if you temporarily turn on pooling-related logs, you will see log messages about DataSources being borrowed and returned. Background here:

    https://smartclient.com/smartclient-...Implementation

    If you confirm that pooling has not been disabled, we would recommend using a Java profiler to see where the bottlenecks are. It's probably going to be something weird that no one could have guessed would be the culprit in advance.

    Leave a comment:

Working...
X