We are looking for someone who can optimize mySQL to support:

1,300,000 members data, 5,000 new member signup per day and 6,000,000 "request" per month. ("request"= user traffic when updating & searching the database. Some call this impressions).

Interested, email: besthope2005x@yahoo.com

Suggestion one : move to php. its more efficient compared to perl, and will cut down a lot of over head increasing speed.

Originally posted by kunal
Suggestion one : move to php. its more efficient compared to perl, and will cut down a lot of over head increasing speed.

I just wanted to note: If you want the most efficiency, you'll use C -- and not PHP over Perl. Also, Perl can be just as efficient as PHP, provided you use it in a web server module (like PHP does) by using FastCGI or mod_perl. You can also use C with FastCGI, so you have a pre-compiled executable that doesn't need to be parsed like Perl or PHP, plus have it embedded in the web server's httpd process in the FastCGI server module. That is what you can do to make sure it's the best performing. Finally, you always have the option of taking it a step further and writing a server module in C (or Perl) that will perform faster than PHP as a server module, or Perl or C as CGI.

Totally agree with Tim.

PHP may be faster than Perl when the server is not in mod_perl mode, and remember, that's only when we are talking Web Page loading.

Perl does a lot more and in his case, it may not even related to Web page, a lot of it probably belongs to MySQL database optimization which needs manipluated by using Perl in shell. So it doesnt really matter if you use mod_perl or not anyhow.

I also hate it when people blame perl for "slowing down the web pages" and "not loading as fast a php". It is the CGI processes that are so slow, not perl itself.

Originally posted by Woody
I also hate it when people blame perl for "slowing down the web pages" and "not loading as fast a php". It is the CGI processes that are so slow, not perl itself.

That and the fact that bad, slow code and routines, are bad and slow routines in any langauge or interface. I've seen just as many PHP scripts put high loads on servers as CGI, and the same with MySQL processes. Take this WHT forum and the software it runs, for example; It takes up a lot of system resources. WHT doesn't get _that_ many hits and this software is coded in PHP and uses MySQL.

I've seen regular Perl CGI scripts use flat file databases and work better. It's all about the code and sometimes about knowing tricks and also sometimes how the server is configured -- and always about the servers hardware. Nonetheless, I didn't mean to take this person's job offer thread so far off topic -- sorry about that, oldtimmer.

Very True. This could be a very interesting discussion. Eitherway, Back on topic now.

What kidn fo script is it? Was it custom made or did you buy it?

Originally posted by Tim_Greer


That and the fact that bad, slow code and routines, are bad and slow routines in any langauge or interface. I've seen just as many PHP scripts put high loads on servers as CGI, and the same with MySQL processes. Take this WHT forum and the software it runs, for example; It takes up a lot of system resources. WHT doesn't get _that_ many hits and this software is coded in PHP and uses MySQL.

I've seen regular Perl CGI scripts use flat file databases and work better. It's all about the code and sometimes about knowing tricks and also sometimes how the server is configured -- and always about the servers hardware. Nonetheless, I didn't mean to take this person's job offer thread so far off topic -- sorry about that, oldtimmer.

I agree with what all of you guys have said.. one can re-compile perl.. one can install mod-perl... but are these the best solutions in todays vitual hosting time??

i mean, mod-perl is very very strict on how it handles perl code.. if there is even one badly coded routine, it goes totally wacky in the head.. and we all know how many "free" scripts are out there which have been badly coded...

as for the c alternative, yes you have it.. how many hosts will let you compile a c program and run it on there server??

from my expierence, which i agree isnt that much compared to tim, i have had these issues with my hosts earlier...

Kunal,

How is mod_perl forcing you to code the right way bad? Most good perl programmers already code the way mod_perl wants you to. Use strict, etc. Not exactlly a big problem.

To me, you are trying to say you can code sloppy code in PHP and get away with it, but you have to code right in mod_perl, so don't use it.

Originally posted by Woody
Kunal,

How is mod_perl forcing you to code the right way bad? Most good perl programmers already code the way mod_perl wants you to. Use strict, etc. Not exactlly a big problem.

To me, you are trying to say you can code sloppy code in PHP and get away with it, but you have to code right in mod_perl, so don't use it.


No. I dont recommend writing sloppy code, but you have to remember, we do not live in an ideal world.

