Wouldn''t it be neat to have some sort of a generator or something that you could use to generate a model/controller/views that would let your users view the stats for a website? (i.e. hits, page views, bytes served, etc) (unless something like that exists already...)
This would require integration with the web server itself. Rails doesn''t know what it''s served previously by itself. On 9/9/05, Joe Van Dyk <joevandyk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> > Wouldn''t it be neat to have some sort of a generator or something that > you could use to generate a model/controller/views that would let your > users view the stats for a website? (i.e. hits, page views, bytes > served, etc) > > (unless something like that exists already...) > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Patrick McCafferty wrote:> This would require integration with the web server itself. Rails doesn''t > know what it''s served previously by itself.Surely not - couldn''t you override ActionController::Base.process_cgi() to log useful bits and pieces that you could then present back to the user? -- Alex
Patrick probably was talking about static assets. Furthermore when entire page is cached, request does not even hit Rails. Caching is essential for high traffic sites. Simply counting at Rails level you will not be able to detect a significant number of hits. I think that parsing web server logs, or some custom ready made solution would be lot more effective. Zsombor Alex Young wrote:> Patrick McCafferty wrote: > >>This would require integration with the web server itself. Rails doesn''t >>know what it''s served previously by itself. > > Surely not - couldn''t you override ActionController::Base.process_cgi() > to log useful bits and pieces that you could then present back to the user? >-- Company - http://primalgrasp.com Thoughts - http://deezsombor.blogspot.com
Dee Zsombor wrote:> Patrick probably was talking about static assets. Furthermore when entire page > is cached, request does not even hit Rails. Caching is essential for high > traffic sites. Simply counting at Rails level you will not be able to detect a > significant number of hits. I think that parsing web server logs, or some custom > ready made solution would be lot more effective. >True. I hadn''t accounted for that. -- Alex
On Sep 8, 2005, at 6:26 PM, Joe Van Dyk wrote:> Wouldn''t it be neat to have some sort of a generator or something that > you could use to generate a model/controller/views that would let your > users view the stats for a website? (i.e. hits, page views, bytes > served, etc) > > (unless something like that exists already...)RailStat is a generator and it tracks most of that: http://www.railstat.com/ Scott Hughes http://blog.globlareset.org
On 9/9/05, Dee Zsombor <dee.zsombor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Patrick probably was talking about static assets. Furthermore when entire page > is cached, request does not even hit Rails. Caching is essential for high > traffic sites. Simply counting at Rails level you will not be able to detect a > significant number of hits. I think that parsing web server logs, or some custom > ready made solution would be lot more effective.But still, it shouldn''t be terribly difficult. Options to the generator could include where to find the log files and possible another one (if apache logs are different from lighttpd logs, which i''m pretty sure are different from webrick logs). I''m just thinking it would be really neat to give clients the ability to go to http://their.site/stats and let them view how many people are visiting the website each day, what the most visted pages are, and where people are coming from.> > Zsombor > > Alex Young wrote: > > Patrick McCafferty wrote: > > > >>This would require integration with the web server itself. Rails doesn''t > >>know what it''s served previously by itself. > > > > Surely not - couldn''t you override ActionController::Base.process_cgi() > > to log useful bits and pieces that you could then present back to the user? > > > > -- > Company - http://primalgrasp.com > Thoughts - http://deezsombor.blogspot.com > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
You should see if this package works for what you want. I am using it for the same thing you are describing: <http://rubyforge.org/projects/railstat/> HTH -Ezra On Sep 9, 2005, at 8:13 AM, Joe Van Dyk wrote:> On 9/9/05, Dee Zsombor <dee.zsombor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >> Patrick probably was talking about static assets. Furthermore when >> entire page >> is cached, request does not even hit Rails. Caching is essential >> for high >> traffic sites. Simply counting at Rails level you will not be able >> to detect a >> significant number of hits. I think that parsing web server logs, >> or some custom >> ready made solution would be lot more effective. >> > > But still, it shouldn''t be terribly difficult. Options to the > generator could include where to find the log files and possible > another one (if apache logs are different from lighttpd logs, which > i''m pretty sure are different from webrick logs). > > I''m just thinking it would be really neat to give clients the ability > to go to http://their.site/stats and let them view how many people are > visiting the website each day, what the most visted pages are, and > where people are coming from. > > >> >> Zsombor >> >> Alex Young wrote: >> >>> Patrick McCafferty wrote: >>> >>> >>>> This would require integration with the web server itself. Rails >>>> doesn''t >>>> know what it''s served previously by itself. >>>> >>> >>> Surely not - couldn''t you override >>> ActionController::Base.process_cgi() >>> to log useful bits and pieces that you could then present back to >>> the user? >>> >>> >> >> -- >> Company - http://primalgrasp.com >> Thoughts - http://deezsombor.blogspot.com >> _______________________________________________ >> Rails mailing list >> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org >> http://lists.rubyonrails.org/mailman/listinfo/rails >> >> > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-Ezra Zygmuntowicz Yakima Herald-Republic WebMaster 509-577-7732 ezra-gdxLOakOTQ9oetBuM9ipNAC/G2K4zDHf@public.gmane.org