session_start() with long wall time.

  • Hello,

    I’ve taken over development of a site that uses Ninja Firewall, and was asked to improve performance of the site. On profiling with xhprof I’ve witnessed a strange behavior. If multiple requests came into the site in a short succession there was a ramp up for session_start(), which was only triggered by nfw.

    Upon opening a post in the editor, easily 20 requests and more are fired in short succession, which results in quite a delay in the later requests. While the first ones were fast as expected, in the later ones I’ve seen a ramp up of session_start() to up to 8 seconds, while the total execution time was just 9s.

    I’ve benchmarked Ninja Firewall against other WAFs and none of them had this ramp up.

    To my question:

    Is there any Webserver configuration I can do, in order to prevent this behavior. Or maybe could you guys replace the use of session_start() with something else, since barely any software in the WordPress eco system utilizes session_start() and when I started doing WordPress Plugins, I was told it is considered a bad practice in WordPress.

    Thanks in advance.

    • This topic was modified 5 months, 3 weeks ago by Christoph Daum. Reason: Typo
Viewing 3 replies - 1 through 3 (of 3 total)
  • Plugin Author nintechnet

    (@nintechnet)

    Do you see any warning or error in the “Tools > Site Health” page ?
    Could you paste here the list of your plugins/theme that use PHP sessions ? You can scan the whole /wp-content/plugins and the main theme folder, and search for session_start.

    Thread Starter Christoph Daum

    (@apermo)

    The list of my plugins/themes that use PHP sessions is easy. It’s just Ninja Firewall.

    I’ve found a quite old Stackoverflow post that pretty much resembles what i’ve measured.

    https://stackoverflow.com/questions/13772074/session-start-takes-very-long-time

    I for sure could try to convince our hosting team to provide a different method for storing the sessions, so that it would no longer be blocking. But that will still leave most other sites using Ninja Firewall unattended.

    The issue where I ran into a problem is within the editor. It’s not unusual that you’ll have 10-30 requests to the internal API when using the editor in short succession. And if session_start() is still blocking in PHP, it will result in ramping up of loading times, since the amount of parallel execution of api requests for one editor is limited.

    So let me rephrase my initial question to:

    Could you please forward this to your development team and try to figure out a way to remove the use of session_start() in order to speed up Ninja Firewall ??

    If any of your developers is in Turin next week, I’m happy to discuss that in person.

    Plugin Author nintechnet

    (@nintechnet)

    We can’t replace session_start as that would require to rewrite the whole plugin.
    There’s no problem to run 50 or 100+ HTTP requests with NF, many applications use session_start without any issue as well (Magento etc). But in your case, there’s a problem/conflict with an application (plugin or theme) and, due to the way PHP sessions work, it hangs and subsequent requests are queued. You would need to find which plugin/theme it is:
    * With a profiler: disable NF from the plugin page and, if it was loaded via the PHP INI file, comment out the auto_prepend_file directive as well. Then run the xhprof or xdebug.
    * Without a profiler: keep NF enabled, disable your plugins one by one and, each time, open/edit a post to see if it is still slow or not, until you find the right plugin. Don’t forget to try to switch the theme too, as it could be it.
    As soon as you narrow to one plugin or theme, tell me which one it is and we’ll make some tests to see what’s going on.

Viewing 3 replies - 1 through 3 (of 3 total)
  • You must be logged in to reply to this topic.