Re: [PHP-DEV] Session management module - thoughts From: Juan A. Pons (jpons <email protected>)
Date: 05/29/99

Zeev Suraski wrote:
>
> > I have to disagree. I was using phplib but moved away because of how
> > "heavy" it is. meaning that deploying a LARGE (read traffic not file
> > size) using PHPLIB was just not going to work. I rewrote session mgmt
> > system that is much more lightweight. Don't get me wrong I really like
> > PHPLIB, but it add too much overhead to our system. I think this SHOULD
> > really be a CORE differentiator between PHP and other systems such as
> > ASP or ColdFusion. Most people that have developed large sites using
> > thow two tehnologies have written their own session managment system,
> > simply becasue it just was not up to snuff, and relied on the NT
> > registry to save the data.
>
> That's clearly untrue. Most people don't need nor care about anything
> beyond the session management features they're given out of the box with
> ASP. I know many large web sites that rely on that and never found this
> support to be limited. Also, you have to realize that most people don't
> know nor care about how session management works. You should be thankful
> if they even know it relies on cookies. They just want to persist a
> variable across their web site, period.
> The number of people that do know and care about what's going on in their
> session management code are numerous, and are usually technically-capable
> enough to configure phplib. Performance won't be much of an issue with
> PHP 4.0.

I very much forward to 4.0. If it will allow me to use the full PHLIB
suite without the performance hit I will switch over to it as it does
some things more elegantly that I am.

STILL the biggest drawback in the ASP session mgmt model is that it is
compeletely machine based, there are solutions out there but none seem
that reliable. So that web users need to go back to the same server for
every request. If the server dies, the session info goes along with it.
If you are using only one server that's fine and dandy, but when you
are adding multiple systems to your application for load balancing and
fault tolerance configurations, this is not really useful.

 
> > I understand the need to cater to the average joe, and I also think this
> > is important, but PLEASE don't do this by sacrificing on the high end.
>
> As a rule, I'd think that the right thing to do is write something that's
> suitable for the average use, and not something fancy that nobody really
> uses.
>
> > As web sites and applications develop over time, sessions are going to
> > play a more and more important role on the eyes and minds of developers.
> > Implenting this in user space is fine, but you are doing it at the
> > expense of speed. For large sites this IS important.
>
> Not all that important, as I said. You can't compare PHP 4.0's
> performance with that of 3.0.

Excellent. I am very much lokking forward to it.

 
> > Beyond that I can't understand the thinking behind "dong it how
> > Microsoft does it is good enough" since when???? ASP Sucks, more because
> > of the patform that it runs into, second because it relies heavily in
> > MTS which is very unstable, but also because of it's session support.
> > Again it works well for small sites, but not heavy duty installatations.
>
> I never was a member in the 'ASP sucks' club, and technology-wise, there's
> a lot one can learn from Microsoft. The real question is 'since when is
> every thing that Microsoft makes NOT good enough?'. I rarely find people
> that actually blame Microsoft for what it has to be blamed; opensource
> junkies usually just bash it for the hell of it. Fact is that the vast
> majority of people will find ASP's session management framework to be all
> they could possibly ask for in a session management system, and a 5 year
> old can use it. Why add complexity and features where it's not necessary?

I am not an MS basher by default, (I am using Windows NT right now to
type this and use many other MS apps). ASP itself does not suck per-se,
it's more the entire platform. I do not find NT to be all that reliable,
specially under heavy load. I beleive quite a few people here would
agree with me.

 
> As a side note, I've yet to crash MTS. MTS is nothing but a simple
> container for DCOM objects, if you write an unstable object (or use one) -
> it's your fault. MTS itself won't crash by the way, only the server for
> that particular object will. I'm not particularly fond of MTS
> conceptually, but I can't blame it for instability.

