Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Optimize PHP and Accelerate Apache

CmdrTaco posted more than 7 years ago | from the wouldn't-it-be-nice-if-we-were-faster dept.

PHP 191

An anonymous reader writes "As the load on an application increases, the bottlenecks in the underlying infrastructure become more apparent in the form of slow response to user requests. This article discusses many of the server configuration items that can make or break an application's performance and focuses on steps you can take to optimize Apache and PHP."

cancel ×

191 comments

want performance from php? (3, Interesting)

wwmedia (950346) | more than 7 years ago | (#19291899)

want performance from php?

Dump Apache! its the slowest link!

use Lighttpd [lighttpd.net] + latest PHP 5.2.2 + APC [php.net]

Re:want performance from php? (3, Interesting)

Ant P. (974313) | more than 7 years ago | (#19291949)

I'll second that - Apache is as bad as Firefox when it comes to resource waste. On my machine, lighttpd uses about 1MB of RAM, not counting the PHP processes.

Re:want performance from php? (5, Funny)

Anonymous Coward | more than 7 years ago | (#19294125)

Dear Opera user: Fuck you.

Re:want performance from php? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19291973)

Lighttpd?
A buggy server and FastCGI, really great combination.
No thanks!

Re:want performance from php? (3, Interesting)

Anonymous Coward | more than 7 years ago | (#19292009)

There are many reasons Apache httpd is the standard and speed isn't one of them but lighttpd is pretty awful although lua integration is cool (much faster than PHP). I might say that if you want performance, avoid crap like PHP and Ruby. That's pretty much true but ignores the fact the bottleneck is usually going to be the database, regardless of whatever other software you happen to be running.

TFA reads like a newbies blog article, 'OMG I know how to haX0r php.ini and httpd.conf'. Any half decent sys admin already knows all this - it's obvious and well documented stuff. I wouldn't be surprised if the author just reworded a couple of blog entries for this article.

Re:want performance from php? (0, Troll)

Anonymous Coward | more than 7 years ago | (#19294233)

That's pretty much true but ignores the fact the bottleneck is usually going to be the database
Can you clarify what this means? In particular, what is a bottleneck and what is a database?

(this is wwmedia speaking, I can't post under my own name for some reason)

Re:want performance from php? (3, Informative)

Anonymous Coward | more than 7 years ago | (#19292083)

That sounds like a rather dumb comment. I also bet you are comparing lighty to apache 1.3. Or you do not know what you`re talking about. I have had (until february) a P3-400 w. 256 MB with around 200 Domains configured (of which 2 make up for 98% of traffic)
running a LAMP Stack w. apache 1.3. The machine serves 6 concurrent users with 8.9 Database-Hits/Sec serving around 30-40G/month.

I have absolutely no problem with apaches speed when it comes to serving pages. It does lag when forking processes, though, so I have to keep a certain quantity of processes in reserve (20).

This leads to memory problems, especially since, with mod_php, the process size alway increases but never decreases with apache-process age. Thrading (where basically memory is shared) and Fastcgi for the php should cure that. And that is what lighty does. But: with apache2, worker mpm and mod_fcgid, it works, too.

Then all you need to do is keep keepaliverequests reasonable and keepalivetimeout low. And get a reverse proxy (apache2.2).
Lighty is probably good, but I do not think it has much advantage over a well tuned apache.

 

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19292159)

Hey dude, take a look at varnish [linpro.no] instead of using Apache as a reverse proxy ;-)

Myself, I like mathopd for static content and employ a stripped down Apache 1.3 with a static mod_php for the dynamic stuff. Lighttpd is often promoted by fanbois that obviously don't even run busy sites - it's very strange these guys think themselves qualified to give advice (and yes, I have evaluated it).

Re:want performance from php? (1)

prencher (971087) | more than 7 years ago | (#19292311)

YouTube, reddit, parts of wikipedia, imageshack, sourceforge all use lighttpd.. Are those small sites?

More here: http://blog.lighttpd.net/articles/2006/12/28/light tpd-powers-5-alexa-top-250-sites [lighttpd.net]

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19292435)

Only for static content you retard.

Re:want performance from php? (1, Informative)

Anonymous Coward | more than 7 years ago | (#19292439)

> YouTube, reddit, parts of wikipedia, imageshack, sourceforge all use lighttpd..

...and thousands of bloggers copy them blindly without understanding the problem area. Then they go espousing how lighttpd is some magic bullet, when the truth is that every situation is different. YouTube (for example) also use Apache, what does that tell us?

One thing lighttpd has going for it is SCGI, FCGI really does need to die.

Re:want performance from php? (2, Interesting)

QuoteMstr (55051) | more than 7 years ago | (#19294469)

As somebody who's writing a program that might be running under fastcgi, I'm genuinely curious as to why fastcgi sucks and scgi is better.

Re:want performance from php? (1)

nneonneo (911150) | more than 7 years ago | (#19292455)

Hmm, the article you linked to says that Slashdot runs PHP -- I'm pretty sure that isn't the case. In any case, the majority of the sites mentioned are using Lighttpd for static content only.

Re:want performance from php? (1)

NickFitz (5849) | more than 7 years ago | (#19293903)

Hmm, the article you linked to says that Slashdot runs PHP -- I'm pretty sure that isn't the case.

You are correct. [slashcode.com]

Re:want performance from php? (4, Insightful)

gbjbaanb (229885) | more than 7 years ago | (#19292461)

They are for static content.

Now lighttpd serves 6 out of the top 250 sites. Do you think the other 246 run IIS or something?

Lighttpd is good, but is best used in specialised instances, for specific (mainly static content) tasks. Its pointless using it for PHP as the cost of forking out a process to run the script will outweigh any saving from running a lighter-weight http server.

Re:want performance from php? (1)

TheRaven64 (641858) | more than 7 years ago | (#19292943)

Its pointless using it for PHP as the cost of forking out a process to run the script will outweigh any saving from running a lighter-weight http server.
Lighttpd uses FastCGI for PHP, so the PHP scripts run in a separate process which persists across connections (and several can be used for load balancing). There may be other reasons for not using Lighttpd with PHP (I've not tried), but the cost of fork is not one of them.

Re:want performance from php? (1)

prencher (971087) | more than 7 years ago | (#19293005)

This is of course true to an extent, but to say that lighttpd is only good at static content serving is flat out false; Look at reddit for example.

Furthermore, I never argued whether or not ligthy is better than apache in my post, I just wanted to make clear that lighttpd certainly has a use for busy dynamic sites as well. The post I replied to seemed to imply this is not the case.

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19293201)

> The post I replied to seemed to imply this is not the case.

That would be my post and I didn't mean to imply that. I was just pointing out that lighttpd seems to be promoted by plenty of people who don't run busy sites. It's single process design uses less memory than Apache and that alone may be a valid reason to use it but as someone below noted; very few sites have the bandwidth required to benefit from the performance gains. This is especially true since the OP was talking about replacing Apache + PHP where performance gains would be minimal at best.

Reverse proxy (2, Informative)

Snowhare (263311) | more than 7 years ago | (#19293701)

And get a reverse proxy (apache2.2).
I have to second this point. I am in the process of setting up a new site that needs to use a PHP based knowledgebase system. The raw performance numbers of the knowledgebase were absolutely abysmal (6 pages/second). I spent half a day working with the Apache 2.2 reverse proxy and got it up to 350 pages/second.

Re:want performance from php? (2, Informative)

malsdavis (542216) | more than 7 years ago | (#19292117)

I would love to dump Apache, but Lighttpd and the other alternatives simply don't provide the power, functionality and customisation I need from my servers. Then there are the many inequitable Apache extensions which are simply a necessity in some situations.

Personally I feel Lighttpd is just too light, but I agree, Apache is too heavy. I would love to find a happy medium but I am yet to find a httpd server which even approaches Apache and its popularity shows that an awful lot of people agree with this.

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19292225)

"wealth creation" is a measure of future expectations. It does not break any rules.

Re:want performance from php? (2, Interesting)

TheLink (130905) | more than 7 years ago | (#19292241)

lighttpd leaks memory, how secure and "lightweight" is that?

So far Apache is good enough for me, but if you're going to replace Apache with something that is fast and has features, you may wish try Zeus.

Anyway, I'd dump PHP first. PHP is slow and has tons of security problems - and judging from the way the devs do stuff, there'll be plenty more to come.

Re:want performance from php? (2)

TheLink (130905) | more than 7 years ago | (#19292775)

Flamebait? Someone can't handle the truth? Tsk tsk :).

"lighttpd leaks memory":
http://www.google.com/search?hl=en&safe=off&q=+sit e:trac.lighttpd.net+lighttpd+memory+leak [google.com]
Random complainer: http://hostingfu.com/article/nginx-vs-lighttpd-for -a-small-vps [hostingfu.com]

As for security: Apache isn't what you'd call secure software, but Lighttpd isn't either.

PHP is slower than Perl or Python for most stuff. This should be common knowledge amongst decent programmers- go find/make your own benchmarks and links.

PHP security? ;). Need I say more?

Re:want performance from php? (5, Insightful)

malsdavis (542216) | more than 7 years ago | (#19292999)

"PHP is slower than Perl or Python for most stuff."

I'd say that in practice (i.e. when performing the vast majority of dynamic web functionality: e.g. database lookups) the opposite is true. Perl & Python are quicker at some tasks, but every-time I've rewritten a website between PHP and Perl (I don't program in Python because it's named after my most hated animal), PHP has come out slightly on top.

Re:want performance from php? (1)

QuoteMstr (55051) | more than 7 years ago | (#19294143)

Grow up. What, am I supposed to like Java because it's named after my favorite drink?

Re:want performance from php? (0, Flamebait)

malsdavis (542216) | more than 7 years ago | (#19294329)

I think it is yourself who needs to gain a bit of maturity. While your at it maybe you could learn to spot obvious jokes.

But I Can't Pronounce "LLMP"! (n/t) (3, Funny)

Mateo_LeFou (859634) | more than 7 years ago | (#19292143)

no text

Re:But I Can't Pronounce "LLMP"! (n/t) (2, Funny)

larry bagina (561269) | more than 7 years ago | (#19292459)

try LOL - Linux/OCaml/Lighttpd

Re:But I Can't Pronounce "LLMP"! (n/t) (1)

julesh (229690) | more than 7 years ago | (#19292847)

It could be worse. I don't know if IIS runs under Wine, but if it did that would be LIMP.

Re:But I Can't Pronounce "LLMP"! (n/t) (3, Funny)

zitch (1019110) | more than 7 years ago | (#19294533)

Just keep IIS in its native environment and we'll get WIMP... :)

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19292247)

no, the performance bottleneck lies with PHP being incompatible with pure threaded apache. It's been a long time since apache2 came out, and php is only partially threadsafe. The weakest link is PHP.

Re:want performance from php? (1)

julesh (229690) | more than 7 years ago | (#19292877)

Speaking as somebody who runs PHP in a threaded environment, PHP is actually pretty damned stable in one (i.e., it has *never* crashed for me). As I understand it, as long as you stay away from the less frequently-used extensions, you'll be fine.

Re:want performance from php? (2, Insightful)

pooh666 (624584) | more than 7 years ago | (#19292335)

Apache is what you *make* of it. If it is heavy look to your sysadmin and cut out the stuff you don't use. The idea that Apache is a bottleneck compared to ANY scripting application is totally misguided nonsense. I can't believe such an ignorant comment got any mod points, even on Slashdot. I can get at least 100Mbs out of a single server pumping out static content with nothing special other than removing unused modules in the compile to save on memory. So guess what, you are WRONG.. I at one point tried using things like thttpd for banner servers, I found with a little work, I could get Apache to run FASTER than those tiny httpd servers and I didn't loose out by having to work with a feature poor server.

Re:want performance from php? (1)

future assassin (639396) | more than 7 years ago | (#19292353)

Or from other people experiences that I've been reading about go with Litespeed http://litespeedtech.com/ [litespeedtech.com]

Re:want performance from php? (5, Informative)

doubledjd (1043210) | more than 7 years ago | (#19292665)

My history is java but I've come to appreciate php recently. The track record on it when used properly is impressive. In case there are some people just starting with it, the several of the problems with php performance is caching. (this is pretty standard stuff so apoligies to people who know a lot more about it than I do)
  1. Use apc or eaccelerator. (yahoo uses apc so that is the one we went with). This alone will give considerable benefit. Apc can defaultly cache any of the php that runs or it can also be used as a local cache for objects you'd like to store programmatically.
  2. If you need distributed items, especially in a non-sticky load balanced environment, look at memcached.
  3. Use a query cache for your db
  4. If your db connections are expensive, look at sqlrelay
  5. Look at whether a caching proxy is a possibility for you (squid or apache has some mods).
  6. Benchmark your pages and functions. It is the only way to know if configuration tweaks are adding any value. I usually do this after a full profiling using apd (to help identify the bottlenecks and frequently called functions). I usually run apache's ab to get a look at page benchmarks.
  7. you can always write c extensions for items in php that are too slow. Of course, you'll have to know c, increased maintenance, development time, etc
There are a million things to be done to increase performance. Obviously, don't use anything blindly. Still, I think the opcode cache (apc or eAccelerator) is probably the easiest and most substantial win.

Re: Stevie B. told me... (0, Offtopic)

MahariBalzitch (902744) | more than 7 years ago | (#19293857)

At a recent Web conference a guy name Steve told me the best web server to use was IIS from some company called Micro something or other. He was grasping his chair very intimidatingly, so I took his word for it. He also managed to talk me into buying a corporate license for some product called Office something or other. He was a great salesman I must say, since I don't even work for a company!

Re:want performance from php? (5, Informative)

consumer (9588) | more than 7 years ago | (#19292767)

All that apache does when serving PHP requests with mod_php is run the early phases (auth, URL mapping) and pass the request to PHP. Do you really think that Lighttpd + FastCGI is going to be significantly faster than that? The bottleneck is your PHP code, not the web server.



Lighttpd is probably faster at serving static content. Most sites don't have enough bandwidth to find out.

Re:want performance from php? (1, Insightful)

Fweeky (41046) | more than 7 years ago | (#19293135)

Quite; you can easily use FastCGI with Apache too (though lighttpd's built-in load balancing sounds nice; hopefully mod_proxy{,_balancer} will one day grow useful FastCGI support). Do that and watch as Apache sits using about 1000x less CPU than your backend PHP's.

lighttpd and friends are generally better if you're serving static content, but it's doubtful you'll notice unless you're talking in terms of many thousands of requests per second to a single server. That's not to say there aren't other reasons you might want to use lighttpd, but performance isn't really one of the interesting ones.

Re:want performance from php? (5, Insightful)

SQL Error (16383) | more than 7 years ago | (#19293555)

The problem is not that Apache is slow, it's that it uses huge amounts of memory. If your database is running slow for some reason - say, during backups - requests will start to queue up, Apache will start more and more threads to handle those requests, and things will spiral rapidly out of control.

Lightppd doesn't have that problem.

Re:want performance from php? (1, Insightful)

Anonymous Coward | more than 7 years ago | (#19293641)

> Lightppd doesn't have that problem.

No, it leaks memory instead.

Nginx doesn't have either problem.

Re:want performance from php? (1)

kbahey (102895) | more than 7 years ago | (#19293823)

If you want to stay with Apache, then the quickest fix for this is to reduce the number of MaxClients [2bits.com] so that an incoming avalanche of traffic does not cause overuse of memory and hence the swapping to hell syndrome.

What number to set it to depends on the size of each Apache process, and how much memory you can spare in the system.

Re:want performance from php? (1)

SQL Error (16383) | more than 7 years ago | (#19294003)

Yes, that stops it killing your server, and instead it rejects requests. It does nothing to actually fix the problem.

Re:want performance from php? (1)

QuoteMstr (55051) | more than 7 years ago | (#19294101)

Your server is going to choke at some maximum number of clients anyway. You might as well configure it to handle what it can and gracefully reject the rest instead of letting everybody's requests wallow in a mire of thrashing.

Re:want performance from php? (4, Interesting)

consumer (9588) | more than 7 years ago | (#19293879)

If you use separate processes for your static content and your PHP (either Apache with FastCGI or a reverse proxy), you won't have problems with memory. The size of an Apache process that's just serving static stuff is tiny. It's the PHP processes that take the RAM, and they will do the same when run from Lighttpd.

Re:want performance from php? (0)

Anonymous Coward | more than 7 years ago | (#19292933)

Or use the Zeus Web Server [zeus.com] - way faster then Apache, especially when running PHP using FastCGI.

Its all about how you use Apache (2, Interesting)

irving (52575) | more than 7 years ago | (#19293207)

The reason why Lighty and Litespeed have pulled better numbers than Apache is because they are threaded and use FastCGI, and always get compared to Apache with the prefork MPM using mod_php.

The latest performance numbers show that Apache 2.2 w/ worker MPM (threaded) + FastCGI can keep pace with Lighty and LiteSpeed. Many of us large site maintainers prefer Apache's feature set.

I agree that APC rocks, it outpaces Eaccelerator in a big way, and is more stable.

This article is not worth the read, I could condense it into a 3-fold pamphlet. Performance tuning is an art, this article does it a great bit of injustice.

Well We could always (1)

Sammy Loo (996666) | more than 7 years ago | (#19293499)

just get a bunch of old computers, cluster them, and every time the server load gets larger, add another old computer from the junkyard. Parallel computing at its finest.

Re:want performance from php? (1)

kbahey (102895) | more than 7 years ago | (#19293687)

As far as Lighttpd is concerned, there is an up and coming competitor called nginx [nginx.net] (Engine X). Its reputation is that it has all the benefits of Lighty, minus the memory leaks.

I have benchmarked [2bits.com] APC vs. eAccelerator [eaccelerator.net] and found that eAccelerator is some 13% faster. It also has significantly lower memory consumption than APC.

The 35 Year Old Virgin..... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19291935)

I've never even SEEN a woman's pubes.....

Links?

Of course! (5, Funny)

BabaYama (899483) | more than 7 years ago | (#19292089)

You should compile it yourself wicked fast compiler optimizations on top of your wicked fast install of Gentoo (which you also compiled yourself)

Re:Of course! (-1, Redundant)

Anonymous Coward | more than 7 years ago | (#19292135)

Unless you work in an enterprise environment.

Re:Of course! (1)

VagaStorm (691999) | more than 7 years ago | (#19292173)

I disagree, an eterprice enviornment is the only place you should ever have to compile anything for yourself :p Umless ofcource you just wrote it :p

Modules (3, Interesting)

deftcoder (1090261) | more than 7 years ago | (#19292101)

Apache generally ships (on most distros) with TONS of modules enabled... kill off any unneeded modules (come on, how many of you actually use mod_userdir or mod_rewrite?), tweak your MPM settings, and be done with it.

I also force PHP to run in FastCGI mode, that way I can use suExec with it to prevent exploits in PHP itself from allowing the entire system to be compromised. Apache suid()s itself after handling the request, but the Apache user can generally write to a few good places, therefore I use suExec.

Re:Modules (1)

tomhudson (43916) | more than 7 years ago | (#19292617)

"kill off any unneeded modules (come on, how many of you actually use mod_userdir or mod_rewrite"

Are you kidding? If anything, those are the two that are the handiest. Ever use short urls? That's mod_rewrite for you. Ever have users with their own public_html? That's mod_userdir.

Really, if you're going to pick on something, pick on, um, maybe mod_speling. (no that's not a spelling mistake - its a module that tries to guess what you really wanted if you misspelled a url, rather than just sending a 404, and even that doesn't take up much resources, since its only called in the event a request would generate a 404, not on success, so even mod_speling isn't "evil").

Re:Modules (0)

Anonymous Coward | more than 7 years ago | (#19292755)

Struck me as odd considering mod rewrite isn't even built by default in the 1.3 series.

./configure \
"--with-layout=Apache" \
"--activate-module=src/modules/php5/libphp5.a" \
"--disable-module=imap" \
"--disable-module=include" \
"--enable-module=rewrite" \
"--prefix=/srv/www"

Dunmp then both (2, Interesting)

butlerdi (705651) | more than 7 years ago | (#19292149)

I have found that a truly scaleable design pattern is using a lean little engine like Jetty and a declarative/Rest based architecture. We have recently ported Sugar CRM PHP/Apache to NetKernel and lost over 95% of the code and subsecond response times. We kept the horrible database design and the workflow in the first version as well, so reworking that will further improve performance and further reduce the need for code. For me performance is important but maintainability is equal. The less code the easier to maintain. There is a great white paper from the NK guys here [1060research.com]

Re:Dunmp then both (2, Funny)

gbjbaanb (229885) | more than 7 years ago | (#19292489)

If I took an app, "lost" 95% of the code, then I guarantee it'd work faster. Of course, by "work" I mean, "do nothing" but lets not let a little semantics get in that way of some technical self-aggrandisement. :)

Re:Dunmp then both (2, Insightful)

butlerdi (705651) | more than 7 years ago | (#19292687)

Well, it now has all of the original functionality it had and that is down to the lack of redundant code and frameworks. Declarative based systems are just different. PHP is an awful lot of code. The code seems to me difficult to maintain and modify, but this is just my experience. I stopped using the J2EE frameworks for the same reason. After 30 years of hacking this stuff I have seen an awful lot of 3GL, 4GL .... and other frameworks and they all have to me seemed a bit bulky. Like when I try to find the actual business logic in most of them. Web based apps have come a long way, I started with WebObjects on the Next machines, and have tried many of the methodologies currently being used Ruby, Groovy, PHP, JSP et al. Declarative and RESTfull systems have just worked for me and I have always found that most of the code in the others was for the framework not my app. But as I said before, this has just been my humble experience.

Really dump them???? (1)

Nicolay77 (258497) | more than 7 years ago | (#19294509)

Hey, I'm interested ^^

Besides that white paper do you have more info about it ?

Diet article (5, Informative)

billcopc (196330) | more than 7 years ago | (#19292209)

Maybe I'm being a cynical bastard again, but that article is REEEALLY light on content. Compared to the other featured articles from IBM, which are usually very rich and informative, this one is more like an "idiots guide to apache", the kind that belongs on Digg's mountain of filth. This is little more than a rehash of the Readme files for Apache and PHP combined. It's about as deep as telling a windows user how to make their PC faster by changing to the Windows NT theme. Of much greater value to web professionals is this article from a fellow OSDN site (!) Lighttpd can lighten Apache's load [linux.com]

Re:Diet article (1)

iknownuttin (1099999) | more than 7 years ago | (#19292265)

Maybe I'm being a cynical bastard again...

It's called being a realist and I, personally, don't think you should imply an apology - especially in this over-hyping everything day and age.

Re:Diet article (1)

mangu (126918) | more than 7 years ago | (#19292417)

Maybe I'm being a cynical bastard again,


Well, yes, I agree, you are being a cynical bastard. I just forwarded the link to a couple of people I know who could get some useful tips from that article. You see, not everyone is born knowing it all, some people can profit from stuff that others already know.


And also, information isn't like money, that you want as much as possible. There is such a thing as information overload, information is something that you want exactly as much as you need, not a bit more. All in all, I think the IBM page is a good start for someone who needs to configure Apache and has been overwhelmed by all the data available.

Re:Diet article (1)

billcopc (196330) | more than 7 years ago | (#19293969)

I certainly agree with you about information overload. I often times find myself way over my head when all I need is an intro to some topic. This article is neither overloading nor introductory, and I think my biggest problem is that it misses the mark with regards to its target audience. It's offering these horribly basic configuration "tips" that would normally be the first thing a server admin would do, but trying to present them as "performance tips" is complete disinformation. I think the kind of readership on /. and IBM's tech blog would have wanted some nitty gritty on some new tricks to squeeze even more juice out of our already-tuned setups, like the very popular Lighttpd article I linked in my previous comment.

If it had been titled "How to properly configure your LAMP stack", I would probably have been ok with it. Actually I would have ignored it completely because such things are trivial to me. Calling them performance tips is unnecessary hype. What if it were about auto maintenance, titled "Optimize your engine and make your car go faster" when it was just a PSA about changing your oil regularly and checking your tire pressure ? My gripe is simply that this article claims to be something it's not. The information contained within is still accurate and valuable to some, that's something I can't deny.

Re:Diet article (1)

hachete (473378) | more than 7 years ago | (#19292629)

what's lighty like with mysql in the mix - I run a LAMP installation which could go faster ... an article on fine-tuning LAMP installations would be useful :-)

Re:Diet article (2, Informative)

Ythan (525808) | more than 7 years ago | (#19292903)

If you want to improve the performance of your database, you should check out Sphinx [sphinxsearch.com] to handle your fulltext searching. In my opinion this is one of the most criminally overlooked pieces of software when it comes to website optimization.

http is the problem (5, Funny)

larry bagina (561269) | more than 7 years ago | (#19292273)

Last year, we dumped apache (and http altogether) and went with a gopherd/fastcgi approach for serving up our php pages. For people still stuck on port 80, we have a squid proxy which converts the request to gopher. Since then, traffic has increased 34%, while average load has dropped by 20%.

Re:http is the problem (-1, Troll)

Anonymous Coward | more than 7 years ago | (#19292655)

If you don't know what Cmd-Shift-1 and Cmd-Shift-2 are for, GTFO.
If you think Firefox is a decent Mac application, GTFO.
If you're still looking for the "maximize" button, GTFO.
If the name "Clarus" means nothing to you, GTFO.

Bandwagon jumpers are not welcome among real [imageshack.us] Mac [imageshack.us] users [imageshack.us] . Keep your filthy, beige [imageshack.us] PC fingers to yourself.

Hello mac troll! (1)

Vexorian (959249) | more than 7 years ago | (#19294179)

Could you get more content? This one is pretty outdated, you used to take less time to update...

You can talk about this all day, but... (1)

sobolwolf (1084585) | more than 7 years ago | (#19292279)

Unless these recommendations can implemented in shared hosting environments they are of no real use to someone like me - ie web application designer. In regards to opcode caching I would go with Ioncube as there are runtimes available for most server environments.

Re:You can talk about this all day, but... (0)

Anonymous Coward | more than 7 years ago | (#19292321)

I don't bother with opcode caching any more. Longterm, I'm going to evaluate the roadsend compiler, caucho and plumhead with a view to replacing Zend for our legacy PHP code. I also expect that the language is going to be forked at some point unless the PHP developers clean up the function naming - it's infuriating.

Re:You can talk about this all day, but... (4, Informative)

tomhudson (43916) | more than 7 years ago | (#19292685)

"I also expect that the language is going to be forked at some point unless the PHP developers clean up the function naming - it's infuriating."

There's nothing to stop you from cleaning up the function naming. We'd all appreciate it :-)

Also, if you really want performance "uber alles", don't bother with apache or any other "pre-made" server - write a custom server in c designed to load modules that serve just the content you want served. You can then handle a thousand requests per second (including time to access the database a half-dozen times per request) on comodity hardware.

Its not like there isn't code out there that shows you how to implement a server in c, how to write and load modules in c, how to use threads in c, and how to access mysql via c. You'll be super fast ... except that your development time will be super slow.

apache+php is a compromose that most people can live with, most of the time.

Yes, the function naming in php is crap. Show us a scripting language where it isn't.

Re:You can talk about this all day, but... (0)

Anonymous Coward | more than 7 years ago | (#19292931)

> There's nothing to stop you from cleaning up the function naming. We'd all appreciate it :-)

You mean the patch or the resulting flamewar on internals:P

> write a custom server in c designed to load modules that serve just the content you want served.

Been there, done that.

> Yes, the function naming in php is crap. Show us a scripting language where it isn't.

lua [lua.org] ;-)

Re:You can talk about this all day, but... (1)

suv4x4 (956391) | more than 7 years ago | (#19293997)

Yes, the function naming in php is crap. Show us a scripting language where it isn't.

Well, the list is too long. First, not scriping languages, but just as fast and robust to develop in : .NET and Java. Then ECMAScript, Ruby, Python etc.

But I can give you very quickly the list of scripts that have as bad or worse function/feature consistency than php:

Re:You can talk about this all day, but... (1)

imroy (755) | more than 7 years ago | (#19294149)

Yes, the function naming in php is crap. Show us a scripting language where it isn't.

Perl [tnx.nl] , for one.

To summarise:

  • Arguments and return values are extremely inconsistent
  • PHP has separate functions for case insensitive operations
  • PHP has inconsistent function naming
  • PHP has no lexical scope
  • PHP has too many functions in the core
  • PHP lacks abstraction and takes TIMTOWTDI to bad extremes

Which all adds up to one thing: PHP is a simple language that's actually rather hard to program in. Or maintain.

Re:You can talk about this all day, but... (1)

julesh (229690) | more than 7 years ago | (#19292895)

Unless these recommendations can implemented in shared hosting environments they are of no real use to someone like me - ie web application designer

There are plenty of shared hosting providers who will let you use any apache/php settings you choose. I have a virtual server with bytemark, and have so far been quite happy with it. It doesn't cost a fortune, and is quite capable.

use perl; (1, Informative)

Anonymous Coward | more than 7 years ago | (#19292333)

[troll]Use Perl, mod_perl, profile your applications, and cache, cache, cache.[/troll]

Re:use perl; (1)

eneville (745111) | more than 7 years ago | (#19292639)

[troll]Use Perl, mod_perl, profile your applications, and cache, cache, cache.[/troll]
that's actually the best advice in this thread, caching that is. and perl does that well with hash lookups... so you dont need a db... just use bdb for most of the pages and get them from the bdb based on page url. that's much faster than dynamically creating the page and should be less of a resource hog overall.

Re:use perl; (0)

Anonymous Coward | more than 7 years ago | (#19293043)

Preoptimization sucks. Now if you wish to do anything DB related, you can't do anything too fancy because it's in a bdb. :P. Create the system sanely, then optimize w/ the complex heavy parts optimized.

Oh wait, I forgot this is php. Let's be clever!

Re:use perl; (1)

QuoteMstr (55051) | more than 7 years ago | (#19294269)

Amen. I think the premature optimization bit is a phase that most good programmers grow out of sooner or later. I've grown tired, though, of having to explain the concept. "No, allocating twelve objects really won't impact performance that much. You're going to be hitting the database with a huge query anyway. The memory allocation won't matter next to that!"

In the previous article (1, Interesting)

Anonymous Coward | more than 7 years ago | (#19292471)

In part 1 [ibm.com] of this series this was recommended...

"The first order of business is to ensure that atime logging is disabled on file systems. The atime is the last access time of a file, and each time a file is accessed, the underlying file system must record this timestamp. Because atime is rarely used by systems administrators, disabling it frees up some disk time. This is accomplished by adding the noatime option in the fourth column of /etc/fstab."

Can someone share their thoughts about this tweak? Is it safe to use from a data integrity perspective?

Re:In the previous article (0)

Anonymous Coward | more than 7 years ago | (#19292571)

> Can someone share their thoughts about this tweak?
> Is it safe to use from a data integrity perspective?

It's perfectly safe and also standard practice.

Re:In the previous article (1)

pooh666 (624584) | more than 7 years ago | (#19292573)

You don't have to access, what you have cached in memory.. If making this change affects performance, then you are hitting the disk too much anyway. The only exception I can think of is where you are server up a massive amount of distinct content, but even then some things get accessed a lot more often and caching can help with those.

Don't just make it up... (0)

Anonymous Coward | more than 7 years ago | (#19292633)

Read this instead [lighttpd.net]

Apache ain't the fastest... (4, Informative)

Anonymous Coward | more than 7 years ago | (#19292643)

It's common knowledge that Apache certainly isn't the fastest out there to server web pages. For static pages lighttpd and, heck, even a basic stand-alone Tomcat (yup, a Java server!) can easily serve as many pages as Apache. That was already the case for, say, Java 1.5 / Tomcat 5.5. Now take Java 1.6 and Tomcat 6 (or, better, Resin [not completely free]) and suddenly Apache is looking even more ridiculous.

For anything SSL related IIS makes fun of Apache.

For many concurrent sessions there are proof of concept servers written in functional languages (like erlang) that handle an order of magnitude (!) more simultaneous sessions than what Apache does.

I understand that for many here Apache is all they know and hence regard it as the holy grail but it is far, far, from being that. It is a good overall purpose web server but it is certainly not the fastest.

In the face of the countless security holes that are all too common in C-written apps I'm now more and more installing pure Java web servers. At first I was using Apache + Tomcat now I'm more and more using Tomcat in standalone mode. Easier configuration, no buffer overflows to patch.

Careful with the php accelerators (2, Informative)

graveyhead (210996) | more than 7 years ago | (#19292849)

I routinely experience Apache crashes while using eAccelerator, APC or Zend Optimizer, even with the latest stable PHP. If you use one of these products, be sure to also run some kind of watchdog that will restart httpd if (when) the stack crashes. They're totally worth running in any case. Zend Optimizer speeds up my Drupal installation by a huge amount because of the time saved parsing code.

You also should of course make sure you've got caching happening at every level of your app. Memcached is a great application level cache. Apache side, make sure you enable and configure the memory cache for static files. (mod_mem_cache) and possibly the file cache (mod_disk_cache). Client side, make sure you're caching static files like images, js, css. Apache's mod_expires gives you good control over this in Apache config.

Of course, all of this could be just spinning your wheels if you have badly optimized sql queries or bad table design to start with. Set mysql's slow query log threshold very low to catch these issues early.

Re:Careful with the php accelerators (1)

gazbo (517111) | more than 7 years ago | (#19292967)

I don't think you know what Zend Optimizer is.

Re:Careful with the php accelerators (1)

Billly Gates (198444) | more than 7 years ago | (#19293051)

You can try running php on Windows with IIS. Its alot more stable on the windows platform and IIS is no longer the POS it used to be. Also you may want to use a real mature language like java or .NET if you need stability and maturity. Php is very mixed.

Of course I am probably going to be modded down here on slashdot for such a posting.

Re:Careful with the php accelerators (1)

yabos (719499) | more than 7 years ago | (#19293221)

The username Billly Gates certainly doesn't help. :)

How to know? (1)

bigjoeystud (715224) | more than 7 years ago | (#19292851)

Is there an easy way to figure out where my bottlenecks are? We have a LAMP site that used to run fast, but with a new version of CentOS, it now runs real slow and I'm not sure why...

Re:How to know? (1)

QuoteMstr (55051) | more than 7 years ago | (#19294241)

Good question. The first step is to figure out where the slowness is coming from. Is the web server process waiting for database queries? Is the CPU pegged at 100%, or is the server waiting for disk IO?

I like to use atop [atconsultancy.nl] to figure these things out. It breaks down system resource use into a couple of distinct categories, like mem, cpu, and swap, and visually indicates which one is the limiting factor at the moment. It'll also tell you which processes are allocating and deallocating memory. It's not particularly user-friendly, but it's a powerful tool.

Also, if it turns out that a process _is_ using a lot of CPU time, and you can't figure out why, strace and httpd -X (which forces Apache to run with one worker) are your friends.

Of course, I'd still prefer to have dtrace in the Linux kernel. Maybe someday...

C code is one answer (3, Interesting)

Anonymous Coward | more than 7 years ago | (#19293083)

I had a customer (I am a contract programmer, working on a per-project basis) who had an emmense PHP / MySQL application that ran so slowly it was unuseable. We did every simple optimization such as is described in this article, and more. In the end, the issue was clearly that there was simply a lot of PHP code, and a lot of it using PHP's objects, and searches through arrays, and that sort of thing. The biggest performance increases we were getting was when we could push some sort of comparison or logic from PHP into the SQL query.

What we did was re-write all of the application except the parts that actually printed HTML to the page in C. We made that library into a php extension, which we added to our php installation. The speed ups varied according to the type of code, of course. MySQL queries changed hardly at all. A simple for loop might speed up from 100 to 1000 times, however, and a for loop that involved some sort of object oriented operations -- say, the creatation of a new object with each iteration, in an extreme example -- could be sped up from 10,000 to 100,000 times.

Now, most code that was sped up 100,000 times, when examined closely, could be sped up in PHP also by writing it smarter. But bad C code still runs faster than good PHP code.

If your disk drives are slow, or your code is printing a debugging log that has every function entry and exit to a network shared disk, or something like that, don't even think about C, just fix the basic problem first.

However, in my experience, twiddling the apache configs for "AllowOverride" and stuff like that will never get you as big a speed up as moving PHP code to C.

Note, that the way we did it, we moved all the core functionality and logic to a C library, but most of the display stuff was left in PHP. This meant that most ongoing development could continue to be done by cheaper, less skilled people who knew only PHP, MySQL, javascript, and CSS.

Re:C code is one answer (1)

pooh666 (624584) | more than 7 years ago | (#19293261)

Funny we did almost the same thing with mod_perl under PHP :)

Re:C code is one answer (0)

Anonymous Coward | more than 7 years ago | (#19293609)

Agreed. After everything is said and done, sometimes using C is a great choice when building a tight, fast component.

Re:C code is one answer (1)

QuoteMstr (55051) | more than 7 years ago | (#19294193)

What were you doing that took so much CPU time? Shouldn't all the heavy lifting have been done by the database anyway? IMHO, it's pretty bad design to put too much sorting, filtering, etc. logic in the client code anyway, regardless of whether that client code is written in C, PHP or INTERCAL.

That said, PHP is only a constant factor slower than C. A big constant factor, granted, but not 100,000. It appears that your perform improvement with the C rewrite came from algorithmic improvements, not a simple translation into machine code.

how abt direcly using Apache Modules.. (0)

Anonymous Coward | more than 7 years ago | (#19293383)

At my company we have our own C++ modules (no PHP layer) which we use to server our content.. though development takes more time we get solid performance...

Re:how abt direcly using Apache Modules.. (1)

QuoteMstr (55051) | more than 7 years ago | (#19294319)

Fair enough. But why should development with C++ take longer than with PHP, assuming that you're using a decent framework and a solid templating engine with both? Compile time ought to be negligible. You can develop faster with PHP only if you corners and don't adhere to good coding practices.

Performance tuning and optimization of LAMP (4, Informative)

kbahey (102895) | more than 7 years ago | (#19293589)

This is a set of articles on Drupal performance tuning and optimization for large web sites [2bits.com] . Although it says Drupal, much of it applies to the LAMP stack in general.

It includes:

  • PHP op-code caches / accelerators: Drupal large site case study
  • Benchmarking APC vs. eAccelerator using Drupal
  • Drupal core caching and contributed content caching modules
  • Installing eAccelerator 0.9.5.1 on Ubuntu Feisty 7.04
  • logwatcher: restart Apache after a segmentation fault
  • MySQL InnoDB: performance gains as well as some pitfalls
  • MySQL my.cnf configuration for a large Drupal site
  • Presentation: Performance tuning and optimization of high traffic Drupal sites
  • Tools for Performance Tuning and Optimization
  • Tuning the Apache MaxClients parameter
  • Links and resources on Drupal performance tuning and optimization


Disclaimer: this is stuff that I have written.

Just listen to this (-1, Troll)

Qbertino (265505) | more than 7 years ago | (#19293655)

Blah, Blah, PHP sux, Ruby rules, Blah, Blah, Ruby sux, Perl rules and is faster and more mature anyway, Jada , jada, Apache sux, lighthttpd 0Nwz0rZ, Blah, Blah, lighthttpd is only for special cases it sux in RL compared to Apache, Blah, Blah, APache is ultra l4m3 and OMFG! unsafe! Yeah!, Blah, Blah, the new MS IIS kicks all others in the butt Blah, Blah. crap article, Blah, Blah, good article but forgot to mention C is fastest for webapps, blah blah ...

Did you guys all get stoned for Pentecost or what?

The dialogs between my 9 year old daughter and friends over which Playmobile toy is better are more coherent than this.

Re:Just listen to this (0)

Anonymous Coward | more than 7 years ago | (#19293881)

Some of us make a living doing this and the tools we use on the server have one job. That job is to send content to the client as fast as possible. There are numerous tradeoffs in the architecture and configuration of web servers and scripting languages and when you're working with this stuff everyday the sub-optimal becomes irritating.

If it's all a bit over your head, I suggest you instead participate in discussions at a level you're more comfortable with.

HTH [playmobilusa.com]
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...