Hi Railers, I''ve got a slightly strange problem here. I added the login generator (regular, non-salted-hash variety) to my app, and it works great here on WEBrick. However, when I deploy it to Textdrive, running in production mode under Lighttpd and FCGI, the login screen itself has a very long (20 seconds plus) delay before it appears. The main page of my app comes up super fast, as do all the other pages - it''s only when clicking the "login" link that there''s this huge delay before the login page appears. When it eventually appears, it does work fine, so I really have no idea what''s going on with it. Even the log files don''t give anything away: Rendering account/login (200 OK) Completed in 0.00542 (184 reqs/sec) | Rendering: 0.00436 (80%) | DB: 0.00000 (0%) Which looks absolutely fine and doesn''t account for the delay at all, so I have no idea what''s going on, because it''s only this one page that''s slow to appear. Once logged in, everything is back to normal speed. Has anyone else experienced this? I''m pretty stumped and nobody on IRC seems to be able to help either. What''s the best way of finding where the bottleneck is in such a situation with Rails? Trouble is, I''m not sure the bottleneck is happening with Rails or Ruby (checking the times in the log) so perhaps it''s something outside of that? I just don''t know! Cheers, ~Dave -- Dave Silvester Rent-A-Monkey Website Development Web: http://www.rentamonkey.com/
Dave, I'm not familiar with the login generator, but many people have recently reported slow redirects with lighttpd 1.4.3 (which textdrive currently uses). I'm blanking on the fix, so google or check the ml archives. Jacob On 9/11/05, Dave Silvester <dave@rentamonkey.com> wrote:> Hi Railers, > > I've got a slightly strange problem here. I added the login generator > (regular, non-salted-hash variety) to my app, and it works great here on WEBrick. > > However, when I deploy it to Textdrive, running in production mode under > Lighttpd and FCGI, the login screen itself has a very long (20 seconds plus) > delay before it appears. > > The main page of my app comes up super fast, as do all the other pages - it's > only when clicking the "login" link that there's this huge delay before the > login page appears. When it eventually appears, it does work fine, so I > really have no idea what's going on with it. Even the log files don't give > anything away: > > Rendering account/login (200 OK) > Completed in 0.00542 (184 reqs/sec) | Rendering: 0.00436 (80%) | DB: 0.00000 (0%) > > Which looks absolutely fine and doesn't account for the delay at all, so I > have no idea what's going on, because it's only this one page that's slow to > appear. Once logged in, everything is back to normal speed. > > Has anyone else experienced this? I'm pretty stumped and nobody on IRC seems > to be able to help either. What's the best way of finding where the > bottleneck is in such a situation with Rails? Trouble is, I'm not sure the > bottleneck is happening with Rails or Ruby (checking the times in the log) so > perhaps it's something outside of that? I just don't know! > > Cheers, > > ~Dave > > -- > > Dave Silvester > Rent-A-Monkey Website Development > Web: http://www.rentamonkey.com/ > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Jacob Quinn Shenker wrote:> I''m not familiar with the login generator, but many people have > recently reported slow redirects with lighttpd 1.4.3 (which textdrive > currently uses). I''m blanking on the fix, so google or check the ml > archives.Hey Jacob, thanks for the prompt reply. My guess is that it may be Lighttpd as well... which seems a shame, because so far it''s been great. Actually, having done about an hour of trying to work out why this was happening, and asking on IRC, and posting here... the damn thing seems to have started working properly now! At least most of the time, which is good enough for now, since this is only a demo at the moment. (I guess it perhaps knew I was going to open a can of whoopass if it didn''t start behaving soon!?) Cheers, ~Dave -- Dave Silvester Rent-A-Monkey Website Development Web: http://www.rentamonkey.com/
This is actually something I''ve been struggling with for the past few days, but with Instiki-AR. It''d be great if some TextDrive people could jump in here, but I think it may also have to do with the Rails trunk since it''s only been noticed recently. While it might not necessarily be a problem with the trunk, it *could* be a change that''s causing TextDrive''s current configuration to break. The problem is related to HTTP 302 redirections (basically anything coming from ActionPack''s redirect_to), but it''s not a problem with lighttpd. The reason you didn''t notice it under WEBrick was that you weren''t using mod_proxy redirection. Everything works fine when you login from a page served over lighttpd directly, but as soon as it goes through Apache, there''s that ~30 second delay. Why? I don''t know. I think it has to do with the headers being passed back and forth, and Apache thinking its smarter than it is (trying to translate the redirection host to something else?). This is what I do know: Client -> get me /login/ -> Apache -> getting /login/ -> Lighttpd Client <- *WAITING HERE for 30 seconds* <- Apache <- 302 redirection <- Lighttpd Client -> get me /login/successful -> Apache -> getting /login/successful -> Lighttpd Client <- HTML <- Apache <- HTML <- Lighttpd Yes, every part of this transaction is speedy, except after Lighttpd gives Apache the 302 redirection. You can confirm this by talking to the servers independently, or by watching timestamps in the Apache, lighttpd, and Rails logs. Can someone please jump in and help investigate? Thanks, -- Chris Lambert On 9/12/05, Dave Silvester <dave-AJqNGCqIqVQ7cdpDWioORw@public.gmane.org> wrote:> Jacob Quinn Shenker wrote: > > I''m not familiar with the login generator, but many people have > > recently reported slow redirects with lighttpd 1.4.3 (which textdrive > > currently uses). I''m blanking on the fix, so google or check the ml > > archives. > > Hey Jacob, thanks for the prompt reply. My guess is that it may be Lighttpd as > well... which seems a shame, because so far it''s been great. > > Actually, having done about an hour of trying to work out why this was > happening, and asking on IRC, and posting here... the damn thing seems to have > started working properly now! At least most of the time, which is good enough > for now, since this is only a demo at the moment. (I guess it perhaps knew I > was going to open a can of whoopass if it didn''t start behaving soon!?) > > Cheers, > > ~Dave > > -- > > Dave Silvester > Rent-A-Monkey Website Development > Web: http://www.rentamonkey.com/ > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
Chris Lambert wrote:> Yes, every part of this transaction is speedy, except after Lighttpd > gives Apache the 302 redirection. You can confirm this by talking to > the servers independently, or by watching timestamps in the Apache, > lighttpd, and Rails logs. > > Can someone please jump in and help investigate?Hi Chris, Good thinking! It''s true that if I go direct to the port I''m running Lighttpd on, it''s noticeably a lot quicker to respond than when proxied through Apache (which is nice, since my app is actually quite snappy like this). It sounds like we ought to file a support ticket at Textdrive. It seems like you have a fairly good idea of what''s actually happening, but I''ll do it if you don''t have time? Cheers, ~Dave -- Dave Silvester Rent-A-Monkey Website Development Web: http://www.rentamonkey.com/
We were having delays on redirects that appears lighttpd-related. I was not running apache but had problems with lighttpd + IE. Others have reported the problem as well. Here''s the ticket: http://trac.lighttpd.net/trac/ticket/243 A temporary fix seemed to be setting server.max-keep-alive-requests to 0, although this did not clear up the issue for me when testing an IE client over satellite link. On 9/12/05, Dave Silvester <dave-AJqNGCqIqVQ7cdpDWioORw@public.gmane.org> wrote:> Chris Lambert wrote: > > Yes, every part of this transaction is speedy, except after Lighttpd > > gives Apache the 302 redirection. You can confirm this by talking to > > the servers independently, or by watching timestamps in the Apache, > > lighttpd, and Rails logs. > > > > Can someone please jump in and help investigate?
On Sep 11, 2005, at 11:18 PM, Dave Silvester wrote:> I''ve got a slightly strange problem here. I added the login > generator (regular, non-salted-hash variety) to my app, and it > works great here on WEBrick. > > However, when I deploy it to Textdrive, running in production mode > under Lighttpd and FCGI, the login screen itself has a very long > (20 seconds plus) delay before it appears. >I had this exact problem (fast local, but on TD with Lighttpd the login/out was slow, but all other pages snappy) and the problem *seemed* to be the large number of session files in /tmp (sometimes) on the shared server. It was suggested that I move my session store into the database, and the problem went away when I restarted lighty and my browser. http://forum.textdrive.com/viewtopic.php?id=1008 Hope this helps! -raymond
The ticket that Bill pointed to solved the problem for me. It looks like lighty and Apache are miscommunicating with keep-alive requests when using mod_proxy, but that the fault could lie with lighttpd. In any case, setting that server option resolved my Instiki-AR problems! :-) - Chris On 9/12/05, Bill Katz <billkatz-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> We were having delays on redirects that appears lighttpd-related. I > was not running apache but had problems with lighttpd + IE. Others > have reported the problem as well. > > Here''s the ticket: http://trac.lighttpd.net/trac/ticket/243 > > A temporary fix seemed to be setting server.max-keep-alive-requests to > 0, although this did not clear up the issue for me when testing an IE > client over satellite link. > > On 9/12/05, Dave Silvester <dave-AJqNGCqIqVQ7cdpDWioORw@public.gmane.org> wrote: > > Chris Lambert wrote: > > > Yes, every part of this transaction is speedy, except after Lighttpd > > > gives Apache the 302 redirection. You can confirm this by talking to > > > the servers independently, or by watching timestamps in the Apache, > > > lighttpd, and Rails logs. > > > > > > Can someone please jump in and help investigate? > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >