Symphony.

I've built a mini-site in Symphony 2.3.3 that allows Garage Bands to subscribe and collect votes for a competition.

The problem is it's got very popular and I probably failed at arquictural planning so I'm rather concerned that the number of entries will overload the server as they are growing fast already and causing various performance issues.

At the time there is a "Votes" section that contains 2 select box links (pointing to a user section and a band section) that has grown to 14k entries and is starting to fail load (in the Admin), showing up a 500 error sometimes. (I've limited pagination on config to 50 entries per page)

It also causes a performance hit on the frontend as I need to ds chain it with bands (ds.band.system.id) to show the list of top voted bands. At the time the ?debug view no longer is loaded since it probably can't process all the information in the xml (altough it only really lists the ~300 bands, the votes are filtered by band entry id)

So here are my questions:

1 - How can I improve page load and avoid the problems I'm having showing the entries in the Symphony Admin

2 - How can I improve the frontend xml processing since I cannot cache the datasource (users need to see their votes beeing counted as they vote for the chosen band)

Thank you in advance!

• Which version of Symphony are you currently using?
• Regarding debugging: does ?debug=raw work for you?

Symphony version is 2.3.3. I've had problems with some extensions in the 2.3.5 version so decided to run with this one as it has been from my experience the one with less conflicts (needless to say that due to the number of extensions I have installed I would be terrified to update at this point).

?debug=raw does work ;) Thank you for that. Didn't remember to use it before.

This leads me to another question: Is there a way to filter output parameters. At this point it seems it's listing the id's for all the bands (instead of just the published) Aditionally it seems to be duplicated as in ds-bands and ds-bands.system.id

Thank you

Sorry just confirmed that the ds-band list is in fact filtered. Only the published bands are actually beeing outputed to the parameters pool.

I'd say, your first step should be looking at ?profile to check which Data Sources are causing long page loading times.

Every Symphony setup is different, so there is no simple solution like "do this and your problems will be gone". If you'd like to get further input here, please post more details about your setup and your site in general.

The band-list data source is the one possibly creating the fuss. At this point it takes up 11 MB of memory, clearly ahead of the competition.

The band list data source lists all the published bands and outputs its system id so I can filter the votes once a user is logged in only (data source votes only outputs results if a user is logged in so I can corss reference is a user already voted for a band and wich). Votes listed on the bands themselves for purposes of showing data (for both logged and logged out users) comes from the "count associated entries" checkbox on the band-list data source.

My main concern at this point is really the list of Votes in the Symphony Admin as it lists every vote with the 2 associated relations (band and user) and seems to be giving in under the weight of its 14k + entries (showing up a 500 error at some requests).

I think 11Mb for a single datasource is a massive problem.

Some advice would be to limit the output of the band-list datasource to as little as you need for the display.

I usually do this, and then have a method to display more with an ajax call for inline display or another page, which then polls another datasource with more information, but a single entry. This may mean more http requests in the long run, but it lifts the load, and makes them when the visitor wants to.

Another method is to use pagination to really limit the number of results being returned in one chunk.

Caching works best (I have no experience though), but a problem there is that if any part of your page has dynamic properties (like displaying a logged in username) it will break your site.

Also, What is your server's memory and processor like? 14k entries in the admin shouldn't kill the page if PHP is set up properly, and you have enough system resources available.

Those are some good ideas, speacially the aditional ajax requests to pull the data source as required. I'm also starting to believe I don't really need to uotput ds-band system.id to the parameters as it only really matters once the user is logged.

Problem is, there is actually no pagination on this list as it is lazy loaded on the frontend and requires that everything is already in place on page load relating to data.

PHP has memory limit of 256 MB. Altogether the full page Memory allocation is 20 MB tops (on the frontend).

Is there anyway I can control a single data source output on the backend? I was imagining I could tweak the Votes datasource on the symphony admin so it became a bit more performant.My main concern right now is not so much as the Front End performance (altough that is becoming a concern too...11 MB :( ) but more the inability for the client to see the 14k entries on the Admin.

Thank you for the help guys.

Redrazor after reading through, first and foremost see if you can stop the datasource from loading when a user is not logged in. You should be able to use something like $member-id. Other then that you could look at customizing it to improve a bit more performance.

As regards the backend I believe you could/should use some pagination I'm not sure if you have this enabled in the backend.

I have pagination, 50 entries per page.

I also have the publish filtering extension active to filter entries as it is needed to search through all this data. Not usre how much of a performance hit that generates but its bound to be some, specially in a Section with 2 select box links.

Is there anyway to tweak result pages for Symphony admin individually?

Publish Filtering is only providing an UI for the core backend filtering so this extension should not impact your backend performance. Your bottleneck are the SBL fields and the enormous amount of data they have to handle.

Does it help to not display the relationships in the backend?

No, because that is the only information that is captured and that matters. What user voted in what band. Even if it helps it must be outputed.

Actually, Publish Filtering will have an impact as it will try to create a dropdown with all available options for you to filter off.

What is your section setup, Bands, Users and Votes section? Votes has SBL to Band & User?

Actually, Publish Filtering will have an impact as it will try to create a dropdown with all available options for you to filter off.

But it only contains the last 20 entries.

Nils: It actually contains all the emails in the dropdown as requested by the client (I did warn him tough) and this is my greatest bet at the moment regarding performance on this section

brendo: Yes, just like you described

If you've got 14k entries coming through in the backend, that's definitely going to bring your performance to a halt. How are they using the email address field? Can they search in the Users section by email address and then link through to the Vote that way?

No they can't. That's what I meant with "...and I probably failed at arquictural planning so..." :)

There is no relation pointing from users to Votes, only the other way around.

Users area laready 19k tough...but not as heavy on the processing since they lack SBL

If you had a Select Box Link on the Votes section, you can always get the number of related votes to show on the entries index of the Users section by enabling 'Display relationship in entries table' on the Select Box Link.

This will then allow you search on Users by email address, and then on the table view, link through to a filtered list of votes from this User.