There exist other MMO technologies for flash that scale much better than AMFPHP.
When building an MMO, consider how the backend will handle failure. Some level of failure from a really busy service is inevitable. The question is how many users are affected by a failure.
Scalability issues differ if the server side is a 'stateless' REST based protocol, or you are building a server that keeps state within server memory.
If you really put a load on AMFPHP, the AMF Serializer will drag the server's performance exponentially. It is simply not a linearly scalable algorithm to convert from Java to AMF serverside.
I've found that SmartFox Server (http://www.smartfoxserver.com/) is a good alternative (written in java) for multiplayer games. Its also extensible, using java. It works using Sockets, and the AMF serialization is done Client Side with the provided SmartFox ActionScript Library.
From a "quality of service" perspective, it would be intelligent to run multiple SmartFox processes on the server (running on different ports) and have each process only manage a few users. This way if a SmartFox process dies, the whole server ins't affected, only the few users being managed by that process.
A safe limit is < 15 users per process. In theory if your goal is to support 10000 simultaneous users on a server, you would have 667 SmartFox processes running on 667 different ports.
Of course this depends on the server side setup/logic, but in the simplest case, real-time MMO data from a client is simply replicated by SmartFox and broadcast to all the players connected to that process instance.
Remember, if you require further server logic, you can extend the SmartFox server with Java. But remember, the more you extend the Server, the more work is being done, and the less connections you can ultimately support (per server).
