Subject: RE: [hackers-il] Presentation about LAMP (= Linux, Apache, MySQL and Perl/PHP/Python)

From: Chen Shapira <[email-masked]>
Date: Wed, 16 Feb 2005 16:43:47 +0200

> Not entirely correct. If you have a busy web-site, (or a server serving
> several web-sites) in which requests are not a simple matter of a few
> database queries (but rather the server-side callbacks actually do
> something), then the speed that the requests are ran in does become an
> issue.
> Otherwise, how can you explain, why people upgrade the servers (tigris.org
> was upgraded and as a result became more responsive.), or use clusters of
> computers.
> 
> I agree that in most cases it makes little difference, and usually the
> server
> will be responsive enough.

I think you missed my point. Performance is a big issue; hardware has a big
impact on it. Programming languages have very small impact on performance.
I've never seen performance for a website improved by switching to a new
language. Switching to new storage or changing a data structure does help.
So, saying "Perl is faster than python" or whatever is really irrelevant and
can be misleading.

> In UNIX, if you want to run a program, you have no choice but to perform a
> fork() first. And why is having a fork() an issue?

The need to fork a new process per request, as opposed to having one process
handling all requests is one of the worse performance issues with CGI and
one of the biggest reasons it is barely used now days.
 > 
> > I suggest you learn a bit, databases are quite an
> > interesting subject this day; they are as complex as operating systems
> and
> > do very cool things with very cool technologies.
> 
> Do you mean that RDBMS are as complex as operating system kernels, or that
> they are as complex as whole operating systems?

I was thinking about kernels. They also need very optimized algorithms and
data structures. Disk usage issues, security issues, there is a lot in
common there. I'll probably write something about it one of these days.

> > Fast vs. Not so fast isn't even close to covering anything.
> 
> But it can be important.

It doesn't mean anything. It is like saying that cats are better than
parrots because they are faster.

Are they fast on small tables as well as huge ones? Maybe it is slow on huge
tables but have native partitions so it doesn't matter?
Are they faster on selects or on inserts? What select/insert ratio gives the
best performance? How well they optimize their stored procedures?
Are deletes fast? Is it possible to delete large amounts of data?
Do they run periodic statistics to optimize performance automatically? And
if they do, maybe gathering statistics cause so many performance issues that
it is practically unusable on 24x7 systems? Which storage systems can be
used with this DB to give great performance?

You can say that anyone listening to your lecture won't care about this, but
you'll be wrong. Anyone who cares about DB performance is interested in real
world situations and not just a meaningless "not so fast".

> > "has a lot of features that other servers don't" isn't that interesting.
> 
> If the database has a feature that other servers don't, then you don't
> need to
> implement it yourself, or change the DB schema to accomplish it, etc. It
> happened to me once when I ran into a MySQL limitation, for which I had to
> change the population of a table, and make sure it has a cross-product,
> instead of a less than that.

Yes, but you could at least give few sample features and why they are
interesting. Saying "more features" doesn't say anything. 

> > Databases are as important as the
> > programming languages, sometimes more, and they have lots of complex
> > parameters that can affect decisions.
> 
> By "parameters" do you mean parameters of varying between different RDBMS
> implementation.

Yes. Just like programming language can be judged by its readability,
performance, standard library, available programmers, easy to deploy, good
IDE, etc.
DBs can be judged by: Available DBAs, great support, easy to deploy,
enterprise features (like partitioning, good monitoring kits, etc.), debug
features (like a good profiler that doesn't crash the system when you use
it), optimization features, etc.

> > I do suggest you look into why Oracle
> > is faster than MySQL, how do they do this, in which cases it is
> important,
> > etc, etc.
> >
> 
> As far as I know, MySQL is considerably faster than Oracle, at least for
> small
> loads. Did you really mean this sentence as it is, or was it a typo?

I actually benchmarked it extensively for one of my customers. I couldn't
find one test in which MySQL was faster. It probably depends a lot on the
scenario, in that case I can bet the Oracle was optimized to its teeth
because Oracle and Open Source solution providers were competing for the
deal and Oracle can play tough. I would wonder why the OS provider couldn't
optimize his DB to match.
 
