[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2007-10-26 Thread Eric Sammons

Eric Sammons added the comment:

I have tested 2.4.4 and 2.5.1 from python.org and both suffer from the
exact same issue.  I have also compared ceval.c from 2.3, the last known
working copy and ceval.c from 2.4+ and found that ceval.c has undergone
some pretty significant changes.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2008-01-14 Thread Eric Sammons

Eric Sammons added the comment:

Please find the attached ceval.c.  This file was generated from oprofile
and gives clear indicators where the simple program below gets hung up.

You will find in the oprofile output, from ceval.c, that PyEval_Frame
has a total of 1649 26.2789.  This indicates with a high degree of
probabilty that the changes made in this portion of the code are
promblamatic.

Now I will be the first to admit that I am by no means a C programmer;
however, I can tell you that the code has changed a great deal with
regards to xmlrpc and it has impacted performance to the point where it
seems to be unusable with current releases of Python where expected
output is > 300 records.  

Please check it out for yourself, using a different xmlrpc server - I
currently have access to one only where the number of records is greater
than 300.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2008-01-21 Thread Eric Sammons

Eric Sammons added the comment:

Has anybody else tested this against an RPC server that has more than
300 items to be returned.  I find it interesting that before all the
xmlrpc code changed everything works fine, but after the code change
(re-write) things don't seem to work.

As for the bug, I do not claim there is a bug, I am simply pointing
out that when using oprofile to profile the test application, most of
the time is spent in a specific routine.  Now it could be a side
affect of xmlrpc, I don't know - I do not claim to be a "programmer".

I am looking to turn on verbose mode in xmlrpc.  As soon as I do that
I will test again and send the results.

On Jan 15, 2008 7:05 PM, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>
> Fredrik Lundh added the comment:
>
> Can you switch on verbose mode in xmlrpclib, so you can see *where* the
> transfer hangs?
>
> Arguing that a hanging Python program must be caused by a bug in the
> code that *executes* the Python program isn't that meaningful, really.
> After all, that code is used to run *all* Python programs, so I think
> we'd noticed if it had a tendency to hang unexpectedly...
>
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1327>
> __
>

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2008-01-21 Thread Eric Sammons

Eric Sammons added the comment:

I have added the verbose=1 option, the processing hangs in the body: where :

for a in l:
print a['channel_label']


Is returning the data.  Initially it returns data quickly and then slows
until it eventually stops.

Here is the sample of the body data... data removed...


body: '


This information is repeats ~500 times in the server where the program
eventually times out.

If you require anything further from the verbose output please let me know.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2008-01-22 Thread Eric Sammons

Eric Sammons added the comment:

Here is the header information that I get:

reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Tue, 22 Jan 2008 14:42:54 GMT
header: Server: Apache
header: Content-Length: 183
header: Content-Type: text/xml;charset=UTF-8


Then I get addition send followed by more header info:


reply: 'HTTP/1.1 200 OK\r\n'
header: Date: Tue, 22 Jan 2008 14:42:54 GMT
header: Server: Apache
header: Content-Length: 399191
header: Content-Type: text/xml;charset=UTF-8
header: X-Pad: avoid browser bug


I am looking for additional Content-Length data.  Also, the above was
done using Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11).

Thank you!

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/ xmlrpmclib

2008-01-22 Thread Eric Sammons

Eric Sammons added the comment:

Some strace data:

WORKS:

 strace -cf ./test.py >/tmp/out
Process 9439 detached
% time seconds  usecs/call callserrors syscall
-- --- --- - - 
 33.100.009125   8  1086   956 open
 23.470.006469   7   930   recvfrom
  9.670.002667   9   311   278 stat
  8.100.002234  14   165   read
  3.400.000936   7   133   mmap
  3.250.000896   6   144   close
  3.240.000892  4520   poll
  2.970.000818   5   173   fstat
  2.830.000780  1553   munmap
  2.130.000588 118 5 3 execve
  1.340.000369   939   mprotect
  1.130.000312   472   rt_sigaction
  0.660.000183   535   futex
  0.640.000176  1017   brk
  0.610.000169  1214   sendto
  0.570.000158  26 6   write
  0.500.000139   434   fcntl
  0.490.000134  1014   socket
  0.400.000111   425   lseek
  0.360.000100   714 2 connect
  0.340.93  23 4   getdents64
  0.270.74   514 2 ioctl
  0.170.48   411   gettimeofday
  0.060.16   8 2 2 access
  0.050.14   7 2 2 readlink
  0.040.10   5 2   arch_prctl
  0.040.10   5 2   time
  0.030.09   9 1   _sysctl
  0.030.08   8 1   lstat
  0.030.08   4 2   uname
  0.020.06   6 1   rt_sigprocmask
  0.020.06   6 1   getcwd
  0.010.04   4 1   getrlimit
  0.010.04   4 1   set_tid_address
-- --- --- - - 
100.000.027566  3335  1245 total


I am still compiling the same data for Python 2.4.3 (#1, Dec 11 2006,
11:39:03).  However, this could take hours...  as 2.4+ seem to be
problematic.

__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1327>
__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com