The only difference is: orm.flush() orm.commit()
Where orm is my SQLAlchemy Session. When I comment out these 2 lines, it works fine. When left uncommented, the actual SQL INSERT happens quickly, but the client sits there waiting for a response. According to my repoze.profile report, the pylons request completes in about 1.5sec, but the client sits there. To rule out the possibility that the server was sending the response properly, and the client choking on it somehow, I ran tcpdump. I don't fully understand the output, but comparing the dumps from with DB and without DB, it looks like with the DB INSERT happening, there is a 5 minute pause of some sort. Notice the 5 minute difference between lines 2 and 3 in the first tcpdump output below (10.0.45.67 is the server): Last few lines of tcpdump when using SQLAlchemy =============================================================================== 12:00:23 length 126) 10.0.45.67 > 10.0.45.111 : P ack win 44100 12:00:23 length 40) 10.0.45.111 > 10.0.45.67: ., cksum (correct) ack win 65434 12:05:22 length 40) 10.0.45.67 > 10.0.45.111 : F, cksum correct) ack win 44100 12:05:22 length 40) 10.0.45.111 > 10.0.45.67: ., cksum (correct) ack win 65434 12:05:22 length 40) 10.0.45.111 > 10.0.45.67: F, cksum (correct) ack win 65434 12:05:22 length 40) 10.0.45.67 > 10.0.45.111 : ., cksum (correct) ack win 44100 2366 packets captured 2366 packets received by filter 0 packets dropped by kernel Last few lines of tcpdump when NOT using SQLAlchemy =============================================================================== 11:59:39 length 126) 10.0.45.67 > 10.0.45.1118: FP ack win 44100 11:59:39 length 40) 10.0.45.1118 > 10.0.45.67: ., cksum (correct) ack win 11:59:39 length 40) 10.0.45.1118 > 10.0.45.67: ., cksum (correct) ack win 65434 11:59:39 length 40) 10.0.45.1118 > 10.0.45.67: F, cksum (correct) ack win 65434 11:59:39 length 40) 10.0.45.67 > 10.0.45.1118: ., cksum (correct) ack win 44100 215 packets captured 216 packets received by filter 0 packets dropped by kernel On Mar 4, 10:52 am, Paweł Stradomski <[email protected]> wrote: > W liście Bryan z dnia środa 04 marca 2009: > > > First off, thanks big time for pointing me towards repoze.profile. I > > have integrated it into my app and love it. > > > The total time for a request without DB stuff is about .855 CPU > > seconds > > The total time for a request with DB suff is about 1.470 CPU seconds > > > These numbers are saying that the entire pylons request/response cycle > > is only taking 1.47sec, but my client sits there waiting for a request > > for about a minute, even when the client is being run on the same > > machine. Could the response be getting tied up in the network layer? > > Why would my use of SQLAlchemy and Mysql interfere with how long it > > takes a response to get sent to a client? > > I'd be more keen to suspect that some lock is held and timeouts rather than > blame network, especially if output is identical in both cases, though you > can check that too. > > What exactly is the difference between "with db" and "without db" versions, > code-wise? Could you try to remove functionality by small chunks to see what > lines cause the slowdown? > > -- > Paweł Stradomski --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
