MySQL Lists are EOL. Please join:

List:General Discussion« Previous MessageNext Message »
From:Tom Cunningham Date:June 24 1999 10:38pm
Subject:glibc 2.1 performance
View as plain text  
I went back through the archives and couldn't find anything about this, so
I figured I'd pipe in. I've been having all sorts of problems the last
couple of days benchmarking two machines. We have an old machine which
runs Red Hat 5.2 (glibc-2.0.7-29), and a new machine which runs Red Hat
6.0 (glibc-2.1.1-6). In every applicable benchmark I can find, the new
machine beats the pants off of the old one - usually by double the speed.
When we ran Apache Bench on a database CGI, the new machine started
choking and the old machine performed pretty well - note : I'm using the
*exact* same tables, and the *exact* same CGI. I got some advice here
earlier that it could be Apache::DBI, but it's not.

We started to doubt Apache Bench's results, so we came up with a little
script that would spawn off processes and time them overall. The new
machine (the fast one) started choking after three mysql processes).

Using DBI, Average time of Execution

Number of Forked
Processes	        Old Machine             New Machine
1                       0.0000399351            0.0000280142
2                       0.7026379704            0.4452039599
3                       1.3370873531            0.6005186637
4                       1.0571669936            1.6903942525
5                       1.2100330114            1.9079551935
10                      1.0757207990            2.2621705055
15                      1.2155478001            2.4058329980
20                      1.1691342056            2.4783635020
25                      1.1905063629            2.4859128809

I though possible that DBI could be the problem, so I started cat'ing a
file with some sql into /usr/local/bin/mysql. Results were similar...

Not Using DBI, Average Time of Execution

Number of Forked Processes      Old Machine             New Machine
1                               0.0000480413            0.0000369549
2                               0.8930709958            0.4044570327
3                               1.4173783064            0.5722350279
4                               0.9450037479            1.7844890058
5                               1.1190732002            1.8621887922
10                              1.0132551908            2.2462723970
20                              1.3192131996            2.4642879009
30                              1.1591543992            2.5852736672

Again, the new machine chokes after a fourth mysql process. 

I'm still confused by what might be causing this, but this Usenet post
might have something to do with it...

http://x23.deja.com/getdoc.xp?AN=474851996&search=thread&CONTEXT=930262832.1734541401&HIT_CONTEXT=930262265.1662714038&HIT_NUM=1&hitnum=1
Subject : performance bug in glibc2.1 linux 2.2?
Date: 1999/05/06

Has anyone encountered anything similar? I guess this will force us to
retreat to glibc 2.0, but I'd like to know whether anyone found a better
solution.

Thanks,

Tom


Thread
Persistent connections to db?Tom Cunningham23 Jun
  • Re: Persistent connections to db?Paul DuBois23 Jun
    • Re: Persistent connections to db?Tom Cunningham23 Jun
      • Re: Persistent connections to db?Daniel Koch23 Jun
        • DBD::mysql fails on two tests?Tom Cunningham24 Jun
          • glibc 2.1 performanceTom Cunningham25 Jun
            • Re: glibc 2.1 performance(Paul D. Smith)25 Jun
              • Re: glibc 2.1 performanceTom Cunningham25 Jun
                • Re: glibc 2.1 performanceathompso28 Jun
    • Re: Persistent connections to db?ed23 Jun
Re: glibc 2.1 performanceAndrew Dunstan25 Jun