User talk:Aichon: Difference between revisions
From The Urban Dead Wiki
Jump to navigationJump to search
Ayu Milady (talk | contribs) (→May I ask?: new section) |
Ayu Milady (talk | contribs) |
||
| Line 86: | Line 86: | ||
== May I ask? == | == May I ask? == | ||
[[ | [[User_talk:Ayu_Milady/Archives]] is this okay or not? and.. where should I ask for things like this? thanks :) --[[User:Ayu Milady|<b><font color="#90B818">Ayu</font></b>]] [[User talk:Ayu Milady|<b><font color="#11B4BD">Milady</font></b>]] <sup><font face="Cambria">[[NWO|<font color="Silver">NWO</font>]] member</font></sup> [[User:Ayu_Milady/Sig | <span style="font-family:High Tower Text; color: orange; font-weight:normal;">(┛ò__ó)┛彡┻━┻</span>]] 08:10, 14 September 2013 (BST) | ||
Revision as of 07:16, 14 September 2013
Aichon:Talk
Announcement: I'm no longer active. My talk page is still your best bet to get in touch. —Aichon— 04:39, 15 December 2018 (UTC)
- New conversations should be started at the bottom using a level two header (e.g.
==Header==). Or with the + - I like to keep conversations wherever they start, but if a conversation ends up here, I will keep it here.
- I will format comments for stylistic reasons, delete comments for whatever reason, and generally do anything else within reason.
NOTICE
Editting User Pages
I was looking around at all the pages that call on the 5000 or so danger report templates, and I noticed that a lot of them were userpages. Since we're experiencing so much lag these days when the danger reports get updated, I was wondering if I could delete or disable the superfluous ones? Putting nowiki tags on them, with a little explanation that we disabled it because of performance issues and because they were unused. Problem is: they still are other peoples' user pages and I'm not sure what the wikipoliticians and wikilawyers would say about this, so any advice? PB&J 14:51, 18 June 2013 (BST)
- The lag isn't from them. The lag is from the Danger Center needing to re-grab all 5000 templates every single time a single one of them changes, since the cache for the page needs to be recreated. Right now, updating a danger report might kick off, say, 5000 updates for the Danger Center and another 10 updates for the other pages mentioning that danger report, giving us a total of 5010 updates to do. Quite obviously, removing the 10 won't have a significant impact on performance. —Aichon— 15:11, 18 June 2013 (BST)
- Quite a lot of the pages I'm talking about are like this one, and call on about 50 everytime a single one of them changes. If we look at the "What links here" of the first one in the topleft corner, Special:WhatLinksHere/User:DangerReport/Palprey_Road_Police_Department, one which is among the lesser used ones and lesser known ones, we see that several of those pages call on dozens of templates, including used, unused and personal test status maps, as well as specific building status maps (in this case the PD Status Map. That could amount to quite a lot of pages, each calling on a couple dozen templates, just for one danger report update, no? PB&J 15:18, 18 June 2013 (BST)
- In this case it would make no difference because it's a by page thing and not a by call thing. --Karekmaps 2.0?! 16:50, 18 June 2013 (BST)
- I still don't really understand? The lag increased when we added the danger center, and it occurs more when updating the danger reports than when you look at the center itself. AFAIK the amount of times a danger report is called upon has a direct influence on that lag, ergo reducing the amount of maps that call upon a danger report should reduce the overall lag. Right? PB&J 16:59, 18 June 2013 (BST)
- What Karek is saying (and what I was typing up before I saw that he had already linked exactly what I was going to say) is that the Danger Center is a gigantic job, whereas the other pages are not. The reason that matters, is because the wiki is configured to process one job in the queue per page load. As such, those smaller pages are not even getting processed at the same time as the Danger Center and are thus in no way contributing to the unresponsiveness that people are suffering. To draw an imperfect analogy, the job queue is like a relay race where every time the baton is passed a page gets loaded for a user. In this race, some runners (jobs) are slower than others. Quite obviously, you can improve the speed of the faster runners all you want, but you'll still be waiting the exact same amount of time for the slower ones to complete their laps and pass the baton. So, more or less, those smaller pages aren't contributing to the problem at all, since the unresponsiveness they create is separate from what people are complaining about and is small enough that most of us have never noticed it at all. —Aichon— 18:39, 18 June 2013 (BST)
Technical gobbledegook-> Yeah, sorta this. Basically everytime you load a page the job queue processes 1 job. Everytime you have a template on a page it loads a function and then on repeat calls of the template it just references the already loaded function. Different templates do have different costs but that's based on the size of the initial template, not so much the number of times it's called(which has a much smaller impact). Everytime you call a unique template the server has to go and make a new database connection and call that template's page content to then queue it up for the preprocessor/job queue. Batch processing it with the job queue means instead of having a half hour of horrific lag(where you have thousands of database connections and nothing can load) you queue up the change and then half multiple hours of much more negligbile lag(where you just double the normal page loads).Super simple version is instead of having 5000 pages load when you edit danger reports it makes it so that for the next 5000 pages loaded you're basically loading 2 pages. --Karekmaps 2.0?! 18:49, 18 June 2013 (BST)- It sounds like you may have accidentally said the opposite of what you meant. Just to double check, as you said above, the queue adds jobs on a per-page basis, which means that the Danger Center is processed as a single job, just as each of those other pages is also processed as a single job (though clearly the Danger Center is a larger job). When a user visits a page, the wiki does the job at the front of the queue before it delivers the page to the user. When a danger report gets updated, each page that transcludes that danger report will receive a corresponding job to update the page. For those smaller pages, because they each have their own job, they get spread out over a number of page loads and cause no noticeable delay. For the Danger Center, it too is done as a single job attached to a single page load, but because it's a much larger job it creates an extremely noticeable delay (i.e. it does the 5000+ db operations you're talking about). I think that's what you meant to say, but please correct me if I'm mistaken. —Aichon— 19:55, 18 June 2013 (BST)
- A lot of this is going to be process descriptive but not exact to how the code runs. It functions like a php include that contains a class with only a single method that's being batch processed. What happens is essentially when you update a template it checks to see how many rows return in the table(see picture below) of transclusions. It then adds those pages(where the template is transcluded) to the jobs queue if there are more than a certain number.
The jobs queue then runs a preprocessor on each of those individual pages. The preprocessor runs through the page content sequentially until it finds text matching what it sees as a template call. It then runs that call through a check against all other held templates/functions already preprocessed, if it returns that none are already stored it queues up a database call to the page(usually a template) being transcluded. It searches for include only tags then for noinclude tags to determine content and then converts the uneliminated text into XML Trees and stores this as a callable variable to be referenced when the same template is called later in the text. That means it only calls the template from the database once per page instead of however many times the template is included in the page.
Once the preprocessor sets limits on the generated text size for the final result and stops converting template content after a certain point. There are a number of reasons for this but the biggest one I can imagine would relate to the topic of this white paper microsoft released a few years back(pages are stored in blobs) about large file vs blob performance. The end result all then gets thrown through the parser when the page is called which converts wikitext like to it's output state.
My understanding is thus that when a page does not hit the rows returned in the 'Pages Included On' check it runs the preprocessor in reverse, thus processing all of the pages then and there making x calls where x is the amount of pages it's included on. When it determines that this would be too much strain for the server based on the limits set it instead queues them up for batch processing so that the calls are processed at a set interval and not all at once. --Karekmaps 2.0?! 03:07, 19 June 2013 (BST)- I love the technical description (honestly, I do), but that's actually tangential to what I was asking. You already explained the details below, and I thought it was well understood that that's what the function of the job queue is, since it's basically just "baking" elements for later use. What I was talking about was specifically the un-struck line you left, since the problem we're having is that it's not being broken up into 5000 jobs, which is what it sounds like you were suggesting is happening. That's why I said you sounded like you were saying the opposite of what you meant. ;) —Aichon— 05:34, 19 June 2013 (BST)
- I was insanely oversimplifying, the default value is 500 operations and each job itself is 500 operations. So with a current job queue of 6 that's roughly 3000 transclusions. Basically it is just the numbers are obscured, additionally Kevan might have changed it but it's unlikely. --Karekmaps 2.0?! 06:16, 19 June 2013 (BST)
- I love the technical description (honestly, I do), but that's actually tangential to what I was asking. You already explained the details below, and I thought it was well understood that that's what the function of the job queue is, since it's basically just "baking" elements for later use. What I was talking about was specifically the un-struck line you left, since the problem we're having is that it's not being broken up into 5000 jobs, which is what it sounds like you were suggesting is happening. That's why I said you sounded like you were saying the opposite of what you meant. ;) —Aichon— 05:34, 19 June 2013 (BST)
- A lot of this is going to be process descriptive but not exact to how the code runs. It functions like a php include that contains a class with only a single method that's being batch processed. What happens is essentially when you update a template it checks to see how many rows return in the table(see picture below) of transclusions. It then adds those pages(where the template is transcluded) to the jobs queue if there are more than a certain number.
- It sounds like you may have accidentally said the opposite of what you meant. Just to double check, as you said above, the queue adds jobs on a per-page basis, which means that the Danger Center is processed as a single job, just as each of those other pages is also processed as a single job (though clearly the Danger Center is a larger job). When a user visits a page, the wiki does the job at the front of the queue before it delivers the page to the user. When a danger report gets updated, each page that transcludes that danger report will receive a corresponding job to update the page. For those smaller pages, because they each have their own job, they get spread out over a number of page loads and cause no noticeable delay. For the Danger Center, it too is done as a single job attached to a single page load, but because it's a much larger job it creates an extremely noticeable delay (i.e. it does the 5000+ db operations you're talking about). I think that's what you meant to say, but please correct me if I'm mistaken. —Aichon— 19:55, 18 June 2013 (BST)
- What Karek is saying (and what I was typing up before I saw that he had already linked exactly what I was going to say) is that the Danger Center is a gigantic job, whereas the other pages are not. The reason that matters, is because the wiki is configured to process one job in the queue per page load. As such, those smaller pages are not even getting processed at the same time as the Danger Center and are thus in no way contributing to the unresponsiveness that people are suffering. To draw an imperfect analogy, the job queue is like a relay race where every time the baton is passed a page gets loaded for a user. In this race, some runners (jobs) are slower than others. Quite obviously, you can improve the speed of the faster runners all you want, but you'll still be waiting the exact same amount of time for the slower ones to complete their laps and pass the baton. So, more or less, those smaller pages aren't contributing to the problem at all, since the unresponsiveness they create is separate from what people are complaining about and is small enough that most of us have never noticed it at all. —Aichon— 18:39, 18 June 2013 (BST)
- I still don't really understand? The lag increased when we added the danger center, and it occurs more when updating the danger reports than when you look at the center itself. AFAIK the amount of times a danger report is called upon has a direct influence on that lag, ergo reducing the amount of maps that call upon a danger report should reduce the overall lag. Right? PB&J 16:59, 18 June 2013 (BST)
- In this case it would make no difference because it's a by page thing and not a by call thing. --Karekmaps 2.0?! 16:50, 18 June 2013 (BST)
- Quite a lot of the pages I'm talking about are like this one, and call on about 50 everytime a single one of them changes. If we look at the "What links here" of the first one in the topleft corner, Special:WhatLinksHere/User:DangerReport/Palprey_Road_Police_Department, one which is among the lesser used ones and lesser known ones, we see that several of those pages call on dozens of templates, including used, unused and personal test status maps, as well as specific building status maps (in this case the PD Status Map. That could amount to quite a lot of pages, each calling on a couple dozen templates, just for one danger report update, no? PB&J 15:18, 18 June 2013 (BST)
- This may help some. The Job Queue, from my understanding, basically functions like the preprocessor for templates so that the stored wiki text can be served faster on significantly large template calls to minimize load time. Templates are thrown into the job queue based on how many pages need to be preprocessed and it converts them into wiki-text/html there. Because job queue processing isn't done through a cron or based on server load it's happenning while other things are being done on the server, so lag will increase be it 1 template call on a page or 10 as it's running the same script either way. As far as impact on performance, because there's no additional complexity to the call(you should only have to queue up the template's content once regardless) it's of neglible impact of processing speed. You get a bigger impact from an increase in unique templates as 0-1 is where you're having to open a new file stream or make a new databse connection(which is likely the cause of the lag). Preprocessor ref. This is also one of many reasons templated signatures suck, they slow down the wiki for everyone, particularly more so the more pages they're on. --Karekmaps 2.0?! 18:43, 18 June 2013 (BST)
Too bad, I really hoped to optimize this whole thing... Then again: the danger reports are updated regularly these days, even more with BB4, and that was always one of the goals :) Maybe I'll go on a little wiki-patrol later today and just list a ton of stuff that can be deleted or otherwise archived to clean the whole wiki a bit out. PB&J 12:54, 19 June 2013 (BST)
- If you want to optimize these pages you could make the core templates use non-wikicode code, here's a list m:Help:HTML_in_wikitext, it'll reduce the work done when the parser runs. --Karekmaps 2.0?! 22:12, 19 June 2013 (BST)
Mob Locator Map Style Practice
Hi Aichon, you should update the comment on http://wiki.urbandead.com/index.php?title=Militant_Order_of_Barhah/Locator&action=edit§ion=3 to reflect the actual practice which is used to colour the map. greetings Ja7 13:09, 25 June 2013 (BST)
- Sorry, I got it wrong. See my edits to MOB Locator. —The preceding unsigned comment was added by Ja7 (talk • contribs) 13:12, 25 June 2013.
A/SA questions
I'm planning to start moving the A/PM archives into A/SA format, and I had a couple questions.
- What do we do about awkward redlinking of archives for those who were never sysops? Example - "Akule" is redlinked in the breadcrumbs.
- I'm planning to convert the A/PM navtemplates so they can be kept in one location, and am adding a key to make them more detailed. Would something like that (or which already exists for A/BP) be useful for A/RE and A/M as well? (Not to be included on each page, but be in one location for cross-referencing.)
Thanks! Bob Moncrief EBD•W! 16:40, 18 August 2013 (BST)
- There's nothing saying we can't make pages for the non-sysops too, and with your changes to put it all in tables, it seems like the concerns we have about it taking up too much space have been alleviated pretty well. I'm thinking give them their own page, and kill two birds (the red-link and the fact that the table will get bulky as we add data) with one stone.
- As for the key, I kinda feel like the improved categorization is designed to remove the need for keys and color-coding sort of stuff, though the categories could definitely be better-linked from A/SA in order to make them more useful. —Aichon— 21:50, 18 August 2013 (BST)
IRC
Can you jump on when you've got a minute, please? --BOSCH 20:50, 20 August 2013 (BST)
A/D
As a note, Revenant's revelation would be what would normally be a checkuser policy allowance. In this case he actually would probably be one of the better authorities on this since he can potentially compare it to one of the various RG boards. Odds are this is another Nubis type situtation in which case you guys should lock the account in question and send an email via the wiki, if possible, letting him know what has happened, why, and how he can contact one of you guys to resolve it. --Karekmaps 2.0?! 04:48, 26 August 2013 (BST)
Editing building pages........
Am i allowed to edit Building pages,particularly the Krinks power station description and make changes to it.
Another question.If i were to post in the current description should i remove the "please sign your post " thing or should i just post on there and leave it like that?PayneTrain(NWO/FU) 16:31, 1 September 2013 (BST)
- You're allowed to make changes to the descriptions of location pages, provided that your changes are in good faith and are written from a neutral point of view (they're unowned pages in the main space, so anyone is free to edit them, so long as they follow those two guidelines, more or less). And if you're making edits to the current news for a building...well, to be honest, I wouldn't, since those sections are rarely used or looked at...but if you do, then I'd leave the instructions to sign your posts, but then would comment underneath it, probably. —Aichon— 21:48, 1 September 2013 (BST)
really?
If you're going to lock cobras edit at least post an opinion on the new edits on the krinks talk page, please. This is not an issue of NWO vs cobra, this is an issue of cobra smudging our integrity, I hope you can give a decent 3rd party perspective on thus subject for the sake of the wiki and the one of the few posting rules you can enforce. Thanks H4ppy 24 7 03:52, 11 September 2013 (BST)
- No, this isn't about any of those things. This is about the two of you acting like children and me taking away your toys until you learn to play nice with each other. The point is not for me to get involved; it's for you two to figure this out between yourselves while the page remains temporarily protected for a day or two, as per our standard procedure in response to edit warring. I'm not going to shove myself into this as a mediator with a third-party perspective. This is between you guys. I'm just giving you a few days to mull it over. —Aichon— 04:03, 11 September 2013 (BST)
You make me cry
How dare you don't list me as arbitraorer. --Rosslessness 21:08, 11 September 2013 (BST)
- You're not the only one, Ross. I've been left out too. Damn it, Aic. I thought we had something special. :( I demand to be listed or I shall take you to Arby's for not listing me as arbitrator! --Axe Hack: The Legend Returns to the Wiki 21:31, 11 September 2013 (BST)
- You've already been turned down by others. I only listed names that hadn't been turned down yet. —Aichon— 21:36, 11 September 2013 (BST)
- I want a divorce. :( --Axe Hack: The Legend Returns to the Wiki 21:59, 11 September 2013 (BST)
- We promised each other we'd never say the D-word! —Aichon— 22:22, 11 September 2013 (BST)
- I want Grim to arbitrate. He is the ultimate jury, judge, and witnesses all in one. --Axe Hack: The Legend Returns to the Wiki 22:53, 11 September 2013 (BST)
- We promised each other we'd never say the D-word! —Aichon— 22:22, 11 September 2013 (BST)
- I want a divorce. :( --Axe Hack: The Legend Returns to the Wiki 21:59, 11 September 2013 (BST)
- You've already been turned down by others. I only listed names that hadn't been turned down yet. —Aichon— 21:36, 11 September 2013 (BST)
- I thought about adding you, but you have a knack for handing out even-handed judgments that leave both sides feeling like they didn't get everything they wanted out of the case. That's good most of the time, but it's not what I want here. Treat the omission of your name as a compliment. ;) —Aichon— 21:36, 11 September 2013 (BST)
- At least he didn't exclude you in particular like he did me XD Bob Moncrief EBD•W! 22:00, 11 September 2013 (BST)
- You got excluded for basically the same reason as Ross. Take it as the compliment it was intended to be. :P —Aichon— 22:22, 11 September 2013 (BST)
- i accept. think cyber will agree?--User:Sexualharrison02:55, 12 September 2013
- You got excluded for basically the same reason as Ross. Take it as the compliment it was intended to be. :P —Aichon— 22:22, 11 September 2013 (BST)
I come back to find you embroiled in the most drama-tic thing going on on the wiki? Times certainly have changed.--Yonnua Koponen Talk ! Contribs 02:30, 13 September 2013 (BST)
- I'm as surprised as you are. I figured there'd be an arbitration case at some point, since things were building in that direction, but not yet, and certainly not involving me. In fact, they just made their opening statements and didn't list a single complaint against me. It's just bizarre. —Aichon— 02:37, 13 September 2013 (BST)
- it really didn't take much. and I'm surprised i'm not personally in the case. oh well
--User:Sexualharrison03:06, 13 September 2013
- Can I make a parody page of an arbitration page? I'll use all the nice lines and stuff that DT is using. Any rule against that?--Seekandyeshallfind QI PK 03:07, 13 September 2013 (BST)
- it really didn't take much. and I'm surprised i'm not personally in the case. oh well
May I ask?
User_talk:Ayu_Milady/Archives is this okay or not? and.. where should I ask for things like this? thanks :) --Ayu Milady NWO member (┛ò__ó)┛彡┻━┻ 08:10, 14 September 2013 (BST)
