Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Customising the CMS /

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Performance Concerns with secured assets


Go to End


1374 Views

Avatar
p0lar_bear

Community Member, 7 Posts

18 March 2016 at 4:34am

Edited: 18/03/2016 4:41am

I'm working on a Silverstripe-based site in which one of the requirements is that users that haven't been authenticated cannot see the contents of a subfolder of the assets directory. The concept is easy to grasp and I have an implementation loosely based on the secureassets module, however as the module's documentation warns, using Silverstripe as an assets gatekeeper causes a performance hit. The performance hit is especially noticeable since some of the secured assets are self-contained web-based applications in development, so the web apps haven't been fully optimized yet. This means multiple round trip requests to load scripts, images, etc.

Without the gatekeeping in place, chrome's network tools report an average waiting/TTFB of 1.5ms, and turning it on results in 500ms waits. What i really don't understand though is that xdebug profiling shows Silverstripe's execution time to be a mere 54ms to go through the motions of bootstrapping and passing the request off to my logic in the controller, so I'm assuming that the extra 450ms wait is PHP starting up.

This approach is tolerable as a zero-version stopgap/proof of concept, however the performance hit is unacceptable for the long term. I will agree that optimization of the web application assets will help and it should be done, but I cannot guarantee that people will upload optimized packages to the site (you can lead a horse to water...). I'm not quite sure where to begin looking for a solution to this issue. I mean, is there a way to verify a user's authenticated session without going through Silverstripe (or to talk really crazy, without touching PHP)? If I'm stuck dealing with PHP/SS for this, is there any method I'm unaware of that will mitigate the long wait for even a response header to be sent?

e: Once again I come to a realization shortly after I post that my instance of PHP has debugging enabled and I remember seeing warning in practically anything PHP-based that xdebug causes performance issues. I'll turn it off and see what it does.

e2: Well that helps but then again not really. Average TTFB went from 500ms to 285ms. A little better but still not acceptable going forward.