Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
Marcus Börger wrote: At 03:52 30.05.2002, Yasuo Ohgaki wrote: Steve Meyers wrote: Well, you didn't try it with MySQL, which is significantly faster than Oracle and Postgres for most stuff. In any case, I agree that msession is probably a better solution -- I just think that having built-in MySQL session support would be a good thing for PHP. You can easily port session pgsql for mysql. BTW, as far as my benchmarks on session pgsql and files handler, they are almost equal. I didn't benchmark in detail, but I doubt mysql could be much faster than PostgreSQL. Just my guess. From my expirience postgres is slower if you use referential integrity (what you should do) but this you cannot do in mysql (and therefore it is some kind of data storage but not a real rdbms). Well, it's difficult to know which one is faster until we actually implement it. As Mark point it out, MySQL has difficulty also. Both have pros. and cons. PostgreSQL support transaction and row level lock, while MySQL supports lock or page level rocks. (3.x) Besides, MySQL manual states that it does not perform well when insert and update is concurrently performed. A-I 1.4 (which is the case for session management) I'm interested in how well MySQL does the job, too. I may write session mysql, but it won't happen in near future. -- Yasuo Ohgaki [EMAIL PROTECTED] E-mail address has been changed. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
Steve Meyers wrote: PostgreSQL support transaction and row level lock, while MySQL supports lock or page level rocks. (3.x) Besides, MySQL manual states that it does not perform well when insert and update is concurrently performed. A-I 1.4 (which is the case for session management) As I mentioned, MySQL does support row-level locking, transactions, etc. Please people, let's stop spreading the FUD of yesteryear about MySQL. In any case, the major performance hits for MyISAM tables in MySQL (which both of you seem to be referring to) come when you do selects that take a long time on tables that are updated a lot. That isn't the case with a session table -- all selects are one well-indexed row. Oops. My reference and memory is too old. I've read about it, but I forgot ;) MySQL(InnoDB table) supports row level lock. (I guess most users are not using InnoDB, isn't?) It seems you are assuming users are not updating session data, but they refer it mainly. I think many users, who implements login with session for example, update session data every time they access. MySQL performance may vary db backend to backend. InnoDB may perform well with concurrent insert/update. Deciding which one is faster is very specific to databse usage. Therefore, most commercial RDBMS licenses do not permit publishing benchmarks. My point is, disussing which database is faster is pointless without specific usage, including specific platforms and settings. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
I agree. Though I know we want to stay well away from bundling anything unnecessary with a base PHP installation, more sophisticated session support seems well warranted, possibly even enough to extend the capabilities of PHP's current built-in session management *and* include msession in some way. Chris Steve Meyers wrote: Well, you didn't try it with MySQL, which is significantly faster than Oracle and Postgres for most stuff. In any case, I agree that msession is probably a better solution -- I just think that having built-in MySQL session support would be a good thing for PHP. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
Steve Meyers wrote: Well, you didn't try it with MySQL, which is significantly faster than Oracle and Postgres for most stuff. In any case, I agree that msession is probably a better solution -- I just think that having built-in MySQL session support would be a good thing for PHP. You can easily port session pgsql for mysql. BTW, as far as my benchmarks on session pgsql and files handler, they are almost equal. I didn't benchmark in detail, but I doubt mysql could be much faster than PostgreSQL. Just my guess. -- Yasuo Ohgaki -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
On Sat, 25 May 2002, Andi Gutmans wrote: At 10:20 25/05/2002 -0400, [EMAIL PROTECTED] wrote: [...] Obviously I think msession is pretty good, but SRM works too. Regardless of which, or even either, PHP needs to make an ?enterprise? statement. That's indeed true. There is some discussion on the php-evang(elism) mailing list, but it needs to mature a little bit. Marginalizing this capability IMHO is not the right direction, I think there should, in fact, be a stronger push for this sort of capability to be built in by default. Agree with that too... but if something like this should be mainstream, all components should in be in the PHP source tree, including the daemon. I agree. I also think that a solution like msession should be pushed despite the work on SRM because many PHP programmers will not want to go in the SRM direction but will want a plug-and-play solution for the most common PHP 2-tier Apache - DB solution. msession is more more specialized for 'sessions' and thus far better for it than SRM, which is a different thing. Derick --- PHP: Scripting the Web - [EMAIL PROTECTED] All your branches are belong to me! SRM: Script Running Machine - www.vl-srm.net --- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
I probably don't have the background on msession that I need to make an intelligent comment, but here is an opinion of mine that is relatively on-topic. The regular session implementation in PHP is extremely flexible, right? Sure, since you can write your own functions to do things such as store session data in a database, etc. However, there is *nothing* to help the average developer implement a professional-grade state management system out of the box. At least, not that I'm aware of. Everyone will happily explain how sessions in PHP work and then follow with a recommendation to *not* use sessions as they work out of the box, because data is stored in /tmp, etc. Take a competing product, such as ColdFusion, and configuring a database to use to maintain session data is a simple option. The functions that power the database session activity are part of the engine itself, and they're very quick and efficient. Every developer doesn't have to reinvent that wheel. Running a cluster of servers is cake. It sounds like msession has more of an enterprise perspective, and it might just have a few benefits worth considering. Session management is a huge deal in enterprise-level Web development, and I don't have to tell you guys how many developers have no idea what they're doing. If we have code that helps people do things the right way, I think it would go a long way in helping PHP. Why has no one suggested that features in msession be incorporated into the standard session module? I sure would hate to think that personality conflicts are getting in the way here. On a different topic, has there ever been a serious discussion about embedding commands in the PHP engine that allow for PHP administration? For example, an administrator PHP application would come bundled with PHP, and when dropped into document root, it would allow for Web-based administration of PHP. There are ways to secure this type of a system such that other PHP applications couldn't just use the same functions to perform their own rogue administration. This system could also allow us to provide a database abstraction layer to PHP without users have to write their own or copy someone else's in the business logic itself. We could leave that type of code in the engine and probably make it much faster. Anyway, some random thoughts from a listener. Chris [EMAIL PROTECTED] wrote: I kind of went off in a huff yesterday with the whole PECL/pear issue with msession, it's over and lets move on. I did, however, want to explain *why* I think msession should be in the main code. In *big* websites, you need multiple web servers serving copies of the same data in a load balanced environment. The PHP session code, in its native state, can not manage this efficiently. You need some sort of external session management system. Putting aside msession or SRM for the moment, the capability of linking multiple PHP web servers is vital. As one scans the PHP site, it is not immediately obvious how this is done, or that it can be done at all. You have to do a bit of digging to figure out how to do it. I have worked as a software developer for almost 20 years now, and it has become obvious to me that people in charge of making technology decisions are not as technically savvy as we would like or is often assumed. They NEED to be spoon-fed. If they have to look for something, they will probably assume it does not exist and opt for the solutions that are marketed at them. Obviously I think msession is pretty good, but SRM works too. Regardless of which, or even either, PHP needs to make an ?enterprise? statement. Marginalizing this capability IMHO is not the right direction, I think there should, in fact, be a stronger push for this sort of capability to be built in by default. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP web farms (i.e. why msession or something likeit)
Daniel Lorch wrote: I'd like to make a suggestion here: What do you think of splitting up the current PHP Manual into three major parts: 1. Developing in PHP (for PHP users) 2. Extending PHP 3. PHP for System Administrators Part 3 would cover all topics interesting only to a system administrator, such as installing PHP, security issues (open_basedir, safe_mode, alternatives such as fastcgi, tweaking the configuration on a vhost basis, ..), installing PHP on web farms etc.. These topics usually don't interest the average PHP developer - why keep it in the same manual, then? What do you think about this? +1 - Maybe even consider adding to part 2 some documentation on developing PHP itself. Right now, one must read the few files on the Zend API, some coding standards, subscribe to this list, and use the force (read the source) - not that this approach is all bad. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