I guess we disagree here, we have problems with MTS on a routine basis,
even when not using any DCOM objects. IIS 4.0 is tightly integrated with
MTS and we have seen less than desired reliablity on systems with just
IIS4.

 
> > This is by far my experience, the only people that don't complain are
> > people that are "low end" developers, people that just finished reading
> > "learn ASP in 10 days!" and now they consider themselves expert web
> > developers. I've seen more than my share of those. I think a lot of
> > people here have.
>
> They're most people and most users. There are hundreds of thousands of
> PHP users, I'd guess most of them aren't computer science majors. But I'm
> saying and stressing again. Personally, I wouldn't care about anything
> beyond what ASP has to offer when it comes to session management. And I
> am a CS major.

I agree and disagree with you on this one. One of the BEST features on
PHP is that it's easy to use by inexperienced developers (the number of
PHP users considering that there where printed reference books, is a
testament to this), but at the same time it does not cripple the
experienced developer. I agree that most of what is in ASP from a
session mgmt viewpoint is sufficient, but I STRONGLY disagree with the
session information storage model.

 
> > A good session mgmt system should allow you to use different containers
> > for your data, starting with databse servers. This about this, can you
> > think of an easier way to build in scalability and redundancy to you
> > system by storing session info on a lightweight, fast, reliable database
> > system, place a whole bunch of webservers in front, that access the
> > session server, this way when a user comes to your site it does not
> > matter which web server they hit, as it will fetch the session info from
> > the session db. if a server goes down the loser loses at most the
> > current transaction but not the rest of their state info. This is how we
> > are doing it. Now try doing this with the built in session support in
> > ASP or CF.
>
> That's a great example for what I said. Most people don't care about that
> sort of scalability. Those who do will probably not use PHP anyway but a
> tailored solution. Either way, we could add this sort of stuff in the
> future, it's simply not important at this time.

I disagree here with you, I know that there are a pretty substantial
number of users of PHP who have developed pretty sophisticated systems
with PHP. Some that are mission critical and receive millions of hits.

 
> > In addition to cookie base session tracking, ASP also supports URL
> > based session IDs, I think this is also crucial as it has been reported
> > that as much as 40% of the users out there have cookies turned off.
>
> Where's that 40% figure from? I'd imagine it's totally bogus. Again,
> considering Microsoft requires cookies enabled for well over half of its
> web site, I truly doubt they intentionally give up 40% of their users.
> You can say whatever you want about Microsoft, but they're not keen on
> losing users.

I am sure it came from CNET from an IDG report, I'll see if I can dig it
out.

 
> > a simple function like PHLIB's url() or purl() would not be too much to
> > ask from users to use in the URLs if they want sessions to work with
> > cookies disabled. They can choose to use it or not.
>
> That's true. I'd still avoid doing that since it renders the source much
> less readable, and also slightly decreases performance.

Agree but it it increases your user base.
 
> > I am not sure how much PHP4 will remedy this situation, but for sites
> > with lots of traffic this IS an issue!
>
> It will, and thus it isn't.

Again, I am very much looking forward to it.

 
> > Maybe the thing to do would be to have two levels of session mgmt, basic
> > and advanced.
>
> Again, as long as it doesn't harm the basic session management in any way,
> sure. If it hurts the basic session management development, though, by
> slowing down the development or by polluting it with many required
> arguments, I'm strictly against it.

I agree completely here. It's more important to get something for people
to use and then refine it after the fact, but it's extremely important
to make sure one keeps in mind future direction when designing the
architecture.

> > Zeev, please don't take this personally, this is not directed to you,
> > but merely my thoughts!
>
> Ditto.

This is what I like so much about the PHP community, lot's of very
stimulating discussions and arguments, and we are still civilized.

Thanks again!

-J 

--

----------------------------------------
|         http://motosite.com          |
| Your motorcycle resource on the web! |
----------------------------------------
|            Juan A. Pons              |
|          jpons <email protected>          |
|    '98 VFR800 - '88 NT650 (Hawk)     |
|         AMA 368441 - HRCA            |
----------------------------------------

--
PHP Development Mailing List   http://www.php.net/
To unsubscribe send an empty message to php-dev-unsubscribe <email protected>
For help: php-dev-help <email protected>