Forum Moderators: coopster
App server: Linux + PHP applications
DB server: Linux + MySQL
It is fast becoming clear to us that we are on the doorstep of having to adopt some scaling model that will propel us into the world of 99.9% availability as our current setup often comes to a grinding halt due to too many open httpd connections.
We are also wanting to build more apps on our framework which means that we may have to create highly specialized servers for providing authentication, or other types of highly specialized services.
Let me use an example:
Currently I am leaning towards writing our own daemons as very thin, high performance layers adopting our own protocol for message exchange as follows:
Server 1:
MySQL <--> logind
Server 2:
MySQL <--> App1
Server 3:
MySQL <--> App2
The thinking is that if App1 needs authentication, it will connect to logind which will do a query on the MySQL server and provide a structured response. If App2 needs authentication, it too will just connect to logind.
I am thinking of writing a unix sockets daemon in C for the logind and have the Apps use PHP sockets for communication to logind. I am also thinking of adopting very minimal protocol for data exchange and not going with XML or any known protocol.
I also feel like I don't want to go with SOAP or any web service type protocol as I get the feeling that the client server model is bloated and the libraries out there seem like a bit of a memory hog when it comes to this.
My question would be this ... what are your thoughts about scaling web apps this way, i.e. instead of clustering web apps and databases on tons of servers, to try and streamline by writing highly specialized daemons for data exchange?
Any pointers would be greatly appreciated.
we may have to create highly specialized servers for providing authentication, or other types of highly specialized services
but then you state that
instead of clustering web apps and databases on tons of servers
It is a bit confusing. Are you going to separate your services on multiple servers anyway? Well, either way, you can use the TCP/IP stack or go with your own socket. I can only offer one piece of experience in this area. I did a custom contract where we wrote over the network on an iSeries partitioned server, 1 physical box, multiple servers partitioned on the box, full redundancy throughout, from power to storage. Writing in this manner bypassed the limitations of the network architecture altogether because the iSeries was capable of writing over it's own internal backbone, bypassing the networking switches, etc. It was 300 times faster. Sweet piece of hardware, I'll tell you that much.
