Printable View
I have recently been doing some web related stuff and I want to get started having some dynamic content. I can't decide whether to use PHP and MySQL or just write Apache modules. The job is pretty CPU intense so the module might be better for speed but PHP and MySQL really seem to know what they're doing when it comes to servers and I've heard a lot of good things about them. Which one of the two would you recommend? Would you recommend either?
writing PHP extension is easier. Embed your extension into your PHP script.Quote:
The job is pretty CPU intense
They are often used together - PHP installed as an Apache module, and MySQL for database (accessed by PHP).
I suggest PHP (you can call a C program to do the calculations from a PHP script if speed is that important).
I never thought of calling a C program. As far as difficulty, how bad is writing an Apache module for something like say a forum?Quote:
Originally Posted by cyberfish
It's pointless since 90% of the load time goes on SQL queries.Quote:
Originally Posted by lruc
That would depend on the application.Quote:
It's pointless since 90% of the load time goes on SQL queries.
I have never written an Apache module, but it would be a very unusual way to go about doing it to say the least, and quite possibly very difficult.Quote:
I never thought of calling a C program. As far as difficulty, how bad is writing an Apache module for something like say a forum?
A forum is not CPU-intensive at all, and is well suited for PHP.
I would just do the CPU-intensive part in C, and call it from PHP. PHP is just so much more convenient.
Yes -- I'd definitely go with PHP, and do the heavy lifting in an external C program, communicating between the two with a pipe.
One of the SMF developers actually started to try and do that. He gave up on it. It just isn't worth it.Quote:
Originally Posted by lruc
A forum shouldn't be CPU intensive. The most intensive part is pretty much search. Everything else is mainly data shuffling.
And search is probably going to be implemented by MySQL anyways.Quote:
A forum shouldn't be CPU intensive. The most intensive part is pretty much search. Everything else is mainly data shuffling.
True. Though sometimes you still want to do some additional post processing so the queries don't become massively complex. Have to look at what the setup is also. If you have multiple web servers and one DB server you might get away with shifting some of the work to the webservers.
Running a forum with about 10000 people online at all times is no problem for a modern server. And I don't see much forums like that, so for a forum one server should do the job. But I guess we are talking about your CPU intense project, so it only serves as a comparision.Quote:
Originally Posted by Thantos
How CPU intense will your web application be? What type of data does it need to process?
Um, that's not what our users were telling us. I've seen large forums that have 2+ web servers, a master database server, and a slave database server all running on different hardware and still have problems during peak times. So it can easily scale past the ability of one server to handle. But the benefit of writing it as an apache module just isn't there.Quote:
Originally Posted by maxorator
Well, I guess it depends on some other factors too. But the Apache module thing wouldn't be useful for a forum for the reason I mentioned earlier - most of the load time and CPU power goes to processing the SQL queries. Even if the CPU load on the web server would decrease, the DB server would still be the bottleneck.Quote:
Originally Posted by Thantos
Since nearly everything to do with the forum is database work - the only bit of a PHPforum that is even remotely CPU intensive is the processing when posting/editing/quoting a post. This is so that the HTML-ization of the post can be done ONCE, rather than doing it every time a post is DISPLAYED (which, for normal use, is probably a factor of 10+ more frequent).
The reason for needing more servers is probably a case of having enough RAM to cache the queries, and to have fast enough disk(s) when there isn't enough RAM. Since a forum like this, with a few 100k posts, hundreds of users, can't realistically fit in reasonable amount of RAM, it's likely that the need for a bigger database server is based on the I/O speed rather than the CPU processing ability (although I'm not 100% sure of that).
[1]I'm slightly more familiar with PHP forum, as I have worked with a webmaster to extend it slightly, compared to vBulletin that this forum uses, but I expect it to use a similar approach.
--
Mats
RAM is pretty cheap nowadays so having 10GB-20GB RAM on a server is no problem. But nevertheless, most SQL databases don't cache almost any data due to the huge amount of data they process and the amount of data they hold. That's why database servers usually don't use normal hard drives, but either SCSI or some SSD.
From what I can recall of the big forum users we had a lot of it was also Apache just handling the request. While the actual PHP code didn't take a lot of work itself there is still quite a bit of work Apache has to do. But I'm not 100% sure as I've never taken the time to really look at it.Quote:
Originally Posted by matsp
I was planning on trying a multi-lingual forum that uses machine translation to show to forum in any desired language. That to me sounds pretty CPU intense and I'm not sure if PHP would even be able to translate.Quote:
Originally Posted by maxorator
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.
Historically doesn't matter because I'm talking about modern servers. I'm assuming their servers don't have an Intel Xeon 7400 processor, 12GB of RAM and SCSI hard drives.Quote:
Originally Posted by sorrofix
OP, did I get it right that you want to write your own translating system?
In a way. I wont personally be doing the translating. Ill probably use google translation. Anyways I'm pretty convinced with PHP + MySQL is the best way to go. My last question is would using CGI(pre-compiled) be faster or slower than PHP + MySQL? I wouldn't mind using CGI, as long as the speed increases.Quote:
Originally Posted by maxorator
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?
CGI is a gateway interface, not a language. It allows you to use a script or program written in another language to be used in the web server. The most common option is to use CGI for Perl. But the option you see on that site, is native application in C++, just loaded through CGI.Quote:
Originally Posted by lruc
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.
I very much doubt you can tell the difference - there will be three things that may limit the speed of the forum (or whatever Web-App it is):Quote:
Originally Posted by lruc
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.
--
Mats
Ugh. Stop asking that, CGI can mean either Perl, PHP, some other or native code (for example C++). PHP in most cases uses CGI (SAPI is an alternative, but I doubt it's used more).Quote:
Originally Posted by lruc
It is, if by SAPI you mean mod_php. If you mean IIS ISAPI, that's different.Quote:
Originally Posted by maxorator
Right sorry about that. I mean CGI with C when I say that.Quote:
Originally Posted by maxorator
And it's highly likely to make little difference, for the reasons I explained above.Quote:
Originally Posted by lruc
--
Mats
Depends on the application again. If it does something relatively CPU intense, then C(++) could give a big boost in performance. If it doesn't (like a forum system), then the difference is small.Quote:
Originally Posted by matsp
So your saying CGI with C is at least faster than PHP. That pretty much changes my vote to using CGI. Then again, any excuse would have done. I just wanted to use C.Quote:
Originally Posted by maxorator
You could write it in assembly to get even more speed... but like matsp pointed out, you probably won't notice any difference, and PHP is far easier.