date:20170410

[Wikidata-bugs] [Maniphest] [Updated] T161342: Missing updates due to recentchanges backfilling

2017-04-10 Thread gerritbot

gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T161342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, Smalyshev, Aklapper, Jheald, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, Salgo60, Avner, Lewizho99, Maathavan, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T161342: Missing updates due to recentchanges backfilling

2017-04-10 Thread gerritbot

gerritbot added a comment.
Change 347565 had a related patch set uploaded (by Smalyshev):
[operations/puppet@production] Enable "trailing poller" functionality for production.

https://gerrit.wikimedia.org/r/347565TASK DETAILhttps://phabricator.wikimedia.org/T161342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, Smalyshev, Aklapper, Jheald, QZanden, EBjune, merbst, Salgo60, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T161342: Missing updates due to recentchanges backfilling

2017-04-10 Thread Smalyshev

Smalyshev claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T161342EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Jheald, QZanden, EBjune, merbst, Salgo60, Avner, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T162230: Updater gets stuck if batchSize is short

2017-04-10 Thread Smalyshev

Smalyshev closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T162230EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, Aklapper, Smalyshev, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, EBjune, merbst, Salgo60, Avner, Lewizho99, Maathavan, debt, Gehel, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T153729: CI tests throw warning "Cannot find site mywiki in sites table"

2017-04-10 Thread gerritbot

gerritbot added a comment.
Change 346916 abandoned by Krinkle:
Use default wiki id in example settings.

Reason:
Closing in favour of I1a52ce07943f20c - which is how it was fixed in master as well.

https://gerrit.wikimedia.org/r/346916TASK DETAILhttps://phabricator.wikimedia.org/T153729EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Tgr, gerritbotCc: Tobi_WMDE_SW, KartikMistry, Amire80, santhosh, StudiesWorld, JanZerebecki, hoo, aude, Bene, demon, hashar, daniel, Lydia_Pintscher, thiemowmde, Nikerabbit, TerraCodes, Jay8g, gerritbot, Paladox, Aklapper, Tgr, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Salgo60, Lewizho99, Maathavan, Izno, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T124418: Investigate massive increase in htmlCacheUpdate jobs in Dec/Jan

2017-04-10 Thread Krinkle

Krinkle edited projects, added Performance-Team; removed MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-07-05_(1.28.0-wmf.9)), Patch-For-Review, MediaWiki-JobRunner.
TASK DETAILhttps://phabricator.wikimedia.org/T124418EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: KrinkleCc: GWicke, ArielGlenn, Krinkle, Peter, EBernhardson, Smalyshev, gerritbot, Legoktm, Addshore, daniel, hoo, aude, Lydia_Pintscher, JanZerebecki, MZMcBride, Luke081515, aaron, faidon, Joe, ori, BBlack, Aklapper, Th3d3v1ls, Hfbn0, QZanden, Vali.matei, Salgo60, Zppix, Izno, Wikidata-bugs, Mbch331, Jay8g, fgiunchedi___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T162111: Make WDQS active / active

2017-04-10 Thread Gehel

Gehel moved this task from Backlog to Done on the Discovery-Search (Current work) board.Gehel added a comment.
grafana dashboard was wrongly filtering on eqiad only (that's why I did not see any traffic there). More tests and checking x-cache and x-served-by headers show that indeed traffic is routed to codfw as well. All looks good!TASK DETAILhttps://phabricator.wikimedia.org/T162111WORKBOARDhttps://phabricator.wikimedia.org/project/board/1227/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GehelCc: BBlack, Stashbot, gerritbot, Smalyshev, Gehel, Aklapper, Th3d3v1ls, Hfbn0, QZanden, EBjune, merbst, Salgo60, Avner, Zppix, debt, Jdrewniak, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, faidon, Mbch331, Jay8g, fgiunchedi___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T159787: Add Wikidata to new RC Filters UI

2017-04-10 Thread Etonkovidova

Etonkovidova added subtasks: T162628: 'Wikidata edits' filter does not recognize registered wikidata users  , T162630:  'Wikidata edits' filter with 'Contribution quality prediction' or  'User intent prediction' returns results  but the filter selection displayed as a conflict.
TASK DETAILhttps://phabricator.wikimedia.org/T159787EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Mattflaschen-WMF, EtonkovidovaCc: Etonkovidova, Liuxinyu970226, Catrope, gerritbot, Aklapper, Mattflaschen-WMF, Adik2382, Th3d3v1ls, Ramalepe, Liugev6, QZanden, Salgo60, Lewizho99, Maathavan, Iniquity, jmatazzoni, Izno, SBisson, Wikidata-bugs, aude, Mbch331, tarlocesilion___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T157014: CONSULTATION/PLAN: Managing Complex State and GUI on MediaWiki (e.g. for Wikidata/Wikibase UI)

2017-04-10 Thread GWicke

GWicke added a comment.

In T157014#3168034, @daniel wrote:
AFAIK we do have infrastructure for running node servers with proper caching, as part of the rest services layer.
If you create endpoints that return structured data you could consume those from the PHP backend or the JS client.

We have node based rendering infrastructure, but as far as I know, we cannot use them to directly serve page views. Because a) all the skin/chrome stuff is done in PHP and b) we currently only use node when editing, and don't have the server capacity to handle several orders of magnitude more hits that would be needed for serving page views.

We aren't using node for UI rendering at scale, but at the API level the REST API is seeing 15 minute averages of more than 6k requests per second most days. This is comparable to the action API: https://grafana-admin.wikimedia.org/dashboard/db/api-summary?orgId=1=now-30d=now

The vast majority of this traffic is driven by read views and data retrieval. Cache hit rate is already ~95%, and rising with traffic levels.

So, we can use node.js to render stuff, but we still need to loop it through PHP to add chrome.

This depends on the roll-out strategy. The standard chrome elements are actually not *that* hard to replace. Long tail special-case interfaces rendered in the content area like special pages etc will take longer, or might not make sense to re-do at all. See https://phabricator.wikimedia.org/T114596.

We also need caching for this on the same level as the parser cache. That could be done on the HTTP level between PHP and node. Does this exist?

We touched on this in the mail thread. Most API responses and server-side UI renders for anonymous users would be cached in the CDN / Varnish.TASK DETAILhttps://phabricator.wikimedia.org/T157014EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: GWickeCc: GWicke, Aleksey_WMDE, daniel, Niedzielski, Magnus, Milimetric, Prtksxna, Fjalapeno, phuedx, Jdlrobson, siddharth11, Capt_Swing, TheDJ, Jdforrester-WMF, SBisson, WMDE-leszek, Volker_E, Krinkle, gabriel-wmde, Jonas, thiemowmde, Lydia_Pintscher, Jan_Dittrich, Jhernandez, Jdrewniak, Aklapper, QZanden, Salgo60, SamanthaNguyen, JGirault, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

74 matches

Mail list logo