I think (and this isn't to insult anyone at all or question their abilities), that most people don't think Perl or C is a viable or reasonable alternative, based on the fact that few people really know how to code really well in these languages. This is why PHP is so popular. The goo thing about PHP, is it's easy and fast to learn, especially compared to things like Perl and C. The other plus, is that it's pretty efficient due to not as much overhead. The problem, however, is that like I said, bad code is bad code -- and the more popular a language is for a task, the more people code in it -- the more bad code there is, and the less valuable that interface or language becomes to a lot of people.

What gave CGI and Perl such a bad rep, is two main things; #1: The overhead CGI creates -- but that's not a problem if you use the same type of idea that PHP's engine is. Problem solved. #2: Perl was hugely popular (and still is) and a LOT of bad code was the product of it. I mean, a LOT. Very, very few quality Perl code exists, and I have yet to see any quality Perl code given away or be free, other than examples by Randal Schwartz or Tom Christiansen and the like. I think it just became the hype and now PHP is the hype and it too will suffer the same fate, taking away the real value and reason why it's there, what purpose and tasks it best serves and how it's created to function. In fact, PHP is already about as equal as Perl/CGI is in regard to causing load problems on servers.

Because Perl was the hype before, there was a lot of bad, inefficient code floating around and being created and causing countless problems on servers. Now, I'm seeing the same results from PHP. PHP was created partly for the reason of saving the overhead caused by CGI -- but again, that's solved by using other modules too. I think CGI and language like Perl will have a bad rep for a while. The syntax is weird compared to a lot of other languages and it takes time and comprehension to properly use. I rarely see a qualified Perl programmer. I rarely see a qualified PHP coder either though, and the same with any language too. PHP just reminds me so much of ASP and that was the big hype for a while. PHP still has a lot of growing to do, it's not as powerful and lacks the variety of Perl, but it's also not as mature as Perl either.

I see a lot of people using the excuse or claims that PHP is better suited for the web. That's not at all true. Granted, Perl wasn't designed, at first for such tasks, but it just worked out so well because how it was designed and worked quite well. Perl requires very little knowledge to make it just as friendly as PHP, and there's countless (and I mean that!) of modules that can make your task perhaps even easier than PHP would for web based applications. Honestly, I just don't see the advantage or point. I mean, I use it, it's fun, but I'd rather code in Perl for a million and 1 other reasons. PHP is a great tool, I won't argue that, but comparing Perl and PHP is pointless, because Perl has it all in that regard too -- it's just (obviously) more of a real language.

However, like I always say, if people are really concerned about efficiency, use C, you're not going to get faster than a pre-compiled, well coded program and you can make it a web server module on top of that -- talk about a dream! :-) I don't blame people for using PHP and learning that instead of Perl.. I mean, there's no reason to for a lot of people -- although I've always thought command line PHP was a really stupid idea personally. PHP is good, there's no reason to really say anything bad that's no obvious. They've accomplished a lot, I'm impressed. I like it. I just don't think it is superior or Perl, or even can compare to it.

Of course, given a certain experience and knowledge of a language, you will know how to code it to be equally as good, if not better. PHP doesn't allow you to do that, even if you can code good or bad code, whereas Perl does -- and C even more allows you to. There's just more power, more control -- which allows you to have a superior option than something like PHP. However, I don't expect many people should, could or would have a reason to spend so much time learning a lower level language, when all they want is a simple web board or guest book, mail form or the like. I'd tell them to learn PHP at that point.

On that note, I will also say, that a lot of PHP's syntax is a mix a match between C and Perl anyway, so if you learn PHP, you'll probably get a good idea what's going on in another language like C or Perl anyway. I conclude with this thought; I just like having the option to truly code my own routines with endless possibilities, whereas you can only do that sort of thing in so many languages/interfaces and PHP is not one of them. However, I don't see many people needing or wanting to get that involved and that's fine too -- provided they write good, quality and efficient code. Just be careful and consider it all when you start getting hundreds of thousands of accesses per hour or day. And now back to your regularly scheudled program (I think the mods will probably move this thread with the off topic parts to another forum soon)...

Hi, since this is some of the few thread talk about fastcgi + C on WHT and I'm doing some benchmark between PHP and C version. However, the problem with C is it run as CGI and as all discussions above and many other places showed that the overhead is quite a problem. So I was wondering what solution do I have? (on Linux)

+ C run as a CGI script
+ Build Apache with FastCGI & C as a CGI script
+ Build a custom module for Apache (this doesn't sound much, but seems to have the best performance?)

And also, if I miss something, please add or correct. Thanks

Originally posted by 123finder.com
Hi, since this is some of the few thread talk about fastcgi + C on WHT and I'm doing some benchmark between PHP and C version. However, the problem with C is it run as CGI and as all discussions above and many other places showed that the overhead is quite a problem. So I was wondering what solution do I have? (on Linux)

+ C run as a CGI script
+ Build Apache with FastCGI & C as a CGI script
+ Build a custom module for Apache (this doesn't sound much, but seems to have the best performance?)

And also, if I miss something, please add or correct. Thanks

Well, this is an old thread that I just got an email saying someone responded to. Building an Apache module in C, is best, since it'll be compiled into Apache and be embedded into it's httpd process, and not have to spawn or parse any code, or anything extra, etc. Well, for the most part. Second, the next fastest, would be to run C with FastCGI. C in FastCGI isn't exactly CGI -- which is why it saves the overhead. C using fastCGI is faster than PHP (mod_php). There's nothing wrong with using C as CGI though, without FastCGI or other such things. It just depends. Most people write such inefficient PHP code, that most (well written) Perl scripts that run as CGI are almost always noticeably faster. Even with both well written Perl or C (especially C) running as CGI and comparing it to well written PHP code, it's sometimes no faster to use PHP, and in a lot of cases, it's not. That's not to say PHP isn't faster for some things though, when compared to something running as CGI. If you write good PHP code, it'll be faster than some CGI though (be it Perl, C, C++, Python, etc.) -- although it's not always a big difference and not always faster (just to repeat for the sake of clarity). However, you can always use mod_perl or fastCGI to make Perl and other langauges like C, Python, etc. to take advantage of embedding it. Again, C doesn't need it's code to be parsed, it's already compiled, so comparing C as CGI to mod_php, might or might not make any noticeable difference in resource usage or overhead. C using FastCGI will allow you to create programs that are faster than mod_php, assuming you code it efficiently -- which is the main complaint about CGI -- even if it does have overhead. After all, PHP has overhead too -- and it's code needs to be parsed, it's not compiled. Even if you use a PHP compiler or a Perl compiler, it's not going to be as efficient as a well coded and compiled program in C. Yes, other than writing an Apache module in C, your next best option would be to use fastCGI with C. Next down the list, I'm not sure. I'd personally have to really think about using PHP over a regular well coded compiled C program running as CGI.