How to persist (PHP) sessions beyond shared memcache?

[Alex Kerr]

Hi,

I'm using standard PHP session stuff for my web app, which means session data is stored in App Engine's shared memcache. Google's docs state that this can get flushed so any logged in user sessions would fail. How exactly do I add use of Datastore (or Cloud Storage?) into this process so that memcache is still used unless it gets flushed in which case Datastore is referred to? Is there a way to do this that minimises Datastore reads & writes and thus minimises cost and latency? I'm ideally after code (or even pseudocode) or even better a drop-in library or class :)

Or, is a flush of the shared memcache so unlikely that it doesn't really matter?

Many thanks.

[Adam (Cloud Platform Support)]

I don't have a code sample, but you would need to create a custom session handler with session_set_save_handler() as per the suggestion provided in this post on Stack Overflow.

[Alex Kerr]

Thanks Adam. The poster on Stack Overflow says he's seeing shared memcache cleared every 10 minutes or less. Is this typical?

And, how does this compare with how often dedicated memcache is cleared - i.e. if I start paying for memcache does the flushing problem go away?

[Alex Kerr]

Actually further to my reply above, I found this old post recommending using Cloud Storage instead: https://groups.google.com/d/msg/google-appengine/ziMU2sXQg7c/5uat0Lxly2sJ

- is this a good idea? Seems like it at first glance for the reasons mentioned (esp caching in memcache anyway). And adapting the example session handler in the PHP docs should be easy I think: http://php.net/manual/en/class.sessionhandlerinterface.php

This would also be cheap given storage pricing and no data transfer costs either way (in the same region).

Can anyone see any drawbacks here? I'm assuming latency would be low enough to be feasible...? What about if there are a large number of users using my simultaneously - is there a limit to the number of simultaneous streams to/from Cloud storage via the "gs://" file interface?

I don't fully understand how cache would work here though (behind the scenes via the gs:// interface - for a read, how is it known whether a session file needs to be read from the cache or not, and if it's in the cache, what happens if an updated session file was previously written to Cloud Storage by the session handler?

Thanks!

Alex

On Tuesday, January 26, 2016 at 1:23:51 AM UTC, Adam (Cloud Platform Support) wrote:

[Adam (Cloud Platform Support)]

The frequency of cache clearances reported on the Stack Overflow is definitely not normal. The reason Memcache was chosen as the default session store is because it is cleared infrequently enough so as not to be noticed during the course of a single session, and session data is typically transient.

On PHP the Cloud Storage stream wrapper is probably the best choice actually, and it does cache file reads to Memcache. This is specific to PHP though as on the other runtimes Memcache caching is paired with Datastore (as is the case with NDB on Python and Objectify on Java), just some extra info.

[Alex Kerr]

Thanks very much Adam. What's the latency like on Cloud Storage - would it still be usable as a session store?

Also I thought I read somewhere that file writes to GCS (e.g. via the PHP wrapper) return immediately so don't hold up script execution (and thus response to the client) - is that correct?

Alex

[Adam (Cloud Platform Support)]

Writes using the GCS stream wrapper should be non-blocking (though you should be able to control the behavior using stream_set_blocking). Reads are cached, so latency should not be an issue. 

[Stuart Langley]

Writes using the GCS wrapper are most certainly blocking, and as they use URLFetch as the underlying transport then stream_set_blocking has no effect.

[Adam (Cloud Platform Support)]

Hmm that's right - there is no async URLFetch on PHP App Engine.