J
Julian Tarkhanov
Hello Rubytalkers
I have a very odd problem here and thought that I should ask your
opinion. I got a test suite here
http://julik.textdriven.com/svn/tools/micro-apps/pasaporte/trunk/test/
it's for a little Camping app for OpenID. This is not PR, I mind you.
However, I have some issues running it on two of our machines. When I
run it
on my staging server:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
The test suite takes 3 seconds to run. Fine is that.
Then I run it on my home G4 (about 700 Mhz).
It takes 19-26 seconds (20ish). Ok.
Then I make a checkout on my dev machine at work (a quad G5, 5G RAM )
and run the suite here.
It takes a friggin' minute.
The test suite does nothing fancy except some crypto. When I do ruby-
prof both, I see the following at the top of the graph on the G5:
Thread ID: 3348220
Total: 12.55
%self total self wait child calls name
22.07 2.77 2.77 0.00 0.00 155 IO#read <<<<
this is suspicious!
4.30 0.54 0.54 0.00 0.00 45
OpenSSL::BN#mod_exp
3.51 0.44 0.44 0.00 0.00 1495 <Class:
ir>#[]
On the Ubuntu box the same shows:
Thread ID: 3084113660
Total: 4.92
%self total self wait child calls name
8.54 0.42 0.42 0.00 0.00 45
OpenSSL::BN#mod_exp
3.86 0.19 0.19 0.00 0.00 155 IO#read
I immediately suspect that something is blocking somewhere. Almost
anytime I try to see what's going on by hard-stopping a test with ctrl
+c I see a reference to
the ruby-yadis library trying to do an HTTP call.
Now comes the question. How should I proceed to eliminate this
problem? Mock the hell out of the HTTP calling part of ruby-yadis?
I mean, a quad 64bit machine like that cannot be so slow at running a
test suite like that and the only processor-dependent
thing I am using here is OpenSSL (the G5 and the dual xeon come
pretty close with the openssl-speed test). Did anybody have a problem
with Net::HTTP waiting too long
and/or blocking before it fails to make an HTTP connection on OS X?
I have a very odd problem here and thought that I should ask your
opinion. I got a test suite here
http://julik.textdriven.com/svn/tools/micro-apps/pasaporte/trunk/test/
it's for a little Camping app for OpenID. This is not PR, I mind you.
However, I have some issues running it on two of our machines. When I
run it
on my staging server:
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Xeon(TM) CPU 2.40GHz
The test suite takes 3 seconds to run. Fine is that.
Then I run it on my home G4 (about 700 Mhz).
It takes 19-26 seconds (20ish). Ok.
Then I make a checkout on my dev machine at work (a quad G5, 5G RAM )
and run the suite here.
It takes a friggin' minute.
The test suite does nothing fancy except some crypto. When I do ruby-
prof both, I see the following at the top of the graph on the G5:
Thread ID: 3348220
Total: 12.55
%self total self wait child calls name
22.07 2.77 2.77 0.00 0.00 155 IO#read <<<<
this is suspicious!
4.30 0.54 0.54 0.00 0.00 45
OpenSSL::BN#mod_exp
3.51 0.44 0.44 0.00 0.00 1495 <Class:
ir>#[]On the Ubuntu box the same shows:
Thread ID: 3084113660
Total: 4.92
%self total self wait child calls name
8.54 0.42 0.42 0.00 0.00 45
OpenSSL::BN#mod_exp
3.86 0.19 0.19 0.00 0.00 155 IO#read
I immediately suspect that something is blocking somewhere. Almost
anytime I try to see what's going on by hard-stopping a test with ctrl
+c I see a reference to
the ruby-yadis library trying to do an HTTP call.
Now comes the question. How should I proceed to eliminate this
problem? Mock the hell out of the HTTP calling part of ruby-yadis?
I mean, a quad 64bit machine like that cannot be so slow at running a
test suite like that and the only processor-dependent
thing I am using here is OpenSSL (the G5 and the dual xeon come
pretty close with the openssl-speed test). Did anybody have a problem
with Net::HTTP waiting too long
and/or blocking before it fails to make an HTTP connection on OS X?