

Ask PG: Why the cookie change? - DanielBMarkham

Seems like in the last week or so, I keep having to go back to the login page. It didn't use to be that way.<p>It's annoying, and when you combine it with the new ClickPass option, it looks a lot like a "push" towards using that service.<p>Is there a technical reason for the new behavior? Is it related to the server slowness we had a while back? Apologies if somebody else has already asked this question.
======
run4yourlives
I'm pretty sure it's because they've been rebooting the server(s) more
frequently. It's related to that slowness that we were experiencing the other
day.

You'll notice that the first time you view your comments after a reboot, they
get loaded into memory, and the page takes forever to load.

------
pg
We're trying to fix the slowness.

~~~
icky
1\. Stash key-value pairs in signed cookies (salt + text + sha1 should be
fine; HMAC is even better-- I prefer a variant of HMAC where I concatenate the
client's IP address onto the first hash before hashing again with the second
key).

1a. Note that this only goes for key-value pairs you don't mind the user
seeing, but want to keep tamper-proof. Real secret stuff still needs to be
handled server-side.

2\. Display them javascriptically, and only verify/change things server-side
on login or POST. This lets you serve most pages as cached, static HTML!

2a. So if my username cookie is "[some 40-byte salted sha1hash]icky", then,
client-side, I could change the username or the hash, and the page's
javascript would display the new username for me (blindly chopping off the
first 40 bytes that form the hash), but if I tried to post, then the server
would detect the tampered cookie, and log me out. [Tampering with the display-
name client-side is something you can already do with the Firebug or Web
Developer plugins, so this really doesn't pose a problem].

3\. When a POST happens, just regenerate the cached page that it dirtied, and
dynamically serve it back to the poster.

4\. That's it! You now have turned nearly all of your read-only requests into
a static, cached page GET, which you can let Apache take care of without even
hitting your application server.

~~~
DanielBMarkham
icky -- don't know if you know it or not, but Paul's writing his own
application language, Arc, and testing it out on this board.

To my knowledge he is not using an Apache stack. In addition, he's doing a
keyed-continuations deal across loads/posts, so he's effectively keeping the
stack around for each user.

Really cool stuff, but I can see where memory can become an issue. He's
probably running into paging issues and trying this out as a fix.

At least I think that is the situation.

~~~
icky
> icky -- don't know if you know it or not, but Paul's writing his own
> application language, Arc, and testing it out on this board.

"Whoa, you mean this isn't wood shop class?" ;-)

> To my knowledge he is not using an Apache stack.

For static pages, there's no reason he can't stick an Apache in front.

> In addition, he's doing a keyed-continuations deal across loads/posts, so
> he's effectively keeping the stack around for each user.

That part might be tricky to optimize, but there ought to be a way, even then,
to avoid hitting the app server for static page loads.

 _Edit: Looking at the login cookie across page loads, it's just a session-id.
There is absolutely no reason that the app server ever need know about these
cached static page loads._

> Really cool stuff, but I can see where memory can become an issue. He's
> probably running into paging issues and trying this out as a fix.

He's also running into _state_ issues, since he's keeping all session state as
in-memory continuations, which is probably forcing him to keep news.yc on one
box.

One thing that might work is to come up with a way to serialize those
continuations, and store the key-value pairs in a memcached box. Then the app
server can become stateless again, and he can add more boxes.

~~~
TFrancis
> For static pages, there's no reason he can't stick an Apache in front.

For static pages, there no reason to stick Apache in front.

~~~
icky
> For static pages, there no reason to stick Apache in front.

Are you suggesting that static pages should hit the app server?

~~~
TFrancis
No I'm suggesting that static content be served by something lighter than
Apache.

