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.
Persistant session objects performances
Moderator: General Moderators
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.
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.
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.
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.
Shared memory
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)
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)
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.
- 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.
specific numbers
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).
PHP = language. ASP = server framework.
Try running PHP as a servlet under Tomcat - you'll have more 'application-level' flexibility.
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).
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.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 = language. ASP = server framework.
Try running PHP as a servlet under Tomcat - you'll have more 'application-level' flexibility.
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?
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?