Posted
almost 7 years
ago
by
Wraithan McCarroll
NIH (Not Invented Here) is a common initialism that refers to excluding solutions that the project itself did not create. For example, some game studios NIH their own game engines, where others license an existing engine. There are advantages to both
... [More]
and neither is always correct. For me, I have a tendency to NIH things when working in Rust. This post is to help me understand why.
When I started with Rust, I built an example bot for one of the The AI Games challenges. The focus of that project was parsing the protocol and presenting it in a usable way for folks to get started with and extend into their bot. I built my parser from scratch, at first focusing on getting it working. Then spending time looking at other parsers to see how they go faster, and what the their interfaces in Rust look like. I updated the implementation to account for this research and I learned a lot about both Rust itself and implementing low level parsers.
I did similar for another couple projects. Spending a lot of time implementing things that there were libraries to do or at least assist with. Something I’ve started to notice over time: I’m using libraries for the parts I used to NIH. Especially the more serious I am about completing the project.
In my broker I’m doing little parsing of my own. I resisted using PlainTalk for my text protocol because I didn’t want to write the parser in a few languages. I’m using JSON since most languages have an implementation already, even if it isn’t the best to type. My only libraries so far are for encoding and decoding the allowed formats automatically. This means my socket and thread handling has been all custom or built into Rust itself.
I definitely get joy out of working at those layers. Which is an easy explanation for NIHing those parts while working on a project in general. I’m also learning a lot about the design as I implement my own. But I find myself at a crossroad. Continuing to NIH the layer and spend a week on getting a workable socket, thread, and job handling story. Or I can entangle the fate of my project with the Rust community more. To explain lets talk about some pros and cons of NIH or using other’s projects.
NIHing something means you can build something custom to your situation. It often takes more up front time than using an external solution. Your project will need to bring in or build up the expertise to handle that solution. The more central to the heart of your project, the more you should NIH. If the heart of your project is learning, then it could make sense to NIH as much as possible.
Using something external means doing research into the many solutions that could fit. Narrowing down to a final few or one solutions to try. Then learning how to use that solution and adapt it to your project. Often the solution is not a perfect fit but the savings on time and required expertise can make up for it. There is an accepted risk of the external project having different goals or being discontinued.
This morning I found myself staring down the problem of reading from my sockets in the server. Wanting to be efficient on resources I didn’t want to only rely on interval polling. I started by looking in the Rust standard library for a solution. The recommendations are to create a thread per connection, use interval polling, or external libraries. Thread per connection wont work for me with my goals. The resource cost of switching between a lot of threads shadows the cost of the work you are trying to perform. I had already ruled out interval polling. A less recommended path is wrapping the lower level mechanisms yourself.
So, I started looking into more and less complete solutions to these problems. When using less complete solutions, you can glue a few together. Creating a normalized interface on top of them that your project can use. The more complete solutions will do that normalization for you. Often at a cost of not closely matching your needs. This brings me to what I mean by entangling my project’s fate with the Rust community more.
Tokio is a project the Rust community has started to center around for building services, protocol parsers, and other tools. Designed to handle a large part of the asynchronous layer for users. I heard about it at RustConf 2016 and read about it in This Week In Rust. My understanding stayed high level and I’ve not had any serious Rust projects to apply it. I began looking into it as a solution for my broker and was delighted. Their breakdown of this problem is similar to how I have been designing my broker already. The largest difference being their inclusion of futures.
The architecture match with Tokio, as well as the community’s energy, makes it a good choice for me. I’ll need to learn more about their framework and how to use it well as I go. But, I’m confident I’ll be able to refactor my broker to run on top of it in a day or so. Then I can get the rest of the minimal story for this message broker done this week. Once I have it doing the basics with at least the Rust driver, I’ll open source it. [Less]
|
Posted
almost 7 years
ago
by
Denelle Dixon
This morning, the U.S. Supreme Court decided to hear the lawfulness of the U.S. Administration’s revised Travel Ban. We’ve opposed this Executive Order from the beginning as it undermines immigration law and impedes the travel necessary for people
... [More]
who build, maintain, and protect the Internet to come together.
Today’s new development means that until the legal case is resolved the travel ban cannot be enforced against people from the six predominantly Muslim countries who have legitimate ties or relationships to family or business in the U.S. This includes company employees and those visiting close family members.
However, the Supreme Court departed from lower court opinions by allowing the ban to be enforced against visa applicants with no connection to the U.S. We hope that the Government will apply this standard in a manner so that qualified visa applicants who demonstrate valid reasons for travel to the U.S. are not discriminated against, and that these decisions are reliably made to avoid the chaos that travelers, families, and business experienced earlier this year.
Ultimately, we would like the Court to hold that blanket bans targeted at people of particular religions or nationalities are unlawful under the U.S. Constitution and harmfully impact families, businesses, and the global community. We will continue to follow this case and advocate for the free flow of information and ideas across borders, of which travel is a key part.
The post Thoughts on the Latest Development in the U.S. Administration Travel Ban case appeared first on The Mozilla Blog. [Less]
|
Posted
almost 7 years
ago
by
Jean-Marc Valin
The Opus audio codec just got another major upgrade with the release of version 1.2 (see demo). Opus is a totally open, royalty-free, audio codec that can be used for all audio applications, from music streaming and storage to high-quality
... [More]
video-conferencing and VoIP. Its standardization by the Internet Engineering Task Force (IETF) in 2012 (RFC 6716) was a major victory for open standards. Opus is the default codec for WebRTC and is now included in all major web browsers.
This new release brings many speech and music quality improvements, especially at low bitrates. The result is that Opus can now push stereo music bitrates down to 32 kb/s and encode full-band speech down to 14 kb/s. All that is achieved while remaining fully compatible with RFC 6716. The new release also includes optimizations, new options, as well as many bug fixes. This demo shows a few of the upgrades that users and implementers will care about the most, including audio samples. For those who haven’t used Opus yet, now’s a good time to give it a try. [Less]
|
Posted
almost 7 years
ago
We enabled HTTP/2 on MDN’s CDN.
We didn’t do anything to optimize for HTTP/2, we just enabled it.
We’re seeing performance improvements.
You don’t have to get ready before you start using HTTP/2
While doing research to see if turning it on
... [More]
without doing any optimizations was
a good idea I read things like:
“It also means that all of those HTTP1 performance techniques are harmful.
They will make a HTTP2 website slower, not faster - don’t use them.” -
HTTP2 for front-end web developers
And:
“However, many of the things you think of as being best practices can be
detrimental to performance under HTTP/2.” - Getting Ready For HTTP2: A Guide
For Web Designers And Developers
Which suggest that enabling HTTP/2 on a site optimized for HTTP/1.1 could result
in a slower site.
A better way to interpret those quotes is:
If you optimize for HTTP/1.1 and turn on HTTP/2 your site will not be as fast
as it could be - but it might still be faster!
On MDN we concatenate a lot of our files but we don’t concatenate all of them.
For example, our article pages have 9 different files coming from our CDN. I
thought we could benefit from a bit of HTTP/2’s multiplexing and header
compression. And we did. You can see the DNS lookup time drop off in this
waterfall from Pingdom:
Some numbers
Overall, our tests don’t show a huge improvement in page load speed but there
are small improvements for everyone, and a real improvement for users located
far away from our servers. (Hi Australia and China!)
Service
Location
Browser
HTTP/1.1
HTTP/2
Change
Pingdom
Dallas
Chrome
1.54s
1.34s
0.2s
Pingdom
Melbourne
Chrome
2.94s
2.80s
0.14s
WebPageTest
London
IE11
2.39s
2.37s
0.02s
WebPageTest
Australia
Firefox
5.61s
5.17s
0.44s
Google Analytics
All
Chrome
3.74s
3.04s
0.7s
Google Analytics
All
Firefox
3.99s
3.71s
0.28s
Google Analytics
Australia
All
3.01s
1.69s
1.32s
Google Analytics
China
All
8.10s
6.69s
1.41s
I tried to segment our users in Google Analytics to make sure we did not have
a negative impact on users relying on HTTP/1.1 and… I couldn’t find enough
users to draw any conclusions. MDN is lucky like that. (It’s possible the IE11
test in the table above is on Windows 7 and does not support HTTP/2, but
WebPageTest doesn’t identify the OS.) In theory, older browsers
should not be affected because the protocol falls back to HTTP/1.1.
There was a lot of variation in the page speed data I examined. I recommend
running your before and after benchmark tests multiple times on multiple days
so you can take an average. Try to wait a week before drawing conclusions
from your analytics data as well.
In a perfect world you don’t increase the amount of code on your site or
invalidate anyone’s caches in the sample time period, but we don’t
develop in a perfect world.
Read more on HTTP/2
HTTP2 for front-end web developers
Getting Ready For HTTP2: A Guide For Web Designers And Developers
HTTP/2 For Web Developers
Next
Get our pages into data centres around the world.
This involves changing our hosting services, not a small task, and changing our
pages to serve the same content to all logged out users.
Decrease asset size by removing support for older browsers.
If you think working on MDN was a great job because we have very modern browser
support requirements, remember we’re also working on a 10 year old code
base.
Thanks for using MDN! [Less]
|
There are several problems you have to endure once you own a car. If
you seem to have one with its battery, then you might want to learn how to restore a car battery. Buying something brand new have its rewards
however it also comes with a hefty
... [More]
price. Should you decide to lessen
your expenses, one way is by getting its battery reconditioned instead
of replacing it right away.
Most car [Less]
|
Posted
almost 7 years
ago
by
gerv
Version 2.5 of Mozilla’s Root Store Policy has now been published. This document incorporates by reference the Common CCADB Policy 1.0.1.
With this update, we have mostly worked through the backlog of modernization proposals, and I’d call this a
... [More]
policy fit for a transparent, openly-run root program in 2017. That doesn’t mean that there’s not more that could be done, but we’ve come a long way from policy 2.2, which we were using until six months ago, and which hadn’t been substantively updated since 2012.
We also hope that, very soon, more root store operators will join the CCADB, which will reduce everyone’s costs and administrative burdens on all sides, and hopefully allow root programs to be more responsive to changing circumstances and requests for inclusion or change.
[Less]
|
Posted
almost 7 years
ago
by
Alessio Placitelli
The data our Firefox users share with us is the key to identify and fix performance issues that lead to a poor browsing experience. Collecting it is not enough if we don’t manage to receive the data in an acceptable time-frame. My esteemed colleague Chris already wrote about this a couple of times: data latency … →
|
Posted
almost 7 years
ago
by
Alessio Placitelli
Defeating data latency on Firefox with the pingsender for shutdown pings.
|
Posted
almost 7 years
ago
by
Bevis Tseng
Use of multi-tab browsing is becoming heavier than ever as people spend more time on services like Facebook, Twitter, YouTube, Netflix, and Google Docs, making them a part of their daily life and work on the Internet.
Quantum DOM: Scheduling is a
... [More]
significant piece of Project Quantum, which focuses on making Firefox more responsive, especially when lots of tabs are open. In this article, we’ll describe problems we identified in multi-tab browsing, the solutions we figured out, the current status of Quantum DOM, and opportunities for contribution to the project.
Problem 1: Task prioritization in different categories
Since multiprocess Firefox (e10s) was first enabled in Firefox 48, web content tabs now run in separate content processes in order to reduce overcrowding of OS resources in a given process. However, after further research, we found that the task queue of the main thread in the content process was still crowded with tasks in multiple categories. The tasks in the content process can come from a number of possible sources: through IPC (interprocess communication) from the main process (e.g. for input events, network data, and vsync), directly from web pages (e.g. from setTimeout, requestIdleCallback, or postMessage), or internally in the content process (e.g. for garbage collection or telemetry tasks). For better responsiveness, we’ve learned to prioritize tasks for user inputs and vsync above tasks for requestIdleCallback and garbage collection.
Problem 2: Lack of task prioritization between tabs
Inside Firefox, tasks running in foreground and background tabs are executed in First-Come-First-Served order, in a single task queue. It is quite reasonable to prioritize the foreground tasks over than the background ones, in order to increase the responsiveness of the user experience for Firefox users.
Goals & solutions
Let’s take a look at how we approached these two scheduling challenges, breaking them into a series of actions leading to achievable goals:
Classify and prioritize tasks on the main thread of the content processes in 2 dimensions (categories & tab groups), to provide better responsiveness.
Preempt tasks that are running the background tabs if this preempting is not noticeable to the user.
Provide an alternative to multiple content processes (e10s multi) when fewer content processes are available due to limited resources.
Task categorization
To resolve our first problem, we divide the task queue of the main thread in the content processes into 3 prioritized queues: High (User Input and Refresh Driver), Normal (DOM Event, Networking, TimerCallback, WorkerMessage), and Low (Garbage Collection, IdleCallback). Note: The order of tasks of the same priority is kept unchanged.
Task grouping
Before describing the solution to our second problem, let’s define a TabGroup as a set of open tabs that are associated via window.opener and window.parent. In the HTML standard, this is called a unit of related browsing contexts. Tasks are isolated and cannot affect each other if they belong to different TabGroups. Task grouping ensures that tasks from the same TabGroup are run in order while allowing us to interrupt tasks from background TabGroups in order to run tasks from a foreground TabGroup.
In Firefox internals, each window/document contains a reference to the TabGroup object it belongs to, which provides a set of useful dispatch APIs. These APIs make it easier for Firefox developers to associate a task with a particular TabGroup.
How tasks are grouped inside Firefox
Here are several examples to show how we group tasks in various categories inside Firefox:
Inside the implementation of window.postMessage(), an asynchronous task called PostMessageEvent will be dispatched to the task queue of the main thread:
void nsGlobalWindow::PostMessageMozOuter(...) {
...
RefPtr event = new PostMessageEvent(...);
NS_DispatchToCurrentThread(event);
}
With the new association of DOM windows to their TabGroups and the new dispatching API provided in TabGroup, we can now associate this task with the appropriate TabGroup and specify the TaskCategory:
void nsGlobalWindow::PostMessageMozOuter(...) {
...
RefPtr event = new PostMessageEvent(...);
// nsGlobalWindow::Dispatch() helps to find the TabGroup of this window for dispatching.
Dispatch("PostMessageEvent", TaskCategory::Other, event);
}
In addition to the tasks that can be associated with a TabGroup, there are several kinds of tasks inside the content process such as telemetry data collection and resource management via garbage collection, which have no relationship to any web content. Here is how garbage collection starts:
void GCTimerFired() {
// A timer callback to start the process of Garbage Collection.
}
void nsJSContext::PokeGC(...) {
...
// The callback of GCTimerFired will be invoked asynchronously by enqueuing a task
// into the task queue of the main thread to run GCTimerFired() after timeout.
sGCTimer->InitWithFuncCallback(GCTimerFired, ...);
}
To group tasks that have no TabGroup dependencies, a special group called SystemGroup is introduced. Then, the PokeGC() method can be revised as shown here:
void nsJSContext::PokeGC(...) {
...
sGCTimer->SetEventTarget(SystemGroup::EventTargetFor(TaskCategory::GC));
sGCTimer->InitWithFuncCallback(GCTimerFired, ...);
}
We have now grouped this GCTimerFired task to the SystemGroup with TaskCategory::GC specified. This allows the scheduler to interrupt the task to run tasks for any foreground tab.
In some cases, the same task can be requested either by specific web content or by an internal Firefox script with system privileges in the content process. We’ll have to decide if the SystemGroup makes sense for a request when it is not tied to any window/document. For example, in the implementation of DNSService in the content process, an optional TabGroup-versioned event target can be provided for dispatching the result callback after the DNS query is resolved. If the optional event target is not provided, the SystemGroup event target in TaskCategory::Network is chosen. We make the assumption that the request is fired from an internal script or an internal service which has no relationship to any window/document.
nsresult ChildDNSService::AsyncResolveExtendedNative(
const nsACString &hostname,
nsIDNSListener *listener,
nsIEventTarget *target_,
nsICancelable **result)
{
...
nsCOMPtr target = target_;
if (!target) {
target = SystemGroup::EventTargetFor(TaskCategory::Network);
}
RefPtr childReq =
new DNSRequestChild(hostname, listener, target);
...
childReq->StartRequest();
childReq.forget(result);
return NS_OK;
}
TabGroup categories
Once the task grouping is done inside the scheduler, we assign a cooperative thread per tab group from a pool to consume the tasks inside a TabGroup. Each cooperative thread is pre-emptable by the scheduler via JS interrupt at any safe point. The main thread is then virtualized via these cooperative threads.
In this new cooperative-thread approach, we ensure that only one thread at a time can run a task. This allocates more CPU time to the foreground TabGroup and also ensures internal data correctness in Firefox, which includes many services, managers, and data designed intentionally as singleton objects.
Obstacles to task grouping and scheduling
It’s clear that the performance of Quantum-DOM scheduling is highly dependent on the work of task grouping. Ideally, we’d expect that each task should be associated with only one TabGroup. In reality, however, some tasks are designed to serve multiple TabGroups, which require refactoring in advance in order to support grouping, and not all the tasks can be grouped in time before scheduler is ready to be enabled. Hence, to enable the scheduler aggressively before all tasks are grouped, the following design is adopted to disable the preemption temporarily when an ungrouped task arrives because we never know which TabGroup this ungrouped task belongs to.
Current status of task grouping
We’d like to send thanks to the many engineers from various sub-modules including DOM, Graphic, ImageLib, Media, Layout, Network, Security, etc., who’ve helped clear these ungrouped (unlabeled) tasks according to the frequency shown in telemetry results.
The table below shows telemetry records of tasks running in the content process, providing a better picture of what Firefox is actually doing:
The good news is that over 80% of tasks (weighted with frequency) have cleared recently. However, there are still a fair amount of anonymous tasks to be cleared. Additional telemetry will help check the mean time between 2 ungrouped tasks arriving to the main thread. The larger the mean time, the more performance gain we’ll see from Quantum-DOM Scheduler.
Contribute to Quantum DOM development
As mentioned above, the more tasks are grouped (labeled), the more benefit we gain from the scheduler. If you are interested in contributing to Quantum-DOM, here are some ways you can help:
Pick any bug from labeling meta-bug without assignee and follow this guideline for labeling.
If you are not familiar with these unlabeled bugs, but you want to help on naming the tasks to reduce the anonymous tasks in the telemetry result to improve the analysis in the future, this guideline will be helpful to you. (Update: Naming anonymous tasks are going to be addressed by some automation tool in this bug.)
If you get started fixing bugs and run into issues or questions, you can usually find the Quantum DOM team in Mozilla’s #content IRC channel. [Less]
|
Posted
almost 7 years
ago
by
cbook
Hi,
first a super big thanks for taking part in this years Sheriff Survey – this helps us a lot !
Here are the results.
1. Overall “satisfaction” – we have asked how People rate their interaction with us (from 1 (bad) to 10 (best)
So far
... [More]
from all results:
3,1 % = 5
3,1 % = 7
12,5 % = 8
43,8 % = 9
37,5 % = 10
2. What can we do better as Sheriffs?
We got a lot of Feedback thats its not easy to find out who is on “sheriffduty”. We will take steps (like adding |sheriffduty tag to irc names etc) also we have https://bugzilla.mozilla.org/show_bug.cgi?id=1144589 with the target to have that name on treeherder.
Also we try to make sure to Set Needinfo requests on Backouts.
In any case, backouts are never meant to be personal and it’s part of our job to try our best to keep our trees open for developers. We also try to provide as much information as possible in the bug for why we
backed out a change.
3. Things we can improve in general (not just sheriffs) ?
A interesting Idea in the Feedback we got was about Automation. We will follow up from the Feedback and i already filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375520 for the Idea of having a “Backout Button” in Treeherder in case no Sheriff is around etc – more bugs from ideas to improve general stuff and workflows will follow.
Again thanks for taking part in the Survey and if you have questions/feedback/concerns/ideas you can of course contact me / the team at anytime !
Cheers,
– Tomcat
[Less]
|