Fast Lane!

Just to chime in on "monetization" (which I hope we all agree is important). I was over at Google the other week for a publisher meeting and the topic came up. BLUF, PWAs are challenging to monetize well. In the end, this is a serious consideration for any publisher and not something to be ignored (or risked) chasing trends. They were supportive of PWA but urged caution.

I think IP Pages should have an option to allow AMP pages. That or at least allow a customer header element to point to an alternate AMP page manually. The Pages product directly competes with WordPress which has this already. Be the way. I totally am not a fan of a stand alone web app. It would likely leave out a TON of my community built around IP Pages and custom areas. Folks would not discover them on the app. Also, advertising revenue and customization would take a huge hit.

Did you have any issues migrating over? I'm about to migrate... and a little concerned on the DNS migration and their cloudflare backend.

How does monetization work with PWA? Many forums earn the bulk of their revenue through banner ads throughout the site. Will this be impacted?

Hi all, if this app places members into a validating status, will their account be deleted if they don't validate? I have the "remove unvalidated accounts" setting at 15 days. This was to delete folks that register but never confirm -- I worry it may nix valid accounts that have old emails and are flagged by this tool. Is there an issue?

Scary. This is why I generally wait a few point releases to upgrade. Sounds like many bugs are abound on 4.3 which isn't surprising for a large update.

FYI if this helps... from a large community.

