For the 37000th time. I never said a word about emulating any PostgreSQL features in PHP. The emulation comment was completely MySQL-related to get around a limitation that when you use prepared statements MySQL doesn't use the query cache. If you application can benefit from the query cache, then PHP has an option to emulate prepare/execute in PDO. You are reading a half-baked second-hand account of a talk I gave.
Yes, the MySQL numbers were without the query cache, although in this particular application the query cache helps quite a bit. And yes, fsync was off in PostgreSQL. I am not trying to convince you or anybody else really. The point of the talk was to show people how they could benchmark and profile something to get a real sense of where their application was spending most of its time. It just so happened that for this application MySQL was faster. I have plenty of experience with both, and there are use cases where both make sense.
That was a reference to the Expect header problem in Apache that was recently fixed and that not all the problems can be blamed on IE.
And yes, I do know my way around PostgreSQL. It's a good database, but no matter how you tweak it, it still has more connection overhead than MySQL does. And as I explained, I wasn't actually using the query cache in MySQL in the initial steps in this iterative optimization because MySQL's query cache doesn't kick in for prepare/execute queries. This isn't a PostgreSQL slam, it is simply pointing out that people should benchmark and profile their actual applications and understand the costs.
It is getting to be rather annoying. A quick email asking me whether the article was an accurate representation of what I actually said would certainly have been more useful, but instead the poster chose to go the other way and focus on the misquoted bits of the article. I have been doing this stuff a long time and have been slammed on/. countless times, but please, slam me for things I actually said or did.
Once again, I never said it was a good idea to "code around the features of PostgreSQL". I didn't write the article. I gave a talk at a conference. Someone was in the audience taking rather bad notes apparently, and he posted these notes as an article. What I showed was that if your problem fits what MySQL is good at, there are significant performance benefits from using it. It wasn't a PostgreSQL slam in any way. It was a "profile and choose the best and fastest tool for the job" statement.
Tested with 5, 10, 25 and 50. I tend to keep my Apache MaxClients low to keep latency low. You are better off getting a fewer number of concurrent connections in and out quickly than to try to handle hundreds of them slowly. The actual number of course depends on the horsepower of your server.
Sure, the more you can offload to the database, the better. Like I said, my point about emulating things in PHP was directed at MySQL's broken query cache implementation when using the prepare/execute API.
By the way, the "emualting PostgreSQL features in PHP" part was completely misquoted. I was explaining how MySQL's internal prepare/execute API is rather broken because if you use it you completely miss the query cache, so my suggestion is to turn on prepare/execute emulation in PDO while behind the scenes it will use the faster direct query api calls and thus will also hit the query cache. So this was actually a bit of a MySQL slam which was utterly misquoted. Trying to emulate PostgreSQL things in userspace PHP would be moronic.
PHP/FI was the second version, and it wasn't written in Perl. Neither was the first version. The first version of PHP replaced some Perl code which may be where this myth comes from.
You are basing this on a rather incomplete account of my actual talk. I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries, and I am not sure why me showing some Callgrind profiles and stating that MySQL is particular good at these things is frontpage slashdot material. Slow day?
And the "The Web is broken and it is all your fault" thing was just a bit of humour to wake people up for this 9am talk, but I guess it makes for good headlines.
Ever consider that folks like Chris and Jeremy might know a little bit more about what actually happened than your average/. crowd?
I know Tridge well, and if he says he didn't use BK to reverse engineer the protocol and file formats, or whatever else is involved, then he didn't. End of story. He is the most annoyingly honest person I know.
Having spoken with hundreds of these over the years, I can tell you that they make a fine weapon. And you can indeed swing them by their wire. The wireless part is between you and the receiver. What I think Neal meant was the kind where you have a little clip-on with a wire down to the transmitter typically stuffed into your pocket or clipped onto your belt. Swing that box full of heavy batteries with a bit of gumption and you have yourself a weapon.
Well, here we have only 1 optional arg and we can actually leave the order as is. With mysql_query() there are 2 so having the optional first is difficult.
But again, these are minor little things to change compared to converting schemas, stored procedures, triggers, etc. when you are moving from one database to another. At most you have to spend 10 minutes going through the prototypes for the 5 db-specific functions you used in your app.
Well, in that particular case they are swapped because you can't put an optional argument before a required one. In most apps you only talk to one database at a time so always putting in the link identifier (which is the MYSQL *mysql part of the low-level API call) was a bit of a hassle, so it was made optional.
Still, the name of the function and the way it works mimics the lower-level API, but yes, here and there we toss in a few changes for convenience. You can call it maintaining the spirit of the low-level API if you will.
Like I said, if you have trivial SQL, use one of the umpteen db abstraction layers that are out there for PHP, or know beforehand that you might need to switch databases and think ahead a little bit.
The order of arguments and the way the functions are laid out for each database are that way because they reflect the underlying API. People who already know the underlying API for a specific database are in heaven when they hit the PHP API for the database as there is nothing new to learn. And even better, they can use the per-database API documentation directly and have it apply to PHP.
You keep arguing the exact same point. You want the native db function to be an abstraction layer whereas the core of PHP provides a direct API interface to each database and pushing abstraction layers up a level. As far as I am concerned that gives you the best of both worlds, but I guess you don't see it that way.
Do you really believe that this was my plan? And even if it was, do you think I succeeded? The online docs are freakin' excellent if you ask me, and I will be the first to tell you that you do not need to buy the dead-tree O'Reilly book in order to use PHP. Some people just like having a book they can sit and read on a train, plane or a beach without squinting at a screen. Plus, you don't look like such a geek if you are lying on a beach with a book vs. lying there with a laptop.
You probably also don't know the financials of publishing all that well. Trust me, this book is not going to make me rich even if every PHP user out there bought a copy. Keep in mind that my name is not the only one on this book. Hopefully it will cover various PHP-related travel expenses I always end up with going to conferences and user group meetings and also help with a computer upgrade and if I am lucky a fancy new laptop.
Before starting PHP I had actually done quite a bit of database programming using various languages including Perl. And I agree that database abstraction is useful in some cases, but as soon as your database needs go beyond trivial selects it all falls apart. Try switching from M$-SQL to Oracle halfway through a project. The fact that you used a database abstraction layer might save you 10 minutes of global search and replace on some db-specific function calls, but then you spend the next 3 weeks converting your schemas, stored procedures, triggers and the SQL itself. Try taking an Oracle query that includes DECODE() and make it work on some other database! A DB abstraction layer doesn't solve any of this. (Well, some try to solve the schema issue by forcing you to describe it in some generic XML format, but you still need to get in there and get your hands dirty to make sure the different types each db supports are handled correctly) When I write applications I write it with the databases I want it to run on in mind. I write database-specific functions to fetch data, update data, etc. I do this so I can use all the DB-specific performance tricks I can. And I will simply state that this application supports MySQL, PostgreSQL and Oracle, for example. If someone comes later on and tells me it needs to support another one, ok, then I add that support. For most dynamic web apps the bottleneck is the database. I am completely unwilling to trade performance for portability on that particular aspect. You don't trade away performance on the one critical factor in your architecture.
So, that is why database abstraction is not in the core of PHP and why PHP gives you access to all the intricacies of each database API. Others have layered abstraction layers on top of this low-level API support and that is fine, but PHP was originally designed as a tool for me to solve web problems and as such the design reflected my approach to web-database integration.
If every database conformed to standards and the SQL and schemas were portable, then yes, not using db abstraction would be asinine, but that is not the case, and it will never be the case as database vendors always want to distinguish their product from the next guy's.
I am not sure why you say mod_perl is more viable with Apache2 than PHP. PHP is every bit as threadsafe as mod_perl, and both PHP and mod_perl can be linked against many of the same libraries which may or may not be threadsafe. Something like libgd doesn't suddenly become threadsafe because it is accessed through mod_perl. Same for a very common library such as gdbm. These are the things that are holding up production-quality PHP (and mod_perl) with Apache2 threaded mpms.
There are actually FreeBSD kernel bugs coming into play here. For example, calling sendfile() in a thread was a problem. If you check FreeBSD CVS you will see that issue reported by someone from Apache and it has been fixed in the kernel.
You are better off using the open_basedir restriction instead of safe_mode for this. Set the open_basedir for each virtual host to that virtual hosts DocumentRoot and then PHP scripts will only be able to open files under that dir.
Of course, both open_basedir and safe_mode are crappy solutions to a problem that needs to be solved higher up. Like with the Apache2 perchild MPM, but that is a long way from being production quality on a couple of different levels.
Slashdot Mirror
For the 37000th time. I never said a word about emulating any PostgreSQL features in PHP. The emulation comment was completely MySQL-related to get around a limitation that when you use prepared statements MySQL doesn't use the query cache. If you application can benefit from the query cache, then PHP has an option to emulate prepare/execute in PDO. You are reading a half-baked second-hand account of a talk I gave.
Yes, the MySQL numbers were without the query cache, although in this particular application the query cache helps quite a bit. And yes, fsync was off in PostgreSQL. I am not trying to convince you or anybody else really. The point of the talk was to show people how they could benchmark and profile something to get a real sense of where their application was spending most of its time. It just so happened that for this application MySQL was faster. I have plenty of experience with both, and there are use cases where both make sense.
Even eliminating connection overhead, MySQL was faster in this case. There are also cases where you can't necessarily leave the connections up.
Yes, of course I showed how persistent connections improved things as well. That was an early step.
That was a reference to the Expect header problem in Apache that was recently fixed and that not all the problems can be blamed on IE.
And yes, I do know my way around PostgreSQL. It's a good database, but no matter how you tweak it, it still has more connection overhead than MySQL does. And as I explained, I wasn't actually using the query cache in MySQL in the initial steps in this iterative optimization because MySQL's query cache doesn't kick in for prepare/execute queries. This isn't a PostgreSQL slam, it is simply pointing out that people should benchmark and profile their actual applications and understand the costs.
It is getting to be rather annoying. A quick email asking me whether the article was an accurate representation of what I actually said would certainly have been more useful, but instead the poster chose to go the other way and focus on the misquoted bits of the article. I have been doing this stuff a long time and have been slammed on /. countless times, but please, slam me for things I actually said or did.
Exactly. But it makes a much more interesting /. story to take an imcomplete account of a talk and further mangle it.
Once again, I never said it was a good idea to "code around the features of PostgreSQL". I didn't write the article. I gave a talk at a conference. Someone was in the audience taking rather bad notes apparently, and he posted these notes as an article. What I showed was that if your problem fits what MySQL is good at, there are significant performance benefits from using it. It wasn't a PostgreSQL slam in any way. It was a "profile and choose the best and fastest tool for the job" statement.
Tested with 5, 10, 25 and 50. I tend to keep my Apache MaxClients low to keep latency low. You are better off getting a fewer number of concurrent connections in and out quickly than to try to handle hundreds of them slowly. The actual number of course depends on the horsepower of your server.
Sure, the more you can offload to the database, the better. Like I said, my point about emulating things in PHP was directed at MySQL's broken query cache implementation when using the prepare/execute API.
By the way, the "emualting PostgreSQL features in PHP" part was completely misquoted. I was explaining how MySQL's internal prepare/execute API is rather broken because if you use it you completely miss the query cache, so my suggestion is to turn on prepare/execute emulation in PDO while behind the scenes it will use the faster direct query api calls and thus will also hit the query cache. So this was actually a bit of a MySQL slam which was utterly misquoted. Trying to emulate PostgreSQL things in userspace PHP would be moronic.
PHP/FI was the second version, and it wasn't written in Perl. Neither was the first version. The first version of PHP replaced some Perl code which may be where this myth comes from.
You are basing this on a rather incomplete account of my actual talk. I went through a series of optimizations of a sample Web application, and one of many steps was to try MySQL instead of PostgreSQL for that particular application. By profiling it with Callgrind it was obvious that in this particular case MySQL was significantly faster. I don't think this is news to anybody that MySQL is quicker at connecting and issueing simple queries, and I am not sure why me showing some Callgrind profiles and stating that MySQL is particular good at these things is frontpage slashdot material. Slow day?
And the "The Web is broken and it is all your fault" thing was just a bit of humour to wake people up for this 9am talk, but I guess it makes for good headlines.
How much?
Ever consider that folks like Chris and Jeremy might know a little bit more about what actually happened than your average /. crowd?
I know Tridge well, and if he says he didn't use BK to reverse engineer the protocol and file formats, or whatever else is involved, then he didn't. End of story. He is the most annoyingly honest person I know.
Having spoken with hundreds of these over the years, I can tell you that they make a fine weapon. And you can indeed swing them by their wire. The wireless part is between you and the receiver. What I think Neal meant was the kind where you have a little clip-on with a wire down to the transmitter typically stuffed into your pocket or clipped onto your belt. Swing that box full of heavy batteries with a bit of gumption and you have yourself a weapon.
Well, here we have only 1 optional arg and we can actually leave the order as is. With mysql_query() there are 2 so having the optional first is difficult.
But again, these are minor little things to change compared to converting schemas, stored procedures, triggers, etc. when you are moving from one database to another. At most you have to spend 10 minutes going through the prototypes for the 5 db-specific functions you used in your app.
Well, in that particular case they are swapped because you can't put an optional argument before a required one. In most apps you only talk to one database at a time so always putting in the link identifier (which is the MYSQL *mysql part of the low-level API call) was a bit of a hassle, so it was made optional.
Still, the name of the function and the way it works mimics the lower-level API, but yes, here and there we toss in a few changes for convenience. You can call it maintaining the spirit of the low-level API if you will.
Like I said, if you have trivial SQL, use one of the umpteen db abstraction layers that are out there for PHP, or know beforehand that you might need to switch databases and think ahead a little bit.
The order of arguments and the way the functions are laid out for each database are that way because they reflect the underlying API. People who already know the underlying API for a specific database are in heaven when they hit the PHP API for the database as there is nothing new to learn. And even better, they can use the per-database API documentation directly and have it apply to PHP.
You keep arguing the exact same point. You want the native db function to be an abstraction layer whereas the core of PHP provides a direct API interface to each database and pushing abstraction layers up a level. As far as I am concerned that gives you the best of both worlds, but I guess you don't see it that way.
Except split() is not an alias for explode(). One takes a regex, the other doesn't.
Do you really believe that this was my plan? And even if it was, do you think I succeeded? The online docs are freakin' excellent if you ask me, and I will be the first to tell you that you do not need to buy the dead-tree O'Reilly book in order to use PHP. Some people just like having a book they can sit and read on a train, plane or a beach without squinting at a screen. Plus, you don't look like such a geek if you are lying on a beach with a book vs. lying there with a laptop.
You probably also don't know the financials of publishing all that well. Trust me, this book is not going to make me rich even if every PHP user out there bought a copy. Keep in mind that my name is not the only one on this book. Hopefully it will cover various PHP-related travel expenses I always end up with going to conferences and user group meetings and also help with a computer upgrade and if I am lucky a fancy new laptop.
Before starting PHP I had actually done quite a bit of database programming using various languages including Perl. And I agree that database abstraction is useful in some cases, but as soon as your database needs go beyond trivial selects it all falls apart. Try switching from M$-SQL to Oracle halfway through a project. The fact that you used a database abstraction layer might save you 10 minutes of global search and replace on some db-specific function calls, but then you spend the next 3 weeks converting your schemas, stored procedures, triggers and the SQL itself. Try taking an Oracle query that includes DECODE() and make it work on some other database! A DB abstraction layer doesn't solve any of this.
(Well, some try to solve the schema issue by forcing you to describe it in some generic XML format, but you still need to get in there and get your hands dirty to make sure the different types each db supports are handled correctly)
When I write applications I write it with the databases I want it to run on in mind. I write database-specific functions to fetch data, update data, etc. I do this so I can use all the DB-specific performance tricks I can. And I will simply state that this application supports MySQL, PostgreSQL and Oracle, for example. If someone comes later on and tells me it needs to support another one, ok, then I add that support. For most dynamic web apps the bottleneck is the database. I am completely unwilling to trade performance for portability on that particular aspect. You don't trade away performance on the one critical factor in your architecture.
So, that is why database abstraction is not in the core of PHP and why PHP gives you access to all the intricacies of each database API. Others have layered abstraction layers on top of this low-level API support and that is fine, but PHP was originally designed as a tool for me to solve web problems and as such the design reflected my approach to web-database integration.
If every database conformed to standards and the SQL and schemas were portable, then yes, not using db abstraction would be asinine, but that is not the case, and it will never be the case as database vendors always want to distinguish their product from the next guy's.
I am not sure why you say mod_perl is more viable with Apache2 than PHP. PHP is every bit as threadsafe as mod_perl, and both PHP and mod_perl can be linked against many of the same libraries which may or may not be threadsafe. Something like libgd doesn't suddenly become threadsafe because it is accessed through mod_perl. Same for a very common library such as gdbm. These are the things that are holding up production-quality PHP (and mod_perl) with Apache2 threaded mpms.
There are actually FreeBSD kernel bugs coming into play here. For example, calling sendfile() in a thread was a problem. If you check FreeBSD CVS you will see that issue reported by someone from Apache and it has been fixed in the kernel.
You are better off using the open_basedir restriction instead of safe_mode for this. Set the open_basedir for each virtual host to that virtual hosts DocumentRoot and then PHP scripts will only be able to open files under that dir.
Of course, both open_basedir and safe_mode are crappy solutions to a problem that needs to be solved higher up. Like with the Apache2 perchild MPM, but that is a long way from being production quality on a couple of different levels.