On Mon, Jun 04, 2012 at 06:34:57AM +0300, Serge wrote: > 2012/6/3 Toni Mueller wrote: > >> First, there can be rather large session directory, you probably don't > >> want ~365595 files to be always eating your RAM. > > Well, I much rather want that, or store the session data in memcache, > > which is almost the same thing, only with a different label. > > Memcache? (0_o) Imho, that's even worse than store it on tmpfs, since > memcache can just push your data off the cache and you'll get it lost even > without reboot. I can think of session data in memcache only as some hack > for load-balanced servers,
Not to be debated - yes, using memcached does create a headache or two, but also solves problems that are otherwise hard. Yes, reboots are rare enough (every few weeks at most) to ignore their adverse side effect on user's sessions - at least in my use cases. > but it requires careful memory configuration, otherwise users may find > themselves logged off in the middle of a chat. No objections here. > > Mind you, all these things are done to *prevent* the application from > > going to disk, and force it to stay in RAM. And that's exactly what > > I want. > > You already have a filesystem cache for that. Session data stays in RAM > if it is used. But it does not get lost when inactive for a few hours. Well, it doesn't. I have copious memory in a box that is highly underused (< 50%), but still find that interesting files, or file system data, are deleted from that cache. Which leads to very high access times in case I need this data. > Plain users I've seen expect their session to stay alive for days. I.e. > they have just checked the forum and then turned off PC. When tomorrow > they turn it on they expect to be still logged in. Hmmm. First, I'd say that this assumption on their behalf is wrong. Secondly, over here, people tend to be forcefully disconnected at least every 24 hours, forcing a new client IP, anyway. There is no sane way to keep users logged in under these circumstances. > They expect this to be true for everything (forums, blogs, web-email, > etc). It's a disaster for them to be logged off, it takes hours to > find a piece of paper where they wrote the password. They become angry > if 10 minutes ago they were logged in and now they aren't, they don't > care that I had to reboot the server. Looks like you have a vastly different user population, who also use a vastly different software. My clients' software packages just automatically re-connect, and re-login if possible, in the background. Even Outlook can do it. Not to mention flakey DSL or mobile connections that break your connection more frequently than that. > It could be that your users are different. Looks like it, yes. > Hardeding[1] stuff, you could get your soft faster just by specifying > your exact arch (-march=native). Also for example -fomit-frame-pointer > option for x86 can make short functions twice shorter and faster... Uh. Mentioning hardening and suggesting "omit-frame-pointer" in one sentence makes me shiver. No, I don't optimize for performance at that level, but rather go for portability and safety, if possible. Also, a quick Google search turns up this - maybe out of date - article: > http://timetobleed.com/gcc-optimization-flag-makes-your-64bit-binary-fatter-and-slower/ Also, from http://gcc.gnu.org/onlinedocs/gcc-4.6.2/gcc/Optimize-Options.html#Type-punning, it's unclear to me whether omit-frame-pointer will interfere with stack protection schemes, or which one takes precedence. I usually resort to trust in my fellow DDs to do the right things in this area... Kind regards, --Toni++ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120604094820.ga18...@spruce.wiehl.oeko.net
