View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0025497 | mantisbt | public | 2019-02-19 17:35 | 2019-02-24 06:49 | |
Reporter | ChrisG | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | new | Resolution | open | ||
Summary | 0025497: Optimize send_emails.php performance | ||||
Description | send_emails.php is called up as a Cronjob, meaning on most servers it will not benefit from Opcode caching. According to my profiler, it is loading up 76 PHP files and taking around 8 seconds to do this. If it is running every minute, that is a very significant overhead on the server. Now, the 8 second time figure may be exaggerated based on some server performance issues I am currently chasing, but it's still a lot of work on a routine background task that is just sending emails. I realize to get this down it will require some heavy restructuring of how the bootup process is working within Mantis. | ||||
Tags | No tags attached. | ||||
I assume that missing opcode caching is not the root cause of the performance issue. Independent from that, you could try if performance is better when using the default |
|
For 0 emails in that table, all the following .php files have to be parsed (I just hacked the code to spit out a list)...
So that's the problem really. With opcode caching it would be less of a problem, but even with, that's a lot of code to call up every minute. The problem with sending out emails in realtime is if there's a lot, you can get a real lag problem. That's why I had to enable the mail queue. |
|
Here's a hackerish patch...
I suppose it would not hurt to merge something like that, given the alternatives are leaving the inefficiency or heavily restructuring the code. |
|
I'm not denying your point, but: How many files are parsed for a typical page view from a user? |
|
Right, yes. There is some nuance to this. It shouldn't hurt a server if an opcode cache is there. If an opcode cache is there, it can well be the case that parsing that much PHP and doing that many disk I/O operations every minute could cause very spiky behaviour, especially with a low number of cores and/or an unimpressive HDD with poor disk caching. So my point about opcode caches not being configured for CLI is key to the understanding of priority here. It really can be very surprising how much lack of an opcode cache can change things. Regarding opcode caching not being on - I can say for Zend Opcache by default it is totally disabled for CLI (opcache.enable_cli=0), and is configured to use shared memory which only works for a memory-resident PHP context (like mod_php). It can be configured to be enabled on CLI, and to use a disk-based backend (MMAP), but that's not the default and usually won't be configured. |
|
What's the reason to run it every minute?
Did you try with latest version, or is it an observation when using older MantisBT versions? Concerning
There are hardly any use cases where a lot emails are sent as a result of a single page request.
This is what I see when running latest MantisBT using PHP 7.0.32 on Ubuntu 16.04, using a pretty cheap hosted virtual system.
Your system can hardly be 64 times slower than my test system, assuming you are not using a Raspberry Pi 1 like this user 0025121. Don't you think there could be some configuration issue on your server? To avoid comparing apples to oranges, can you try with MantisBT 2.19.0 or latest code from master branch? |
|
Thanks for the help guys :). "What's the reason to run it every minute?" - I like the responsiveness, but I probably didn't even think about that or properly read the docs TBH lol. It is correct to point out my server has some issues. That's why I went down the rabbithole of installing tideways-xhprof on there and having everything benchmarked over a day or so. Basically I think my machine was doing a lot of page swapping which was slowing processes, and disk reads, down - it had a decent amount of free RAM, but I think Linux wanted to keep that RAM free by preemptively moving less important stuff in and out of swap. I did a tonne of optimization, but reconfiguring the FastCGI settings and reducing the overhead of some other processes has helped most. I have now cleared that issue, and this is what I am currently getting:
So, far better. A little worse than what you're getting, but certainly very tolerable. However... It is a reality some people are going to be on crappy server situations. Over the years I've seen countless very stressed servers provided by webhosts. Imagine a user with:
That's more the reality for some people. Now, to be honest, that's more of an argument to optimize the requests that are coming in thick and fast, rather than something running just every 1 or 5 minutes. I realize this isn't a major or pressing issue, but if someone has the time I do think it's worth looking at at some point. Regarding register_shutdown_function... This can be problematic for a few reasons: TBH I don't want to start tinkering with my configuration again as I just lost 3 days unexpectedly wrestling my server back under control and am seriously behind - sorry about that. It may well be that the speed your sending out these emails now is fast enough that it's barely noticeable even when sending dozens. I'm happy with things as they are right now with the Cron script. |
|
From my experience with other profiling tools I expect this added a lot of overhead and influenced performance a lot more than any other topic we discussed before. |
|