I jsut upgraded to 0.13, and my application is very slow now. I''m still in development using webrick. I did apply changeset 1752 from here http://dev.rubyonrails.com/changeset/1752 but had no change in my application performance. Does anyone out there have any suggestions?
> I jsut upgraded to 0.13, and my application is very slow now. I''m still > in development using webrick. I did apply changeset 1752 from here > http://dev.rubyonrails.com/changeset/1752Could you give us some more to go on? Is the application also slow in production mode? Have you tried narrowing down the slow parts using the benchmark helper? Have you checked whether it''s the action processing that''s slow (with a very simple Hello World action) or if its only happening in complex actions? Answers to these questions will help us find any issues. Thanks. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
Ok, here are some details. I don''t know what will help you out the
most,
so I''ll just try to answer your questions using my limited knowledge.
Switching the environment to "production" seems to make no difference
at
all.
A simple operation in my application is finding/displaying a location.
Using script/benchmarker I get something like this:
script/benchmarker 1 ''Location.find(3)''
user system total real
#1 0.060000 0.000000 0.060000 ( 0.110743)
In the view that displays this, I used the benchmark helper around it to
give me this:
Show location (0.06354)
Completed in 0.89753 (1 reqs/sec) | Rendering: 0.24893 (27%) | DB:
0.08958 (9%)
The above is fairly typical as I display one location after another. The
numbers don''t seem to add up, and/or I don''t know what the
numbers are
supposed to indicate.
A complex action is to display a schedule for someone. A 5 day work-week
schedule with a few events in it takes much longer than it did in
0.12.1. I have created my own Schedule class, and ran the benchmarker
script on it:
script/benchmarker 1
''Schedule.new(Perspective.new(ScheduleEventAttendee.find(1)),
Date.new(2005,6,6), Date.new(2005,6,10))''
user system total real
#1 1.410000 0.000000 1.410000 ( 1.470003)
These number seem reasonable, since the application under 0.12.1 took
about 2 seconds to display a schedule. There is a lot of database work
done in this action, but it seems to be the rendering that takes all the
time, or possibly something else. When going through the application and
using the benchmark helper in the schedule view, I get these numbers
when viewing the same schedule:
Display Schedule (11.64090)
Completed in 15.97526 (0 reqs/sec) | Rendering: 11.74090 (73%) | DB:
0.15579 (0%)
This same query run under the "production" environment gives:
Display Schedule (15.93863)
Completed in 20.40290 (0 reqs/sec) | Rendering: 16.01285 (78%) | DB:
0.12349 (0%)
3/4 of the time spent "rendering" seems like a lot to me.
I''ve been following the thread on this list titled "0.13 slower,
or
fastcgi not working anymore?", and the tip there was to install native
mysql drivers using "gem install mysql". I''ll try this, but
I''m
sceptical since it doesn''t seem to be the database that''s
slower, it''s
the rendering.
I did make a very simple controller and view as follows:
class SimpleActionController < ApplicationController
def simple
#do nothing
end
end
--- simple.rhtml ---
<% benchmark ''Simple Action'' do %>
Simple Action
<% end %>
Results were this:
Processing SimpleActionController#simple (for 192.168.1.22 at Thu Jul 07
16:33:56 MDT 2005)
Parameters: {"action"=>"simple",
"controller"=>"simple_action"}
Rendering simple_action/simple (200 OK)
Simple Action (0.00002)
Completed in 0.00803 (124 reqs/sec) | Rendering: 0.00273 (34%)
[http://192.168.1.22/simple_action/simple]
I hope these details are helpful. Let me know if there is anything else
I can provide.
David Heinemeier Hansson wrote:>>I jsut upgraded to 0.13, and my application is very slow now.
I''m still
>>in development using webrick. I did apply changeset 1752 from here
>>http://dev.rubyonrails.com/changeset/1752
>
>
> Could you give us some more to go on? Is the application also slow in
> production mode? Have you tried narrowing down the slow parts using
> the benchmark helper? Have you checked whether it''s the action
> processing that''s slow (with a very simple Hello World action) or
if
> its only happening in complex actions?
>
> Answers to these questions will help us find any issues. Thanks.
Matthew Thill <mithill@...> writes:> > I jsut upgraded to 0.13, and my application is very slow now. I''m still > in development using webrick. I did apply changeset 1752 from here > http://dev.rubyonrails.com/changeset/1752 > > but had no change in my application performance. > > Does anyone out there have any suggestions? >I have identical problems: rendering for 4 rows of 9 columns has gone from 10+ reqs/sec down to 1 req/sec. SQL time seems the same; rendering is the problem. John
On Jul 8, 2005, at 9:44 AM, John Norris wrote:> Matthew Thill <mithill@...> writes: > > >> >> I jsut upgraded to 0.13, and my application is very slow now. I''m >> still >> in development using webrick. I did apply changeset 1752 from here >> http://dev.rubyonrails.com/changeset/1752 >> >> but had no change in my application performance. >> >> Does anyone out there have any suggestions? >> >> > > I have identical problems: rendering for 4 rows of 9 columns has > gone from 10+ > reqs/sec down to 1 req/sec. SQL time seems the same; rendering is > the problem.There is something wrong with the benchmarks there. We were having severe performance problems in Backpack, and the benchmarks consistently showed that render time was the problem. However, as soon as we installed the native MySQL driver (as a last-ditch, don''t- know-what-else-to-try thing), everything was better. The render time benchmark went back down to expected levels and everything. So, if you''re using MySQL, consider installing the native driver and then check your numbers again. We''re not sure why the benchmark numbers seem to be off, but we''ll look into it. - Jamis
I rolled back to rails version 0.12.1 and everything is fast again. I
posted several benchmark results earlier in this thread, and it all
showed rendering as the bottleneck. However, you say there is something
wrong with the benchmarks.
I did read about the native driver, and I tried to install it myself but
ran into trouble. Here is what happened:
Attempting local installation of ''mysql''
Local gem file not found: mysql*.gem
Attempting remote installation of ''mysql''
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.6 for inspection.
ruby extconf.rb install mysql\nchecking for mysql_query() in
-lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
The gem_make.out file had no useful information, just a copy of the
above information. Can anyone provide some guidance?
Jamis Buck wrote:> On Jul 8, 2005, at 9:44 AM, John Norris wrote:
>
>> Matthew Thill <mithill@...> writes:
>>
>>
>>>
>>> I jsut upgraded to 0.13, and my application is very slow now.
I''m still
>>> in development using webrick. I did apply changeset 1752 from here
>>> http://dev.rubyonrails.com/changeset/1752
>>>
>>> but had no change in my application performance.
>>>
>>> Does anyone out there have any suggestions?
>>>
>>>
>>
>> I have identical problems: rendering for 4 rows of 9 columns has gone
>> from 10+
>> reqs/sec down to 1 req/sec. SQL time seems the same; rendering is the
>> problem.
>
>
> There is something wrong with the benchmarks there. We were having
> severe performance problems in Backpack, and the benchmarks
> consistently showed that render time was the problem. However, as soon
> as we installed the native MySQL driver (as a last-ditch, don''t-
> know-what-else-to-try thing), everything was better. The render time
> benchmark went back down to expected levels and everything.
>
> So, if you''re using MySQL, consider installing the native driver
and
> then check your numbers again. We''re not sure why the benchmark
numbers
> seem to be off, but we''ll look into it.
>
> - Jamis
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
I have exactly the same problem Matthew. I''m running on Linux if that has any bearing on this problem. Not sure either what steps to take to fix this problem (I''m a n00b to ruby and rails). Matthew Thill wrote:> I rolled back to rails version 0.12.1 and everything is fast again. I > posted several benchmark results earlier in this thread, and it all > showed rendering as the bottleneck. However, you say there is > something wrong with the benchmarks. > > I did read about the native driver, and I tried to install it myself > but ran into trouble. Here is what happened: > > Attempting local installation of ''mysql'' > Local gem file not found: mysql*.gem > Attempting remote installation of ''mysql'' > Building native extensions. This could take a while... > ERROR: While executing gem ... (RuntimeError) > ERROR: Failed to build gem native extension. > Gem files will remain installed in > /usr/local/lib/ruby/gems/1.8/gems/mysql-2.6 for inspection. > ruby extconf.rb install mysql\nchecking for mysql_query() in > -lmysqlclient... no > checking for main() in -lm... yes > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lz... yes > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lsocket... no > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lnsl... yes > checking for mysql_query() in -lmysqlclient... no > > The gem_make.out file had no useful information, just a copy of the > above information. Can anyone provide some guidance? > >
On 7/8/05, Matthew Thill <mithill-sK6dKysfGH7D0D/r9Z6QQA@public.gmane.org> wrote:> I did read about the native driver, and I tried to install it myself but > ran into trouble. Here is what happened: > [snip] > -lmysqlclient... no > checking for main() in -lm... yes > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lz... yes > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lsocket... no > checking for mysql_query() in -lmysqlclient... no > checking for main() in -lnsl... yes > checking for mysql_query() in -lmysqlclient... noYou need to point it to your mysql lib and include dirs, like this: sudo gem install mysql -- --with-mysql-include=/usr/local/mysql/include --with-mysql-lib=/usr/local/mysql/lib -- http://johansorensen.com http://theexciter.com
Having problems here too. Production mode is nice and snappy, but dev mode has turned into a cumbersome beast. Requests that used to take <1sec now take 5+ secs just to render. I''m not in a position to benchmark any of my code at the moment, but hopefully will have a chance later. As I said, production seems pretty snappy (which is ultimately what is most important, I suppose), but waiting 5-10secs for a page to load while developing can wear down on you after a while. Matt
Ran into this issue on Mac OS X. Seems to be a problem with the location
of the MySQL libraries. These steps fixed it for me:
cd /usr/local/lib/ruby/gems/1.8/gems/mysql-2.6
sudo ruby extconf.rb --with-mysql-dir=/usr/local/mysql
sudo gem install mysql
See also here:
http://wiki.rubyonrails.com/rails/show/MySQL+Database+access+problem
HTH
-----Original Message-----
From: rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org] On
Behalf Of Matthew Thill
Sent: Friday, July 08, 2005 12:59 PM
To: rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: Re: [Rails] Re: 0.13 very slow
I rolled back to rails version 0.12.1 and everything is fast again. I
posted several benchmark results earlier in this thread, and it all
showed rendering as the bottleneck. However, you say there is something
wrong with the benchmarks.
I did read about the native driver, and I tried to install it myself but
ran into trouble. Here is what happened:
Attempting local installation of ''mysql''
Local gem file not found: mysql*.gem
Attempting remote installation of ''mysql''
Building native extensions. This could take a while...
ERROR: While executing gem ... (RuntimeError)
ERROR: Failed to build gem native extension.
Gem files will remain installed in
/usr/local/lib/ruby/gems/1.8/gems/mysql-2.6 for inspection.
ruby extconf.rb install mysql\nchecking for mysql_query() in
-lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
The gem_make.out file had no useful information, just a copy of the
above information. Can anyone provide some guidance?
Jamis Buck wrote:> On Jul 8, 2005, at 9:44 AM, John Norris wrote:
>
>> Matthew Thill <mithill@...> writes:
>>
>>
>>>
>>> I jsut upgraded to 0.13, and my application is very slow now.
I''m
still>>> in development using webrick. I did apply changeset 1752 from here
>>> http://dev.rubyonrails.com/changeset/1752
>>>
>>> but had no change in my application performance.
>>>
>>> Does anyone out there have any suggestions?
>>>
>>>
>>
>> I have identical problems: rendering for 4 rows of 9 columns has
gone >> from 10+
>> reqs/sec down to 1 req/sec. SQL time seems the same; rendering is
the >> problem.
>
>
> There is something wrong with the benchmarks there. We were having
> severe performance problems in Backpack, and the benchmarks
> consistently showed that render time was the problem. However, as
soon > as we installed the native MySQL driver (as a last-ditch, don''t-
> know-what-else-to-try thing), everything was better. The render time
> benchmark went back down to expected levels and everything.
>
> So, if you''re using MySQL, consider installing the native driver
and
> then check your numbers again. We''re not sure why the benchmark
numbers > seem to be off, but we''ll look into it.
>
> - Jamis
>
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails
A big thanks to Johan for pointing me in the right direction. When installing, the default directories are /usr/local/include and /usr/local/lib. If you have mysql installed somewhere else, you must provide this information. You may have a /usr/local/mysql directory, and you would provide that location with this: sudo gem install mysql -- --with-mysql-dir=/usr/local/mysql The --with-mysql-dir assumes that under the given directory there are the directories include/ and lib/ that have what it needs. If you don''t know where the mysql libs are, look for one of the lib files, like libmysqlclient.a, to get the lib directory. The include directory will probably be nearby. All this said, it didn''t work for me because of some 64 bit library problem. I''m using an AMD64 machine, and I''ve had nothing but trouble compiling things on here. I''ve asked questions everywhere, but no-one can provide me with an answer. This is very off-topic here, but I''ll ask anyway in the hopes that someone in the know will see this post. OFF-TOPIC When compiling things, I often get a message similar to this: /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol'' can not be used when making a shared object; recompile with -fPIC If anyone knows how to resolve this, please let me know. Peter Bailey wrote:> I have exactly the same problem Matthew. I''m running on Linux if that > has any bearing on this problem. Not sure either what steps to take to > fix this problem (I''m a n00b to ruby and rails). > > > > Matthew Thill wrote: > >> I rolled back to rails version 0.12.1 and everything is fast again. I >> posted several benchmark results earlier in this thread, and it all >> showed rendering as the bottleneck. However, you say there is >> something wrong with the benchmarks. >> >> I did read about the native driver, and I tried to install it myself >> but ran into trouble. Here is what happened: >> >> Attempting local installation of ''mysql'' >> Local gem file not found: mysql*.gem >> Attempting remote installation of ''mysql'' >> Building native extensions. This could take a while... >> ERROR: While executing gem ... (RuntimeError) >> ERROR: Failed to build gem native extension. >> Gem files will remain installed in >> /usr/local/lib/ruby/gems/1.8/gems/mysql-2.6 for inspection. >> ruby extconf.rb install mysql\nchecking for mysql_query() in >> -lmysqlclient... no >> checking for main() in -lm... yes >> checking for mysql_query() in -lmysqlclient... no >> checking for main() in -lz... yes >> checking for mysql_query() in -lmysqlclient... no >> checking for main() in -lsocket... no >> checking for mysql_query() in -lmysqlclient... no >> checking for main() in -lnsl... yes >> checking for mysql_query() in -lmysqlclient... no >> >> The gem_make.out file had no useful information, just a copy of the >> above information. Can anyone provide some guidance? >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
On 7/8/05, Matthew Thill <mithill-sK6dKysfGH7D0D/r9Z6QQA@public.gmane.org> wrote:> OFF-TOPIC > > When compiling things, I often get a message similar to this: > /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): > relocation R_X86_64_32 against `a local symbol'' can not be used when > making a shared object; recompile with -fPIC > > If anyone knows how to resolve this, please let me know.To answer your off-topic query. Do what it says... try this: env CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure (for autoconf-based installation) I''m not sure this''ll work, but you could try it for gems as well. env CFLAGS=-fPIC CXXFLAGS=-fPIC gem install mysql Cheers, bs.
Thanks for the idea. I gave it a try, but received a similar error to before. The compilation occurs with the fPIC flag, but it seems that it wants (or wanted) the mysql libraries compiled with this flag as well. I''m a C compiler rookie. Here is the complete output: sudo env CFLAGS=-fPIC CXXFLAGS=-fPIC gem install mysql -- --with-mysql-dir=/usr/local/mysql Attempting local installation of ''mysql'' Local gem file not found: mysql*.gem Attempting remote installation of ''mysql'' Building native extensions. This could take a while... mysql.c: In function `row_seek'': mysql.c:983: warning: cast from pointer to integer of different size mysql.c: In function `row_tell'': mysql.c:990: warning: cast from pointer to integer of different size /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol'' can not be used when making a shared object; recompile with -fPIC /usr/local/mysql/lib/libmysqlclient.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [mysql.so] Error 1 /usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): relocation R_X86_64_32 against `a local symbol'' can not be used when making a shared object; recompile with -fPIC /usr/local/mysql/lib/libmysqlclient.a: could not read symbols: Bad value collect2: ld returned 1 exit status make: *** [mysql.so] Error 1 ruby extconf.rb install mysql -- --with-mysql-dir=/usr/local/mysql checking for mysql_query() in -lmysqlclient... no checking for main() in -lm... yes checking for mysql_query() in -lmysqlclient... no checking for main() in -lz... yes checking for mysql_query() in -lmysqlclient... yes checking for mysql_ssl_set()... yes checking for mysql.h... yes creating Makefile make gcc -fPIC -g -O2 -I. -I/usr/local/lib/ruby/1.8/x86_64-linux -I/usr/local/lib/ruby/1.8/x86_64-linux -I. -DHAVE_MYSQL_SSL_SET -DHAVE_MYSQL_H -I/usr/local/mysql/include -c mysql.c gcc -shared -L''/usr/local/mysql/lib'' -Wl,-R''/usr/local/mysql/lib'' -L''/usr/local/lib'' -Wl,-R''/usr/local/lib'' -o mysql.so mysql.o -lmysqlclient -lz -lm -ldl -lcrypt -lm -lc make install gcc -shared -L''/usr/local/mysql/lib'' -Wl,-R''/usr/local/mysql/lib'' -L''/usr/local/lib'' -Wl,-R''/usr/local/lib'' -o mysql.so mysql.o -lmysqlclient -lz -lm -ldl -lcrypt -lm -lc Successfully installed mysql-2.6 Ben Schumacher wrote:> On 7/8/05, Matthew Thill <mithill-sK6dKysfGH7D0D/r9Z6QQA@public.gmane.org> wrote: > >>OFF-TOPIC >> >>When compiling things, I often get a message similar to this: >>/usr/bin/ld: /usr/local/mysql/lib/libmysqlclient.a(libmysql.o): >>relocation R_X86_64_32 against `a local symbol'' can not be used when >>making a shared object; recompile with -fPIC >> >>If anyone knows how to resolve this, please let me know. > > > To answer your off-topic query. Do what it says... try this: > > env CFLAGS=-fPIC CXXFLAGS=-fPIC ./configure (for autoconf-based installation) > > I''m not sure this''ll work, but you could try it for gems as well. > > env CFLAGS=-fPIC CXXFLAGS=-fPIC gem install mysql > > Cheers, > > bs. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
> You need to point it to your mysql lib and include dirs, like this: > sudo gem install mysql -- > --with-mysql-include=/usr/local/mysql/include > --with-mysql-lib=/usr/local/mysql/lib >Thanks Johan, this did the trick. FWIW, my ancient MySQL install had files in: /usr/include/mysql /usr/lib/mysql John
you can also use gem install mysql --with-mysql-config that will use the mysql-config tool to figure out the paths for you. On 7/8/05, John Norris <john.norris99-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > > You need to point it to your mysql lib and include dirs, like this: > > sudo gem install mysql -- > > --with-mysql-include=/usr/local/mysql/include > > --with-mysql-lib=/usr/local/mysql/lib > > > > Thanks Johan, this did the trick. FWIW, my ancient MySQL install had files in: > > /usr/include/mysql > /usr/lib/mysql > > John > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Tobi http://www.snowdevil.ca - Snowboards that don''t suck http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog