Description

Change History

It needs to be removed from the help file. The charts are too dynamic to cache... and until I see a benchmark showing that the charts are responsible for too much server load, I'm not going to worry about the performance. "Permature optimization" and all that. :)

It goes beyond server load issues, really. Dynamic chart generation is painfully slow. On my lightly-loaded servers here, generating one pie chart for the stats page adds about 5 seconds to the load time for that page, which becomes quite tedious. Now imagine adding more than one chart to a page, and it becomes even less bearable. I think the only way this feature is going to become practical is to implement scheduled static chart generation.

It's not that difficult to do, frankly. The same PHP scripts that now generate the dynamic charts can be called from the command line, modified only slightly to output their images to files. The chart_stats.php script would output to, say, chart_stats.png, which the stats page would load as a static image. As long as the charts all have an As of: time and date displayed, it should be clear to viewers that the stats are generated hourly (or at some other fixed interval).

Just an observation. Sorry if I'm mistaken or uninformed. It seems to me the potential for waste is there either way. Either create them dynamically and risk server load due to frequent generation, or have a sript frequently generate them (for potentially thousands of users) when there may be only a few users actually viewing them. I think you loose either way, but given the choice, my hunch would be the load would be less if they are created dynamically.

A valid point, Gary, and I confess that I was mainly thinking about system-wide stats, not per-user stats.

That said, even with per-user stats, charts would only be auto-generated for those users who specify that they want graphical charts in the first place (no sense generating charts for users who don't want them). You'd also want to adjust the chart interval to account for the number of users this entails--at 5 seconds/chart, you can only generate 720 charts/hour (17,280 charts/day), so you might opt for chart updates just once a day if you've got a large number of users. At sites with tens of thousands of users, it might even be necessary to make the stats a once-a-week process.

For batch-generation of charts, there's probably also a faster way to do it, too, perhaps using a different tool (e.g. Perl-based modules, ImageMagick, etc.), such that the 5-seconds-per-chart figure can be dropped down fairly dramatically. I suspect the overhead of PHP is largely to blame for that, in which case getting the job done outside of PHP may speed things up considerably for static batches.

There may be a way to trade this off, however. Just as we offer users the ability to enable/disable charts from their Settings pages, we can offer them the choice between dynamic or static charts. If they choose dynamic charts, they suffer the load-time delays, but they at least get up-to-the-minute data. If they choose static charts, they get fast page-loads, but with the understanding that the charts will contain somewhat dated information.

Maybe the frequency of auto-generation (in hours) could automatically be adjusted according to number of users that use the feature and length time it took to perform the operation. Kick it to once a day and bias it toward early morning for sites that are near the "once a day" mark. This might prevent 17,000 users from selecting "Each Hour" (or the admin doing it for them with an SQL command) and unwittingly DOSing the machine. Just stuff to consider. Seems to me it should be a system-wide operation. I'm not sure how you would control it otherwise.

Oh no, the users would not be allowed to specify their own chart intervals--that's got to be a system-wide setting. If the user chooses to see static charts rather than dynamic ones, he's forced to view the charts that were generated during the most recent system-wide interval.

That should be the end of ticket spam. Creating, modifying and commenting on tickets now requires a registered login that I have to generate for those who want one. Sad that it came to this, but on the plus-side, it means we won't see any more tickets and comments from "anonymous" individuals.