showartist and showalbum seem to be leading amont the ordinary pages ..
djce
I doubt it. You mean the "unique usernames" bit?
At the moment that would be taken directly from the access logs; so user "-" for 99.99% for all requests, and other names for some other HTTP requests (but not for the main web site)
But if I make the change I mentioned a minute ago, that stat would become useful...
salisan
Right, but you can get what pages have most requests now anyway, just not if they are from logged in users or not ;)
djce
yes
ruaok|snug is off to spend time with the lead MB donor.
intrep
ok, im not familiar with mason so i have a quick question
at the bottom of showartist.html there is a tag <& /comp/footer &>, i am going to take a wild guess that this is the end of the generated html, is there any way to get mason to dump the html for the whole page into a variable at this point?
djce
Hmmm...
You can call $m->scomp($page) to "run" a page and capture its output
i.e. $output = $m->comp("/path/to/component", @args)
If you haven't been called as $m->scomp, I don't know if it's possible.
intrep
mason has its own object cache
keeps expire times and everything
interesting...
djce
yes, that's useful, if you know what you're "expire" conditions are.
For small parts of pages, e.g. the "top moderators" panel in the sidebar, the cache is useful then since it only depends on time, not any other inputs.
intrep
well, i would think the entire page for anonymous lookups of showartist and showalbum could be cached for say, five minutes or so
djce
Except for the "expand" settings on the album page.
Album pages are easier.
intrep
the expand pages could be cached too really
but i would bet that the showartist main page for each artist is accessed about 3 times as often as the expansion pages, making it very valuable to cache
djce
Only for anon visitors, right?
intrep
right
djce
Interesting...
intrep
logged in users get fresh content all the time
djce
And you're talking about cached as in returning a "304" response, not just getting the "200" response but faster?
intrep
you really could cache a lot of the info for logged in users as well
you could do it either way
djce
The latter is technically easier; the former is more beneficial to the visitor.
intrep
yeah, and better for your bandwidth
djce
Yes!
That's definitely going on the TODO list then. Let me know if you make any progress yourself...
intrep
hmm, you could also, if you wanted to get really tricky, stick some squid caches out on people machines that will redirect to your main site and cache some stuff.
taking a lot of load off of your main site
Mutiny
180980 mp3list.txt
133589 trmdb.txt
intrep
a sort of squid mirror
Mutiny raps his fingers.
djce
squid: The yet-to-be-created mirror system would handle that too.
180,000 MP3 files? Wow.
intrep
i need food
intrep is afk for grub
Mutiny
mmm
637gb, all downloadable and streamable courtsey of unixpunx.org
It was mentioned a month or so ago that we need a more responsive way of dealing with those, so we would be more likely to keep them up-to-date.
My TODO list tends mainly to be small bug-fix-like things. Rob's TODO list tends to be more oriented towards the big picture (e.g. "implement mirroring")
intrep
perhaps bugzilla, file bugs for things that need to be done
djce
We've got the sourceforge bug list too
intrep
yeah, maybe just file your todo items as bugs
djce
That's a mixture of bugs reported by users, potential bugs spotted by us, and RFEs
Yes, but how much easier is just appending two lines to a local text file than posting a web form? :-)
intrep
very true
you could write a script to autopost your text file as bugs :)
you just have to format your text file more carefully
djce
Interesting idea. It would be a start just to copy my TODO file to the web, like I did for you just now, and link to it from the main site.
(and do so regularly)
intrep
write a script to copy the file to the web server and run it from cron