Persistant session objects performances

PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!

Moderator: General Moderators

Post Reply
tanis
Forum Newbie
Posts: 5
Joined: Fri Jul 05, 2002 2:00 am
Contact:

Persistant session objects performances

Post by tanis »

Hello everyone!

Today I was thinking about a cart for an e-commerce application and I asked myself what would be the best way to do it in my application.
I've had previou experience with e-commerce products written for IIS in ASP and I still think that ASP has a big advantage in this kind of applications. I'm explaining why and I would like to know if there's a way to do the same with PHP that I am not aware of.

In ASP you can create a new object and save it as a Session variable. From now on, I can stay assured that by simply checking if the variable exists I know if there's a cart for the current user.
Whenever I feel the need to do so, I can dump the cart to a DB backend for later use and reload it if I loose the session.
This way of doing a cart has real good performances with IIS and I think it's due to the way IIS and ASP have been bounf together.

Months ago I tried doing something similar with PHP storing objects as session variables, but the performance was horrible. I think it is because of the way PHP handles session stuff. For every page you load, PHP is reloading the content of the session variables from a file and if you've got many objects or a very big one, it sits down.
I have already tried using a different approach by saving the cart in the DB and only using the session id along with the userid to retrieve the cart in every page. It's much faster but it's a waste of resources in my opinion.

The main problem seems to be that once I create an object I cannot make it persistant until the time I stop Apache. I don't know if there's a workaround or if this is just a limit of PHP.

I hope someone out there can snlighten me.
khayll
Forum Newbie
Posts: 6
Joined: Thu Jul 04, 2002 4:59 am

Post by khayll »

dunno what DB you are using, probably not MySQL if you do some commercial stuff. anyway in MySQL you can create a heap type table (which has some limitations) and you can use it to store your sessions, and it is way faster than using files. then you can simply store your cart in the session.

so perhaps you can check out your DB software if it support heap tables too.

p.s. I am using a session cart with files, and it work OK, though it is not a very popular shopping site.
tanis
Forum Newbie
Posts: 5
Joined: Fri Jul 05, 2002 2:00 am
Contact:

Post by tanis »

Heap tables are ok, but you have to be sure to update the table every time you make a modification to a variable inside the object or at least at the end of the script.
And it's a bit of overhead, too.

I was thinking about trying to use shared memory. Create the cart object in shared memory and store its memory handle in a session variable.
This way whenever I modify a property of my object I know it's going to be reflected in every other page without having to explicitly save the values.
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Shared memory

Post by BDKR »

Hey,

PHP does allow the use of shared memory using the shm_*() group of functions. This php.net/manual/en/ref.sem.php should get you where you need to go.

Later on,
Big Din K.R. (TRC)
tanis
Forum Newbie
Posts: 5
Joined: Fri Jul 05, 2002 2:00 am
Contact:

Post by tanis »

I have had a look at the documentation about the usage of shared memory with PHP and it has huge drawbacks, so I'm still not sure this is a good way to go. Any new idea?
User avatar
BDKR
DevNet Resident
Posts: 1207
Joined: Sat Jun 08, 2002 1:24 pm
Location: Florida
Contact:

Post by BDKR »

What are the drawbacks? Just curious.

BDKR
tanis
Forum Newbie
Posts: 5
Joined: Fri Jul 05, 2002 2:00 am
Contact:

Post by tanis »

Drawbacks mainly are:

- Shared memory allocation is limited. Its maximum size is set by the kernel.
- Every area of memory must be tagged with an id, but you can't be sure that another process is using the same id.
- Memory allocation is not dynamic. So you cannot predict how much space your objects are going to take if the size of variables changes during your script execution.
mgkimsal
Forum Newbie
Posts: 7
Joined: Wed May 22, 2002 12:16 pm

specific numbers

Post by mgkimsal »

Tanis, please give some numbers as to how you judge 'horrible' performance (or whatever word you used).

For smallish projects, the ASP system will give somewhat better performance for sessions, especially storing objects in sessions, because everything remains in memory (hits swap file when not enough memory). The PHP model dictates that nothing lives beyond the request - each request session info is rebuilt, either from disk, memory or database. As your project grows, or if you abuse the session concept(!), stuffing stuff in in-memory sessions doesn't scale because you'll need more than one web server.

The latest ASP (3) might be somewhat better, but I know earlier ASPs had problems storing objects in sessions. Yes, it worked, but depending on the object, you'd have memory leaks and/or poor performance (some objects weren't threaded properly, causing that object to get tied to one thread, meaning that session had to hold on to that thread when it wouldn't otherwise make sense to do so resource-wise).
The main problem seems to be that once I create an object I cannot make it persistant until the time I stop Apache. I don't know if there's a workaround or if this is just a limit of PHP.
PHP is a langauge. VBScript is a language. PHP running under Apache does not allow you to do what you're looking to do (just serialize the object and get it back next request!). VBScript on its own doesn't do this either - VBScript has server objects exposed to it which it can hook in to to provide this.

PHP = language. ASP = server framework.

Try running PHP as a servlet under Tomcat - you'll have more 'application-level' flexibility.
tanis
Forum Newbie
Posts: 5
Joined: Fri Jul 05, 2002 2:00 am
Contact:

Post by tanis »

You're right. I should give you some timings but I cannot at this exact time. I'll try to provide you some ASAP.

I totally agree with you that scalability is a problem when you're using sessions. But what I have in mind is that if I can track an user through its session id, I could force all his request to the same webserver. This should be doable.

Are you talking seriously about running PHP as a servlet under Tomcat? It sounds nice, but is it feasible?
Post Reply