I just closed another punbb forum without antispam. Received over 50k spams in one month; i wasn't careful enough. Punbb 1.3 needs an antispam feature built in. I really hope we won't have a punbb 1.3 coming out without that feature which I think is crucial.
27 2007-06-10 10:12
Re: Improve search? (8 replies, posted in PunBB 1.2 discussion)
Smartys > Exactly, the queries are run as fast as possible, which may not be what you want... Reindexing is extremely hard on the sql server, personnally i would prefer having the reindex process take more time with less load on the sql server. Concerning the shell version, I agree this is not something everyone can do, but:
1) that would be interesting for forums with several 100k messages, and at that size you usually have a shell account
2) Believe me, when the reindexation process takes several DAYS, you don't want to let your firefox open. Moreover, imagine you have a network failure within these three days, the reindexation process just crashes, and you will have to restart it manually where it had stopped. Same if your firefox just crashes for some reason...
So when I speak about improving the indexation process, dont misunderstand me: I don't speak of speeding up the process, I ask for a somewhat more reliable way to do it.
You should try to reindex a big forum with the current system 
28 2007-06-09 00:34
Re: Improve search? (8 replies, posted in PunBB 1.2 discussion)
Smartys > for the reindexing I would suggest a tool in perl/php-cli, so that it can be run from the command line in a screen... With an option for the speed of the queries.
Concerning the search, we are still having _huge_ problems with it, because of its performance and the pertinence of the results. We will see if we find a solution...
29 2007-06-04 07:17
Re: Improve search? (8 replies, posted in PunBB 1.2 discussion)
Smartys > The search indexer needs to be completely rewritten too imho... Reindexing would take up to one week on our servers with their current load (took me 2 days last year wih 1/3 of the posts and less loaded servers) - and I don't feel like keeping a browser window open all the time.
Concerning 1.3.... The last time I heard punbb 1.3 would come out, it was in september 2005, stating that it would probably come out before the end of the year... And I think if 1.3 goes the same way as 1.2, with beta 1->4, it will take at least one other year from now on to get it production-ready
There was a fullsearch mod for punbb 1.2, is it working well? Is there a backport of the fulltext search from 1.3 to 1.2?
30 2007-06-01 11:47
Topic: Improve search? (8 replies, posted in PunBB 1.2 discussion)
Hello, I wanted to ask here if there were plans to improve the search, or if someone actually already did. The search is poor, as in its performance as in its results; when I look for nvidia on our forum, I get over 277 pages of unweighted results, or more complex queries i dont get any answer at all, because it must return too much results, hitting some of my mysql limits, certainly.
Has someone already tried to bundle punbb with another search engine, like lucene, or any other one, that would actually be faster and more effective?
31 2007-04-23 22:47
Re: Punbb & Memory usage (3 replies, posted in PunBB 1.2 troubleshooting)
Concerning mod installed.. The subforum thing is a self made, it doesnt use more memory than if I wasnt using it (just hides subforums with a type=2 and that's it)... Else hhm.. the bbocde one.. we don't have much mods running.
Concerning the file concerned, hihihi, if only I knew 
Maybe the search? Btw how good is the fulltext search mod now?
32 2007-04-23 22:20
Topic: Punbb & Memory usage (3 replies, posted in PunBB 1.2 troubleshooting)
Hello! Punbb seems to use a large amount on memory on my system...
Allowed memory size of 31457280 bytes exhausted (tried to allocate 10 bytes)
[Mon Apr 23 21:29:19 2007] [warn] FastCGI: (dynamic) server "/srv/www/fr/forum.ubuntu-fr.org/bin/php4-cgi" (pid 6429) terminated due to uncaught signal '11'
(Segmentation fault)
[Mon Apr 23 21:29:19 2007] [warn] FastCGI: (dynamic) server "/srv/www/fr/forum.ubuntu-fr.org/bin/php4-cgi" (uid 1011, gid 1011) restarted (pid 1172)
Allowed memory size of 31457280 bytes exhausted (tried to allocate 10 bytes)
[Mon Apr 23 21:29:19 2007] [warn] FastCGI: (dynamic) server "/srv/www/fr/forum.ubuntu-fr.org/bin/php4-cgi" (pid 5903) terminated due to uncaught signal '11'
(Segmentation fault)
Allowed memory size of 31457280 bytes exhausted (tried to allocate 10 bytes)
[Mon Apr 23 21:29:19 2007] [warn] FastCGI: (dynamic) server "/srv/www/fr/forum.ubuntu-fr.org/bin/php4-cgi" (pid 32287) terminated due to uncaught signal '11'
(Segmentation fault)
Yeah, fastcgi doesn't seem to like becoming out of memory 
But anyway, over 30MB seems like huuuge to me.. Our board is quite large, but I must admit I expected the memory consumption of every process not to grow like this..
Someone, any idea? What can cause punbb to use more memory when the board grows?
33 2007-01-25 16:53
Topic: Beautiful auth API, for better integration (2 replies, posted in Feature requests)
I find punbb quite difficult to integrate into a website composed of many scripts, as you are forced to use punbb's identification system... Dokuwiki provides a simple, short and great api for that; would it be possible to have a beautiful api, so we could implement identification the way we want?
34 2007-01-14 18:28
Re: Maintaining two branches - a stable version, and a dev version (6 replies, posted in PunBB 1.2 discussion)
Jeremie > sometimes it's just 2/3 lines... I could do it but then it would be a fork 
Rickard > some kind of "service pack" eh?
By the way I'm happy to hear that semi-serious bugs will be fixed in 1.2
Many thanks for punbb, you're doing great
35 2007-01-14 01:06
Topic: Maintaining two branches - a stable version, and a dev version (6 replies, posted in PunBB 1.2 discussion)
Hi, this message is particularly intended to Rickard, but everybody is free to give his opinion
I find it a bit sad that all the efforts are going into the development version, and nearly noone to the current stable version. When reporting bugs, answers often are "fixed in CVS" or "will be fixed in 1.3"...
There are bugs in 1.2 that will never get fixed in 1.2 (just let give two examples: people being more than one time in the online user list, their message being displayed n times - and the "group by" tweak in the search - there may be other examples). These bugs are fixed in 1.3, which is new version with a lot of new features, and which will certainly involve a lot of other new bugs... This all results in the fact that there is no _really_ stable and bug-free version of punbb.
I think it would be really nice, and not require much work, to really maintain these 2 branches, and really backports bugfixes in the 1.2 version, and not only security fixes.
Would that be an option?
36 2007-01-11 04:39
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
I'm glad to introduce worf, the guy who wrote the patch in the first post of this topic
37 2007-01-11 00:35
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
sirena > it depends on the size of the indexes of your forum (as far as I understood, i'm not quite good in sql, and usually gets help for this).
The key_buffer_size should be bigger as the size of your indexes; but you should be careful to have enough RAM so mysql don't need to swap (which would be really bad).
By the way, I disabled the wildcards in the search, a query on %wifi% just killed my forum Would be nice to be able to disable these in the admin panel
39 2007-01-10 13:15
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
Rickard > Smartyes told me it was buggy and searched in forum where users have no access
Btw, i'm continuing to investigate the issue... And I think I should apologize for my complaints, the search was what
caused my server to read/write so much on the disk, but I think it was because of a too small key_buffer_size ...
Sorry for that.
40 2007-01-08 23:50
Re: The biggest PunBB? (142 replies, posted in PunBB 1.2 discussion)
reviewum > that's not mine
Btw, I'm managing a quite big forum too, http://forum.ubuntu-fr.org/ . We have a bixeon 3Ghz, 4GB RAM, scsi10k for web, and 1GHz/1GB ram / 18GB scsi 10k for database.
There are also another forum almost the same size, 2 wikis (with quite a lots of hit), 2 planets, and some other crap on these.
Punbb is such a great software, but the search is KILLING it. Cpu usage on sql would be 70% less if search was disabled, although there are other things running on it. I'm actually hoping there will be backports from the search from 1.3 in 1.2, but I don't think there will
41 2007-01-08 23:37
Re: The biggest PunBB? (142 replies, posted in PunBB 1.2 discussion)
Try searching, for example, *mac* on http://beta.maclife.com/forums/search.php ... I guess the search query goes too long.
42 2007-01-08 23:29
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
Btw, Am I the only one with these bugs? I can't understand how bigger forums manage it...
43 2007-01-08 23:04
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
I'll try to move the search to another server... 
PS: just as a comparison i wanted to look how was search in SMF, and tried a request a bit complex like "forum -php -bug" and got a sql error... the search pain is not only punbb specific
44 2007-01-08 20:16
Re: "Disable search all forums" not working (or just hiding the link?) (3 replies, posted in PunBB 1.2 bug reports)
elbekko > i don't want to totally disable the search, juste the "search all forums"... and it was first intended as a test to see how much it would reduce i/o operations.
45 2007-01-08 19:46
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
MMmhh, could the following scenario be possible?
- Someone start a search that take long, let's say, 30secs - it locks the topics table in write, so that read is still available, but no posting as long as the search is not ended...
- Someone posts: as the topic table is locked in write, it waits for the search to be finished, and until that, locks the table in read too...
- Someone tryes to display the forum: Not possible due to lock of the table, has to wait for the search to be ended.
And that way, the forum lags.
Is that possible? Are there solutions? Would moving from myisam to innodb change things (the row locking may prevent that?) Moving the search to another server so that the tables get not locked?
46 2007-01-08 19:36
Topic: "Disable search all forums" not working (or just hiding the link?) (3 replies, posted in PunBB 1.2 bug reports)
Hi, deactivating "search all forums" does not prevent people from calling the search page directly, and search all the forums. This can be particularly painful if some of your members created some kind of "firefox search plugin" for your forum and a lot of people are using it.. or if people made special forms to search your forum....
47 2007-01-04 13:14
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
These lines don't work... Error: Unable to fetch topic IDs.
Are you to be find tomewhere on IRC?
48 2007-01-04 09:59
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
Yeah that broke the search, in fact... But, this query is killing the server's disk.. Is there no way to improve it?
49 2007-01-04 01:31
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
Yep, the same as earlier (hey, some people still awake?? )
So I deleted that part: INNER JOIN '.$db->prefix.'topics AS t ON t.id=p.topic_id
50 2007-01-04 01:15
Re: Punbb search performance tweak (30 replies, posted in PunBB 1.2 discussion)
Can it be that the join is in unused in other queries, like for example this one (search.php):
if ($show_as == 'topics')
{
$result = $db->query('SELECT t.id FROM '.$db->prefix.'posts AS p INNER JOIN '.$db->prefix.'topics AS t ON t.id=p.topic_id INNER JOIN '.$db->prefix.'forums AS f ON f.id=t.forum_id LEFT JOIN '.$db->prefix.'forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id='.$pun_user['g_id'].') WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND p.id IN('.implode(',', $search_ids).')'.$forum_sql.' GROUP BY t.id', true) or error('Unable to fetch topic list', __FILE__, __LINE__, $db->error());
Deleting that join resulted in 70% less disk access, as I had a lot of slow_queries coming from that request.
Was it safe?