Hi.

What is wrong with Apache, exactly? It is stable, fast, mature, well understood, well supported and most of all -- it works.

FWIW, while I agree that sockets support in PHP is very handy, PHP is quite frankly too slow for even moderate loads. Its worse than that as on Windows the the sockets implementation really only works synchronously so something like webserving is a complete non-starter there.

While I don't disagree that sockets provide many new and exciting opportunityes for PHP, supplanting the webserver is not one of them in my humble opinion. It makes a nice toy, perhaps a handy in-a-pimch development environment and the possibility of writing "local browser apps".

If anything, I think PHP needs to integrate MORE with Apache. Why oh why is authentication typically handled at the PHP application layer and not at the server layer?

Hi,
hanks for comments.
Nothing is wrong with Apache, really nothing.
But if you use PHP and Apache, you can't store session data in the memory between two requests. You have to store the data in a data base, or use PHP sessions.

Let me describe it in a concrete case.

Suppose you have a community, using PHP, Apache and a data base MySql Sqlite, Oracle etc.

1. You use PHP sessions, to store the session data. Its fast and it is simple.

After a few months, you have have lots of visitors, and you have to scale. You buy a new server, and build a server farm. Now you have a problem, because the data you stored in PHP sessions on server one, is not available on server two.

Now you store the session data in the data base. On server tow, you have to connect on each request to server one, in order to fetch the data from the data base. Now you have connection overhead and your application becomes slow.

But that is not all, you get more visitors, and you have to buy a new server (server three). Now you have a real problem. Your data base cannot server so many queries.

It becomes seriose, when you begin to replicate your data base.

So nothing is wrong with apache, but some thing is wrong with PHP and Apache on huge sites.

What you provide for an example is exactly the problem we're having - a large scale application, with a load balancer, means that sessions are unique to the server. our solution was to store the sessions in a database, but this means a higher query overhead. Unfortunately, PHP sockets are, in my opinion, still too experimental - but the concept is worthy of further experimentation.

PHP Sockets are still expermental, and I hope we get a robust sockets support soon.

I can see how a servlet environment adds a lot of niceties but I also know that adds alot of overhead that you beeter make use of or you are going to pay a performance penalty. And performance was what you were looking for when you decided to add more servers! My point is PHP does need to become Java unless it _really_ needs to. I believe memcached can provide a distributed session container with enough redundancy and speed for most medium to large applications. It requires smart code and that means a lot of work but it can be done.

My .02 cents,

Adrian Madrid