Title: allocatedspace's Replies | WordPress.org

---

# allocatedspace

  [  ](https://wordpress.org/support/users/allocatedspace/)

 *   [Profile](https://wordpress.org/support/users/allocatedspace/)
 *   [Topics Started](https://wordpress.org/support/users/allocatedspace/topics/)
 *   [Replies Created](https://wordpress.org/support/users/allocatedspace/replies/)
 *   [Reviews Written](https://wordpress.org/support/users/allocatedspace/reviews/)
 *   [Topics Replied To](https://wordpress.org/support/users/allocatedspace/replied-to/)
 *   [Engagements](https://wordpress.org/support/users/allocatedspace/engagements/)
 *   [Favorites](https://wordpress.org/support/users/allocatedspace/favorites/)

 Search replies:

## Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)

 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[The Events Calendar] Unoptimized; DoS risk.](https://wordpress.org/support/topic/unoptimized-dos-risk-2/)
 *  Thread Starter [allocatedspace](https://wordpress.org/support/users/allocatedspace/)
 * (@allocatedspace)
 * [1 year, 11 months ago](https://wordpress.org/support/topic/unoptimized-dos-risk-2/#post-17831045)
 * Hi,
 * Any updates?
 * It’s causing CPU issues. The WordPress database shown below has 2,128 `tec_occurences`
   records.
 * ![](https://i0.wp.com/i.ibb.co/yWJWZW2/processes.png?ssl=1)
 * ![](https://i0.wp.com/i.ibb.co/JnZ9vTn/Screenshot-2024-06-17-at-12-59-47-PM.png?
   ssl=1)
 * —
 * The issue was resolved by disabling The Events Calendar plugin and terminating
   the two persistent `tec_occurences` MySQL queries, as shown below:
 * ![](https://i0.wp.com/i.ibb.co/5G89PcV/disabled.png?ssl=1)
 * While server-side full-page caching dos help, it only does so conditionally, 
   and so it’s not a final solution in reducing the high CPU usage caused by inefficient
   The Events Calendar table scans.
    -  This reply was modified 1 year, 11 months ago by [allocatedspace](https://wordpress.org/support/users/allocatedspace/).
    -  This reply was modified 1 year, 11 months ago by [allocatedspace](https://wordpress.org/support/users/allocatedspace/).
      Reason: formatting
 *   Forum: [Plugins](https://wordpress.org/support/forum/plugins-and-hacks/)
    In
   reply to: [[The Events Calendar] Unoptimized; DoS risk.](https://wordpress.org/support/topic/unoptimized-dos-risk-2/)
 *  Thread Starter [allocatedspace](https://wordpress.org/support/users/allocatedspace/)
 * (@allocatedspace)
 * [2 years, 1 month ago](https://wordpress.org/support/topic/unoptimized-dos-risk-2/#post-17724966)
 * Hi Gustavo Bordoni (@bordoni),
 * Nice, that sounds great.
 * Sure, just let me know when you’ve made any changes, and I’ll update and note
   the update time accordingly. I’ll keep an eye on CPU usage for multiple sites
   by monitoring a database CPU utilization histogram to determine if there is a
   noticeable difference. Each site has a few thousand tribe_event records.
 * If your update adds an index to the joining columns (wp_tec_occurrences.post_id)
   and handles dates and times as DATETIME types rather than VARCHAR, it should 
   improve performance because of fewer table scans for joins and less effort (CPU
   time) in queries that were type casting VARCHAR to DATETIME, especially where
   the type casting of VARCHAR to DATETIME was occurring in the WHERE clause (which
   also causes another table scan, since that column as a VARCHAR cannot benefit
   from an index in the way it’s being used, whereas DATETIME data is stored as 
   8 bytes, with the first four representing the date, and the last four representing
   the time, and this format can benefit from a B-Tree index, allowing efficient
   lookups based on datetime using MySQL’s date and time functions (or LT and GT
   operators). It’s likely to make a noticeable difference. Looking forward to it.

Viewing 2 replies - 1 through 2 (of 2 total)