- v50 information can now be added to pages in the main namespace. v0.47 information can still be found in the DF2014 namespace. See here for more details on the new versioning policy.
- Use this page to report any issues related to the migration.
Difference between revisions of "Dwarf Fortress Wiki talk:Improvement Drive"
| Line 26: | Line 26: | ||
: did you tweak your appache setting so you could use maybe a bit less bandwidth ? Mainly compression on the fly ? Else... I was looking at some redundant template, like the rocks template, you have ~700bytes of inline CSS. Not a lot by itself, but every bytes count when you want to save bandwidth. It could be easy to add classes and CSS rules in a file that will be cached anyway. There's some compression tools for Javascript and CSS files that could give you a couple kbytes too. --[[User:Karl|Karl]] 11:29, 23 September 2009 (UTC) | : did you tweak your appache setting so you could use maybe a bit less bandwidth ? Mainly compression on the fly ? Else... I was looking at some redundant template, like the rocks template, you have ~700bytes of inline CSS. Not a lot by itself, but every bytes count when you want to save bandwidth. It could be easy to add classes and CSS rules in a file that will be cached anyway. There's some compression tools for Javascript and CSS files that could give you a couple kbytes too. --[[User:Karl|Karl]] 11:29, 23 September 2009 (UTC) | ||
::Karl's got a good point, I just looked at the site stats using YSlow and noticed a few things that might help and should be easy (in theory) to do: 1. Add expires headers: this means that browsers won't be constantly reloading files that aren't changed much like many of the graphics files and script files. Having an expiration date of about a week or two is often enough to drastically improve bandwidth. 2. Compress components with gzip (or deflate.) This is easy to do in IIS but I don't know how easy it is to do in Apache; I've only dabbled in Apache before. [[User:3lB33|3lB33]] 13:41, 23 September 2009 (UTC) | ::Karl's got a good point, I just looked at the site stats using YSlow and noticed a few things that might help and should be easy (in theory) to do: 1. Add expires headers: this means that browsers won't be constantly reloading files that aren't changed much like many of the graphics files and script files. Having an expiration date of about a week or two is often enough to drastically improve bandwidth. 2. Compress components with gzip (or deflate.) This is easy to do in IIS but I don't know how easy it is to do in Apache; I've only dabbled in Apache before. [[User:3lB33|3lB33]] 13:41, 23 September 2009 (UTC) | ||
| + | ::: It was on the todo list; and is now done. The primary cost of the server hosting is not in bandwidth, but is instead in memory and cpu usage. However, I want to try to keep all page serves under 500 ms. [[User:Briess|Briess]] 07:57, 24 September 2009 (UTC) | ||
== Non-vanilla == | == Non-vanilla == | ||
Revision as of 07:57, 24 September 2009
Advertisements
Instead of pursuing this kind of thing, why not go with paypal and ask for donation? I'm curious, why are you forking that much money for a simple wiki ? 60$ a month seems a lot. Could you provide stats about bandwidth usage and stuff like that ? --Karl 22:59, 18 September 2009 (UTC)
I'd rather not ask for donation, as I feel if the ads are focused properly, they shouldn't be too intrusive and more than cover the bills. Also, we have the issue that since this is on my company's server, the hosting provider is technically the company I co-own; as that is the case, donations to a company raise all kinds of weird legal issues that I'd rather not spend time trying to figure out. Ad units are legally able to be accounted as "revenues," so it makes it significantly simpler to just go with that. If I had a cheaper server that could handle the load, sure, I would move it there - unfortunately, I tried that, which resulted in about an hour of downtime yesterday. Oops.
Once my company is making enough money that it's no longer draining money from my savings (and is paying me, instead of me paying it), I'll gladly and quite quickly drop the ads.
Server usage statistics:
- 3gb downstream / day used on average (peak: 3.3gb)
- 322mb upstream / day used on average (peak 7.4gb, but I was uploading some stuff not related to the wiki)<
- Apache stats: (only the wiki is using Apache, and it's set to manage new instances of apache based on load)
- Average: 7 instances of Apache running at 2.0% processor utilization each, 20 mb of memory each
- Peak: 22 instances of Apache running at 3.2% processor utilization each, 23 mb of memory each
The above are moving averages. Briess 23:12, 18 September 2009 (UTC)
- Do you have any stats on, the amount of traffic from wikignomes like me who hang around and mess with articles, vs n00bs the wiki actually thinks it is here to help? I guess that "logged-in vs IP" would be the easiest stat to look at, how much that gets rid of editors who don't automatically log in I don't know.
- Re: the adds, I personally find it funny to get ads for real-world "Rock Retaining Walls" by visiting a wiki about a game in which your @'s build, rock retaining walls. How to target that is an amusing problem for someone. The ads don't bother me at all though - but obviously no adds would be nicer.
- Maybe if you disabled the ads for users with more than.... 500 edits (ie, me!)?
- I'm all for a project to improve articles BTW, sign me up.Garrie 03:46, 19 September 2009 (UTC)
- I don't have access to stats like that, as unfortunately Mediawiki was not designed with that level of logging detail in mind. Best I can do is estimated time on pages in particular namespaces. Briess 05:57, 19 September 2009 (UTC)
- did you tweak your appache setting so you could use maybe a bit less bandwidth ? Mainly compression on the fly ? Else... I was looking at some redundant template, like the rocks template, you have ~700bytes of inline CSS. Not a lot by itself, but every bytes count when you want to save bandwidth. It could be easy to add classes and CSS rules in a file that will be cached anyway. There's some compression tools for Javascript and CSS files that could give you a couple kbytes too. --Karl 11:29, 23 September 2009 (UTC)
- Karl's got a good point, I just looked at the site stats using YSlow and noticed a few things that might help and should be easy (in theory) to do: 1. Add expires headers: this means that browsers won't be constantly reloading files that aren't changed much like many of the graphics files and script files. Having an expiration date of about a week or two is often enough to drastically improve bandwidth. 2. Compress components with gzip (or deflate.) This is easy to do in IIS but I don't know how easy it is to do in Apache; I've only dabbled in Apache before. 3lB33 13:41, 23 September 2009 (UTC)
- It was on the todo list; and is now done. The primary cost of the server hosting is not in bandwidth, but is instead in memory and cpu usage. However, I want to try to keep all page serves under 500 ms. Briess 07:57, 24 September 2009 (UTC)
- Karl's got a good point, I just looked at the site stats using YSlow and noticed a few things that might help and should be easy (in theory) to do: 1. Add expires headers: this means that browsers won't be constantly reloading files that aren't changed much like many of the graphics files and script files. Having an expiration date of about a week or two is often enough to drastically improve bandwidth. 2. Compress components with gzip (or deflate.) This is easy to do in IIS but I don't know how easy it is to do in Apache; I've only dabbled in Apache before. 3lB33 13:41, 23 September 2009 (UTC)
Non-vanilla
o Should we include a link to Mayday's graphical compilation on the main page?
The default tileset can be more than intimidating for some.
The problem is that MM's download is far from vanilla, and conflicts rear up regularly with newbies who have downloaded that and then refer to this wiki - which isn't the same interface in many respects. If we were to do something like that, we'd want to approach it with those problems in mind.--Albedo 23:24, 18 September 2009 (UTC)
- Makes sense. The only gameplay differences I can recall off the top of my head are the stone control mod and the 'cat cancels store item in stockpile: too injured' 'fix'. What other changes are there that we would need to account for? Briess 23:30, 18 September 2009 (UTC)
Verify this
* Verify Time!
o Category:Verify has a lot of stuff we need to verify.
To "verify" sometimes requires "more research", and sometimes that research is either obscure, time consuming, random, tedious or a combination of the above. Do we need it? Yeah. Are we excited about it?... <looks around>--Albedo 23:24, 18 September 2009 (UTC)
- True. Once I get a few upgraded wiki modules up though, I'll probably start cracking at it. Briess 23:29, 18 September 2009 (UTC)