And an Apache module can?
Even if you want to do it in C/C++, calling it from PHP is probably an easier choice.
With caching, it won't be CPU-intensive on average. If you have few enough accesses that caching won't help, you don't need to worry about CPU load at all.
>Running a forum with about 10000 people online at all times is no problem for a modern server.
Really? One forum I visit, which usually has a couple thousand people online, of which only about 20 are registered members, uses 2 database servers and at least 2 web servers and it's historically had a lot of problems with speed. Searching isn't even handled by their hardware -- it's sent to Google, and the results are parsed back.
Going back to the original question, a PHP script coupled with a MySQL database will be by far the easiest, especially for a forum. Don't bother writing an Apache module, that will just cause unnecessary complication and very few benefits.
Using Google's translation API makes sense. As the translating is then handled by Google's servers, it doesn't actually matter what you use. And also PHP can be pre-compiled (into bytecode), but not manually - PHP accelerators do that automatically.
Something I just found on Google: http://www.wrensoft.com/zoom/benchmarks.html
Thats pretty interesting to me because I have been assuming CGI is really slow because thats what the Wikipedia article on it seemed to imply. With those results, I would definitely change my vote to CGI. Would these results be similar on other kinds of websites?
The problem with CGI is that a new process is launched for every query. Launching and terminating a process is slow. CGI is therefore best for things that take a long time and are used comparatively rarely, like searching. CGI gets into scaling problems if it is used for pages that are retrieved very often, and that take very little time to compute, since the process overhead far outweighs the computation time.
FastCGI and SCGI are attempts to rectify this situation, by providing servers that manage a pool of processes for CGI execution, which reduces the overhead significantly.
For a forum about this size, would CGI or PHP be faster? I cant see any forum I make getting any bigger than this.
1. Disk I/O - if you haven't got enough RAM to keep EVERYTHING in RAM.
2. Internet connection speed - unless you have many hundreds of megabits per second. For simple things, a modern single-core processor can push out data at 1GB/s and not really breaking into the middle of the CPU performance. Of course, processing the data more than just reading it and writing it to some portion of memory will make it a bit more than that, but it's unlikely that you have 1GB connection to the rest of the world.
3. Thread/Process switching. When you have 10000 users, you will spend a lot of time switching from one user to another in the processing of the HTTP requests. It is likely to be a LARGE proportion of the CPU processing time to just keep all threads turning over. Let's say you have a 16 core machine, each core would handle 625 processes. Let's say each user does 1 request every 4 seconds [we're assuming it's forum, not a gaming server], then we have 4/625 seconds between each task-switch on each CPU. That's one process switch every 6.4 millisecond. That's not bad, but you also have to consider that there may be more to it than that: There are likely more than one thread/process per user - a PHP client, a database thread, appache itself. Reading the disk will not help either, as it makes another task-switch.
Having a large cache on the processor will help the code-execution, but highly unlikely to contain something useful for the next thread when it comes to data.