Symphony.

Hi all, excuse me if I can't explain my problem clearly, I have been using Symphony for a good few years but I'm still a bit of a Novice. I have searched the forums but can't find anything like this there so far.

I recently moved a working Symphony site over from a VPS to a dedicated sever and now I'm having a problem when querying larger datasources.

What happens is, for instance when I paginate a particular datasource to say 100 entries, it works fine, but then changing that to 130 (or removing pagination) results in the following <xsl:choose> coming out as false. When I check in ?debug though it clearly shows that that it should be true. Because of this it jumps to the <xsl:otherwise> which as it happens is a log in page.

<xsl:choose>
    <xsl:when test="/data/events/member-login-info/@logged-in='yes' and ($member-role='Admin' or $member-role='Limited Admin')">
.......

If I change the "test" condition to something like "1=1" it comes out as true but then fails to render the linked template (it only renders the master template).

So it appears that a larger query is interfereing with the page / templates and or page params.

I really apologise for the vague information. I have been using symphony for some years and have found a lot of help here in the forums, but this one has me stumped!

Any help would be amazing!

Total Database Queries 6340 Slow Queries (> 0.09s)0 Total Time Spent on Queries 0.6536 s Time Triggering All Events 0.0000 s Time Running All Data Sources 0.0000 s XML Generation 0.0175 s XSLT Transformation 0.0000 s Output Creation Time 0.0000 s Total Memory Usage 11.71 MB

Does that Total Memory seem way high or is it just me?

Memory Usage

Engine Initialisation 0 bytes FrontendDevKitResolve: debugdevkit 26 KB FrontendDevKitResolve: profiledevkit 197 KB Page creation started 0 bytes FrontendPrePageResolve: maintenancemode 50 KB FrontendPageResolved: members 1.36 MB FrontendParamsResolve: maintenancemode 7 KB FrontendParamsResolve: members 41 KB FrontendParamsResolve: xssfilter 44 KB FrontendProcessEvents: members 4 KB Event: deletemodels 69 KB Event: storageaction 1 KB DataSourcePreExecute: associationoutput 132 KB DataSourcePreExecute: orderentries 47 KB DataSourcePostExecute: associationoutput 9.58 MB Datasource: activepaidmodels 0 bytes DataSourcePreExecute: associationoutput 5 KB DataSourcePreExecute: orderentries 1 KB DataSourcePostExecute: associationoutput 25 KB Datasource: adminuser 0 bytes XML Built 0 bytes FrontendParamsPostResolve: useragentdetails 31 KB Page Built 30 KB XML Generation 0 bytes FrontendOutputPostGenerate: memberlastvisit 46 KB XSLT Transformation 0 bytes Page creation complete 328 bytes ManipulateDevKitNavigation: debugdevkit 21 KB ManipulateDevKitNavigation: profiledevkit 1 KB

If I need to include any more info, please let me know.

Thanks in advance.

sorry will post a screenshot

Maybe it's a PHP and/or webserver max memory setting thing?

Hi David, thanks for your response. I have already adjusted the php.ini just to test and it's still doing the same.

maxexecutiontime = 60

maxinputtime = 60

maxinputvars = 1000

memory_limit = 500M

Do you know if there could there be any other server settings doing this?

Thanks

I've noticed that its happening when the Total Memory Usage in the Full Page render Statistics goes beyond 12MB, but I can't work out where this limit is imposed.

Does anyone have an idea?

• PHP memory_limit = 500M

Did you restart PHP (if using FCGI/FPM) and the webserver (e.g., Apache) after changing the PHP settings?

How long does the response take to be returned?

Hi David, thanks for your help. It was strange as the response was taking a few seconds. I finally worked out what was causing it. I had previously added the following line of code in after having some issues with libmxl 2.9.2:

libxml_use_internal_errors(TRUE);

After removing that, the page loaded fine. Problem solved.

Thanks again.

Interesting. I wonder why using that gives rise to that issue.

Glad you figured it out.