> > - Non-SQL dbs also include object based DBs. I think Zope has one.
> >
> 
> Hmmm... Object based DBs. I don't know how much people know this (I don't)
> and
> how useful they are, and/or how superior they are over Relational
> databases
> for web-developers needs.

I would mention them just for completeness. Every once in a while there is
an article saying that this is the next great thing. Even Oracle have OODB
solution.

> Not two codebases, true (that may have been a bad phrasing on my part),
> but
> nonetheless, a lot of code for each database. Sometimes, you need to work
> directly with SQL, and that's where the differences between the databases
> can
> bite you.

I think you are over emphasizing this point. It is possible to avoid writing
SQL directly (and it is much recommended), and it isn't such a huge
overhead. It is easier than writing code portable between Solaris and Linux.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Shlomi Fish <[email-masked]>
Date: Wed, 16 Feb 2005 17:52:13 +0200

Hi Chen!

I'll address the rest of your post at a later point.

On Wednesday 16 February 2005 16:43, Chen Shapira wrote:
> I think you are over emphasizing this point. It is possible to avoid
> writing SQL directly (and it is much recommended), and it isn't such a huge

I beg to differ, but writing code that compiles and runs on both Linux and 
Solaris (and other UNIX flavours) is not very hard, as long as you know what 
you're doing, use the right tools (autoconf, etc.), avoid common pitfalls, 
possibly make use of cross-platform abstraction libraries[1], and naturally 
test it everywhere. There's a lot of common ground between the different UNIX 
flavours, and it's not very hard to write software that compiles everywhere.

Take a look at the GNU software:

http://ftp.gnu.org/pub/gnu/

Almost all of it compiles and runs on Linux, Solaris and almost every other 
32-bit or above UNIX flavour you can throw at it. Some of it, also compiles 
on Windows and other non-UNIX operating systems. The same is true for a lot 
of other free and non-free software. Usually if a program is not portable to 
a certain UNIX flavour, it's because it uses some special mechanisms provided 
by a particular UNIX flavour.

Back at the time when all the proprietary database vendors ported their 
databases to Linux, an Informix enginner was asked what it took him to port 
one of the Informix servers to Linux. He answered: "We just typed 'make'.":

http://www.linuxjournal.com/article/3097

(and this was without having Linux in mind in the first place).

As for SQL compatibility: here's a small example: in PostgreSQL, log() is a 
base-10 logarithm, and ln() is the natural logarithm.[2] In MySQL, log() 
returns the natural logarithm, while log10() is the base-10 logarithm. [3] 
(there's also ln(), but I recall it wasn't there before).

This means that if you wish to calculate a logarithm in an SQL query, you need 
to construct specialized queries for both MySQL and PostgreSQL (and for every 
other database implementation you intend to support). And you have to do it 
at run-time, not at compile-time, which is the case for writing code portable 
between Linux and Solaris, and any other flavour of UNIX you'd like to 
support.

Regards,

	Shlomi Fish

[1] - http://vipe.technion.ac.il/~shlomif/abstraction/ (note: link to a my own 
resource)

[2] - http://www.postgresql.org/docs/8.0/interactive/functions-math.html

[3] - http://dev.mysql.com/doc/mysql/en/mathematical-functions.html

---------------------------------------------------------------------
Shlomi Fish      [email-masked]
Homepage:        http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

---

From: Elad Efrat <[email-masked]>
Date: Wed, 16 Feb 2005 18:37:02 +0200

Chen Shapira wrote:

[snipped]

may be related to the thread-

http://software.newsforge.com/software/04/12/27/1243207.shtml?tid=72&tid=29

from this it seems that the OS has pretty much a very big
affect on how your database performs. even though it
tested only mysql, i believe the results are very obvious
as to what OS you need to use if you run a heavy DB

(let me spoil it for you - linux 2.6 :)