Regarding a disk cache, I don't believe write acceleration is enabled on most drives due to the inherent danger. Battery-backed write caches in combination with a RAID controller aren't too uncommon, and those will indeed coalesce small write operations (as will the OS cache, I believe). Nonetheless, when I benchmarked the write speed of one of our new servers a few weeks ago (no battery backed write cache, but RAID 5 w/15k drives), I got nearly twice the throughput with 1MB writes as I did with 256K writes. I don't know if that slowing trend continues below 256K -- perhaps write coalescing would start to kick in at that point.
i was also talking about the OS cache. As i said if i look at a very simple load like i am clicking through the application my self. Then saving the page (the count in java) is almost everytime 0ms. Serializing is much higer lowest 32ms but can go through 200ms) Of course if the load gets much higher, and then i mean like our stress test. Then the serialization time and the saving time are getting closer to each other, because the disk/os cache is completely filled up. About saving bigger files.. Any idea's? combine pages when i see that there are multiply for one session? But how can i then read them back in easily, i need to build then some kind of filesystem in a filesystem == db.... By "rock solid" I meant more robust than a typical sticky session
environment. With a non-sticky session configuration, you don't care which other servers might or might not have the replicated session -- all servers have access to all sessions so any of them (including multiple nodes) can be pulled or can fail with no user interruptions.\
look for example the resins build in sticky session clustering. You do know and care that a session is replicated. But it is only replicated to one other server (its buddy) Of course if the main server and its buddy are both going done at the same time then you would loose sessions. but this is mostly true for all kind if RAID things (if in a typical RAID config 2 hd's at the same time are killed you could have a problem) If every server has to read in the session from the database (and do a select for update) for every request. That means deserializing and serializing for every request the complete session (complete can maybe be optimized...) That would mean a really performance penalty. While sessions will distribute evenly, what really matters with
regard to resource utilization is the distribution of individual requests and their operations. The finer grained model of distributing per request has an advantage in that the system as a whole reacts much faster to changing load (it's essentially instantaneous).
its just a matter of numbers. If you use sticky sessions with round robin new session creation it is very common that the load would be exactly the same over all the servers. one other pro for sticky sessions with buddy system is that you also gain memory. If for example you replicate to all servers then all the servers will have all the sessions in memory. with a buddy system this is with 2 servers ofcourse the same but then in drops (4 servers it is 50%)
That's not really an issue in a "typical" non-sticky session configuration: session data is read at the beginning of a request and, if the session is updated, written at the end of the request to a central database. The idea is to push concurrency issues to the database instead of handling them in code. The DB can handle simultaneous selects and/or updates from different servers easily and, if you want serialized requests, you can use SELECT FOR UPDATE or the equivalent lock when you read the session row.
and this is want i meant with synching over the complete cluster The gain you think you have is completely killed. Because all other servers that access the same session are waiting for the other on the complete. And cpu penalty for the deserialing and serializing of the session from and to the database again.. It's not a terribly elegant solution and it has a built-in
bottleneck, plus a single point of failure that can only be partially mitigated with database replication. However, it's extremely simple and can perform better than you might think.
i think resins buddy system will out run this system by far. And you don't have a single point of failure. To be clear -- I'm not trying to convince anyone that non-sticky
sessions are the holy grail of scalability. The advantages of sticky sessions (Igor brought up the cache data locality issue, and there are plenty of others) can easily outweigh the advantages of non- sticky sessions. I just think it's a viable option in certain situations. The more important point is that, imo, a web framework shouldn't dictate scalability choices if possible.
I think in all the web frameworks that are really session based. none sticky sessions don't have any advantages only drawbacks. At least i haven't heard any single advantages yet in the current thread. johan
