Query time is high

[Yudhi DarmawanParticipant]

This plugin is working at my website. The only thing which bother me is its speed. In your demo its working fast. But for me it working so slow. Enable caching options help just a little bit. My website only has 6MB database, but it load so slow. Especially new keyword, but your website works great.

Do you know why? Currently I cannot give access to my admin area. Because I believe its nothing to do with admin settings. Its only in default settings.

I felt this nothing to do with your plugin but my server.

I need your view.

here is my PHP info: http://www.bezbay.com/sugar_info.php

I give you full benchmark from my VPS (CPU, MEMORY, DISK and MYSQL), I felt nothing wrong with its results.
My system PHP. 5.5/WP-4.3.1 with PHP5-FPM cache

Here the results with all service still running. I found nothing wrong with its speed. (perhaps just disk I/O a little bit lower)

Sysbench Results:
CPU:sysbench –test=cpu run
Test execution summary:
total time: 15.9467s
total number of events: 10000
total time taken by event execution: 15.9420
per-request statistics:
min: 1.35ms
avg: 1.59ms
max: 11.12ms
approx. 95 percentile: 1.76ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 15.9420/0.00

Memory (Read):sysbench –test=memory run
Operations performed: 104857600 (1605170.36 ops/sec)

102400.00 MB transferred (1567.55 MB/sec)

Test execution summary:
total time: 65.3249s
total number of events: 104857600
total time taken by event execution: 51.8100
per-request statistics:
min: 0.00ms
avg: 0.00ms
max: 43.21ms
approx. 95 percentile: 0.00ms

Threads fairness:
events (avg/stddev): 104857600.0000/0.00
execution time (avg/stddev): 51.8100/0.00

Memory (Write):sysbench –test=memory –memory-oper=write run
Operations performed: 104857600 (1817882.22 ops/sec)

102400.00 MB transferred (1775.28 MB/sec)

Test execution summary:
total time: 57.6812s
total number of events: 104857600
total time taken by event execution: 45.7893
per-request statistics:
min: 0.00ms
avg: 0.00ms
max: 12.59ms
approx. 95 percentile: 0.00ms

Threads fairness:
events (avg/stddev): 104857600.0000/0.00
execution time (avg/stddev): 45.7893/0.00

File I/O: sysbench –test=fileio –file-total-size=4G –file-test-mode=rndrw run
Operations performed: 6000 Read, 4000 Write, 12800 Other = 22800 Total
Read 93.75Mb Written 62.5Mb Total transferred 156.25Mb (33.032Mb/sec)
2114.02 Requests/sec executed

Test execution summary:
total time: 4.7303s
total number of events: 10000
total time taken by event execution: 0.1164
per-request statistics:
min: 0.00ms
avg: 0.01ms
max: 1.04ms
approx. 95 percentile: 0.02ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 0.1164/0.00

MySQL: sysbench –test=oltp –oltp-table-size=1000000 –mysql-db=test –mysql-user=root –mysql-password=password run
OLTP test statistics:
queries performed:
read: 140000
write: 50000
other: 20000
total: 210000
transactions: 10000 (227.21 per sec.)
deadlocks: 0 (0.00 per sec.)
read/write requests: 190000 (4316.94 per sec.)
other operations: 20000 (454.42 per sec.)

Test execution summary:
total time: 44.0126s
total number of events: 10000
total time taken by event execution: 43.9450
per-request statistics:
min: 2.46ms
avg: 4.39ms
max: 1969.09ms
approx. 95 percentile: 4.88ms

Threads fairness:
events (avg/stddev): 10000.0000/0.00
execution time (avg/stddev): 43.9450/0.00

[Ernest MarcinkoKeymaster]

Hi,

It’s probably not related to the actual search process, but either a post process step or additional processes running with the ajax request.

In WordPress when an ajax request is executed first WordPress core is initialized, then it loads every plugin cores then goes through the list of the registered ajax handlers. The problem usually is caused at the step where the plugins get initialized. Some plugins check at the beginning of their execution if the current call is within an ajax request, and only load the absolutely necessary codebase – but most of them not. This can cause a huge delay.

The sysbench looks all right to me, but it does not mean that there shouldn’t be any hold-ups within ajax requests.

Please check out the Performance Tracker section of the documentation. I’ve built in a basic process measurement tool to the plugin to check how long the search process actually takes. If the Average Request Runtime is considerable lower than the actual response on the front-end, then it means that something else is clogging up the ajax request. (wordpress core loading, plugin loading and code execution etc..)

There is also a chapter about Fine Tuning the search Performance, where you should find a few tips about performance related improvements.

If the Average Request Runtime is high on the performance tracker, then let me know. If you can work out an FTP access, I will gladly do a debugging to find which part is actually causing the delay.

Best,
Ernest Marcinko
If you like my products, don't forget to rate them on codecanyon :)

[Yudhi DarmawanParticipant]

Thank you very much for your explanation. Now I can find the problem in right way.

your below statement is very helpful. Add to my knowledge.

“In WordPress when an ajax request is executed first WordPress core is initialized, then it loads every plugin cores then goes through the list of the registered ajax handlers”

CASE CLOSE, Thank You

[Author]

Posts