One of the things I noticed too (and I changed on my board for speed) was that members with larger post counts took longer to run this series of queries on. In 2.3.x (not sure on 3.x) The order of queries is, 1) Select count(*) as count, 2) Select data (with joins) then sort based on post date (desc) and then limit xx,25 (where xx is the page you want to view (0 page 1, 25 page 2, ...). I noticed that the select count(*) statement for users that have a lot of posts took a LONG time compared to the regular select/join/order/limit statement after it. The "count" is only required so you can calculate the number of "pages" to show. I thought there was more to it but that is it. It was such a resource intensive step for some of my members that to basically double the speed of this query I eliminated this query and hard coded 250 posts (which has the effect of populating 10 page counters even if there are not enough posts). I post a line in the search results saying "Last 250 posts are shown. Some pages may be blank if the user has less than 250 posts in the last xx days." Long story, I am not sure my method is really a good one. I would love a better idea. The important part is the realization that the "count" query was up to 50% of the total query time overall. Sometimes more! This simply to get the page count. There must be a more efficient way? If so we can potentially save 50% of the total query time which on a large board causes massive table locks on the post table (effectively taking the message forum offline as queries on the post table queue up on the locked table). Thoughts? I see some potential here for big gains. My only other thought was simply query on the user post count but for many reasons that is not always accurate over time.

I just thought of another improvement that may make this "more smart". I will probably code this up for my board shortly... I will go and first query the "last active" date which is a trivial query (work and time wise). I will then back date the "30" or XX days prior to that. This way members that have not been active in a while (and have the find all posts query run on them) will still get results returned. I will report my results EDIT: Also the "find my last 10 posts" query can have the time limit portion added too. It basically right now finds ALL your posts and then performs a sort and limit. Reducing the query using the post_date index should help as well.

Awesome. A quick flag in the ACP to turn on (with date limit) would work. Even a flag in the source code with a variable time limit (that people can adjust) would work. I understand lesser active boards do not need this but for the larger ones the MYSQL query "as is" is pretty intensive when sorting through years of posts in a (in my case) > 5 GB table.

@IPB Staff, can you please consider adding this as a large board speed option in the ACP. It REALLY reduced the server spikes on my server which is a RAID 10 box with dual quad core xeons. If I was affected and needed this then I know other people are too.

For the record you need to also edit this function (just realized this needs posted sorry): function search_get_all_user_query( $a ) { $time_restrict = "p.post_date > " . ( time() - 60 * 60 * 24 * 30 ) . ""; return "SELECT p.*, t.*, t.posts as topic_posts, t.title as topic_title, m.*, me.*, pp.* FROM ".SQL_PREFIX."posts p LEFT JOIN ".SQL_PREFIX."topics t ON (t.tid=p.topic_id) LEFT JOIN ".SQL_PREFIX."members m ON (m.id=p.author_id) LEFT JOIN ".SQL_PREFIX."member_extra me ON (me.id=p.author_id) LEFT JOIN ".SQL_PREFIX."profile_portal pp ON (m.id=pp.pp_member_id) WHERE t.approved=1 AND t.forum_id IN({$a['forums']}) AND p.queued=0 AND p.author_id={$a['mid']} AND {$time_restrict} ORDER BY post_date DESC"; } The speed up is real and is FAST! You can replace the "30" day limit to anything you want. Long is slower but if you have a database spanning several years this will improve the MYSQL query time dramatically if you limit it to any fraction of that.

The main issue I found (after exhaustive log digesting and research) is that the "Find all member posts" mysql statement is SLOW as heck with large post tables (large forums with lots of posts). It also is even slower when run on members that have LOTS of posts. Despite indexing it is SLOW... like five minutes slow sometimes. The change I made below is similar to other methods I suggested (and IPB integrated into the mainline code as large board optimizations) previously. If the place I made the change is not "preferred" then I am sure another location can be found... So what did I do? Basically you can restrict (in this case 90 days) the amount of posts to find back in time. Because the "post_date" column is indexed the search goes from slow to SUPER FAST because it allows a large reduction in the data set. @IPB: Since you support 2.x still any chance to get this into a baseline (or in 3.x)? I am holding out myself for a few more minor rev's on 3.x to shake out most the early bugs/security issues any new release has. forums/sources/sql/mysql_quesries.php was: function search_get_all_user_count( $a ) { return "SELECT count(*) as count FROM ".SQL_PREFIX."posts p LEFT JOIN ".SQL_PREFIX."topics t ON (t.tid=p.topic_id) WHERE t.approved=1 AND t.forum_id IN({$a['forums']}) AND p.queued=0 AND p.author_id={$a['mid']}"; } is: function search_get_all_user_count( $a ) { $time_restrict = "p.post_date > " . ( time() - 60 * 60 * 24 * 90 ) . ""; return "SELECT count(*) as count FROM ".SQL_PREFIX."posts p LEFT JOIN ".SQL_PREFIX."topics t ON (t.tid=p.topic_id) WHERE t.approved=1 AND t.forum_id IN({$a['forums']}) AND p.queued=0 AND p.author_id={$a['mid']} AND {$time_restrict}"; } code execution time is now way less (from 5 minutes sometimes on my board to seconds).

Simply make sure that IPB can be accessed via a BlackBerry (not very well right now). Sorry.

I agree. I am waiting on Cleancut and the "Active topics" and "New Topics Since last Visit".

I forgot! When IPB did some upgrade I ended up with two accounts. Here is my above 100 post account :P . Note it is me above.

Obviously you will support PHP 5.3 but I just wanted to get some official feedback that you will be officially supporting the newest revision (to be released in the near future -- before IPB 3.0 Final.

One of the "slowest" IPB queries is the member profile page when people view the tab to see a members recent topics/posts. The MySQL Select statement (even with indexing) takes some time on a large DB with lots of members. My suggestion to reduce this is to add a little "up front" work to reduce these query loads. Basically I am suggesting adding two columns to one of the tables (members, members_extra, etc.) that contain the last ten topics/posts the member has posted. The list could be in a single cell (comma separated list) and easily loaded with a single query. PHP can then explode the list and treat it as a FIFO and add a new post / topic ID and remove the old. Then when you need to load a persons recent topics/posts you simply load this list, explode it in PHP and then load only those topics with mysql. It is much less CPU intensive to do this and only adds minor upkeep/load on the front end. It is similar to the concept of AJAX / XML where you use some continuous and predictable loading to prevent irregular and heavy loads that you can not predict. Thoughts? I know this would help me (5-6GB database for my largest site).

Unless that 15% is on a work PC or other IT controlled PC where they can not.

It does add a burden, but luckily that burden is self imposed. People can choose not to utilize this compatibility at all... I would certainly rather have the option to do something then not have the option at all :).

Two IPB style sheets would at least give a stop gap. We could put a notice on the IE6 style sheet that their current skin does not give them all the features of the newest browsers, but instead gracefully falls back to IE6 compatibility. Hopefully we can assign that style sheet to be used based on detecting their browser (an option in the IPB Control panel to "check" for IE6 and assign the skin?). As time goes on we as webmasters can simply (when the time is right) drop the style sheet and migrate everyone over to the new 3.x style sheet. We would turn off the IPB Control panel option (for IE6 legacy browser detection). This allows the webmasters to control when "their" customer base is forced to have the new skin. For all of us our member base probably varies on the percentage of people on IE6 but this at least gives us the option and control of when this happens. Thank you for the help if you really can make this happen!

A good read on people's opinions on Digg: http://digg.com/linux_unix/Firefox_eclipses_IE6_in_web_share_threatens_IE7

I have a solution that I hesitate to offer... Because it works against me and others in my shoes. The solution is if IPB will offer 2.2.x support for bugs and "hack" fixes, etc... only .x upgrades to 2.2.x in other words... This would create an EOL date possibly until IE6 reaches it's EOL notice next summer. Thoughts? It would provide an avenue that makes everyone happy with the only cost being some legacy support on the side of IPB.

Yes. I would say we should at a minimum wait until Windows 7 / IE8 are final and released. This will help spell the end of IE6 especially with the EOL notice for IE6 just over a year out. This will force everyone to upgrade and solve the issue. I hope IPB can hold on to support for it until then. The other (and less terrific option) is if IPB extends it EOL notice for IPB 2.x out until then and provides bug and technical support to then. Even if this was not an option I would not upgrade to IPB 3.x for likely 3-6 months after its release to allow any latent bugs and security flaws to be found and fixed.

Valid point. But they still chose to build in a fully functional skin (versus a very reduced and limited skin).