The plot thickens: While the 5 minute pause is happening, I can kill the pylons app, and the last 4 packets are still exchanged between client and server, albeit 5 minutes later. Could paste still be hanging around after I kill the pylons app?
I have had problems in the past when SQLAlchemy encounters a DB error and when I try to restart my pylons app, I get a "socket.error: (98, 'Address already in use')" exception that starts in SocketServer.py and bubbles up to paste/serve.py. And if I do netstat -l at that point, I see that "something" is listening on my app's port 5004, but there is no pid or program name there, just a dash. 5 minutes later, that port no longer has "something" listening on it. It seems that there is some sort of 5 minute zombie state in paste or tcp/ip stack. How could Mysql+SQLAlchemy happenings have this sort of effect?? The server is running Ubunut 8.04. On Mar 4, 1:04 pm, Bryan <[email protected]> wrote: > Using wireshark on the client side, the xmlrpc data is actually > getting back to the client right away. Then there is the large pause > (always right around 5 minutes) > This is how the conversation goes. The 5 minute gap appears only when > using SQLAlchemy w/ MySQL > > 1. Last packet that has actual xmlrpc data sent to client > 2. Client sends packet to server (confirmation ??) > ----- 5 Minute gap --------------------------------------------- > 3. Server sends 1 packet to client > 4. Client sends back 2 packets > 5. Server sends 1 packet to client > > It is the first packet sent by the server *after* the data is > received by the client and the client responds that is stalling. > After the data is received by the client, I assume there needs to be > some tcp/ip confirmation and such, and that is what the last 4 packets > being sent between client/server are. But what is so special about > this packet that is taking 300 seconds for the server to send? > > On Mar 3, 11:17 am, Noah <[email protected]> wrote: > > > On Mar 5, 2009, at 7:09 AM, Bryan <[email protected]> wrote: > > > > 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 have never looked at network traffic directly before, but it seems > > > like that is what I need to do next. I want to find out exactly when > > > the request is being sent over the wire. A > > > > ny suggestions on how to proceed? > > > Wireshark and or strace are miracle workers. > > > > On Mar 3, 3:26 pm, Paweł Stradomski <[email protected]> wrote: > > >> W liście Bryan z dnia wtorek 03 marca 2009: > > > >>> Inside of an XMLRPCController I have a function that inserts items > > >>> into a database, and returns 'OK' to the client if everything works. > > >>> Everything runs quickly and correctly, the rows are inserted into > > >>> the > > >>> DB, but pylons hangs for about a minute when generating the > > >>> response. > > >>> The client hangs there waiting for a response while pylons does > > >>> *something*. > > > >> Maybe try to profile your application to check where it spends that > > >> time? Try > > >> repoze.profile. > > > >> -- > > >> 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 -~----------~----~----~----~------~----~------~--~---
