the host and the cloud

Open Sourcing Daytona: A Framework For Automated and Application-agnostic Performance Analysis

By Sapan Panigrahi and Deepesh Mittal

Today, we are pleased to offer Daytona, an open-source framework for automated performance testing and analysis, to the community. Daytona is an application-agnostic framework to conduct integrated performance testing and analysis with repeatable test execution, standardized reporting, and built-in profiling support.

Daytona gives you the capability to build a customized test harness in a single, unified framework to test and analyze the performance of any application. You’ll get easy repeatability, consistent reporting, and the ability to capture trends. Daytona’s UI accepts a performance testing script that can run on a command line. This includes websites, databases, networks, or any workload you need to test and tune for performance. You can submit tests to the scheduler queue from the Daytona UI or from your CI/CD tool. You can deploy Daytona as a hosted service in your on-prem environment or on the public cloud of your choice. In fact, you can even host test harnesses for multiple applications with a single centralized service so that developers, architects, and systems engineers from different parts of your organization can work together on a unified view and manage your performance analysis on a continuous basis.

Daytona’s differentiation lies in its ability to aggregate and present essential aspects of application, system, and hardware performance metrics with a simple and unified user interface. This helps you maintain your focus on performance analysis without changing context across various sources and formats of data. The overall goal of performance analysis is to find ways of maximizing application throughput with minimum hardware resource and the best user experience. Metrics and insights from Daytona help achieve this objective.

Prior to Daytona, we created multiple, heterogenous performance tools to meet the specific needs of various applications. This meant that we often stored test results inconsistently, making it harder to analyze performance in a comprehensive manner. We had a difficult time sharing results and analyzing differences in test runs in a standard manner, which could lead to confusion.

With Daytona, we are now able to integrate all our load testing tools under a single framework and aggregate test results in one common central repository. We are gaining insight into the performance characteristics of many of our applications on a continuous basis. These insights help us optimize our applications which results in better utilization of our hardware resources and helps improve user experience by reducing the latency to serve end-user requests. Ultimately, Daytona helps us reduce capital expenditure on our large-scale infrastructure and makes our applications more robust under load. Sharing performance results in a common format encourages the use of common optimization techniques that we can leverage across many different applications.

Daytona was built knowing that we would want to publish it as open source and share the technology with the community for validation and improvement of the framework. We hope the community can help extend its use cases and make it suitable for an even broader set of applications and workloads.


Daytona is comprised of a centralized scheduler, a distributed set of agents running on SUTs (systems under test), a MySQL database to store all metadata for tests, and a PHP-based UI. A test harness can be customized by answering a simple set of questions about the application/workload. A test can be submitted to Daytona’s queue through the UI or through a CLI (Command Line Interface) from the CI/CD system. The scheduler process polls the database for a test to be run and sends all the actions associated with the execution of the test to the agent running on a SUT. An agent process executes the test, collects application and system performance metrics, and sends the metrics back as a package to the scheduler. The scheduler saves the test metadata in the database and test results in the local file system. Tests from multiple harnesses proceed concurrently.

External image

Architecture and Life Cycle Of A Test

Looking Forward

Our goal is to integrate Daytona with popular open source CI/CD tools and we welcome contributions from the community to make that happen. It is available under Apache License Version 2.0. To evaluate Daytona, we provide simple instructions to deploy it on your in-house bare metal, VM, or public cloud infrastructure. We also provide instructions so you can quickly have a test and development environment up and running on your laptop with Docker. Please join us on the path of making application performance analysis an enjoyable and insightful experience. Visit the Daytona Yahoo repo to get started!

empressfortuna  asked:

Do you have any advice for someone putting together an RPG system for fun and to maybe play with friends? It's something I've started a couple of times (and I have a concept I really like sitting around that I'd like to try to flesh out into a system at some point), but I'm interested in what advice an industry professional has for an amateur.

Sure thing:

1. Start small.

If you’re an author, you don’t write the next Game of Thrones as your very first work, and if you’re a game designer, you don’t go straight to writing the next Dungeons & Dragons.

A good target for a beginning designer is a game that can be set forth in about 5000 words - i.e., basically a sixteen-page pamphlet if you’re aiming for print publication. Have a look at other very short RPGs to get a feel for what the minimal set of stuff you need to include is. Good examples include:

Several of these look like they break my length guideline, but that’s because they include introductory fiction, sample adventures, GM advice sections, etc. Ignore all that for now - zero in on the rules themselves.

2. Start with premise.

Not setting, not mechanics - if you start with those, you’ll end up with a collection of neat worldbuilding bits and dice-rolling tricks that don’t actually add up to anything.

Have a clear idea in your head of what the prototypical session of your game, the Platonic ideal of an adventure, looks like from beginning to end, and ensure that all of the material you write - rules, setting, etc. - directly supports that premise. You can branch out later, but it’s absolutely critical that you get that core right first. If you’re not sure whether a given piece of material directly supports that core? It probably doesn’t - lose it.

3. Outline, outline, outline.

Resist the urge to just leap in and start writing. You can note stuff down for later if you want (see point 5, below), but if you just start writing, at best you’re going to end up with a disorganised mess; at worst, you’ll become irresolvably stuck when you run into some critical aspect of your premise that you haven’t thought about yet.

Good organisation is much more important in game rules than it is in prose fiction, so effort spent here pays off huge later. A good game outline should ideally drill all the way down to what you plan to talk about in each individual paragraph. Use headings and subheadings if you have to. When you’re finished, you should be able to start writing your game simply by picking a portion of your outline and filling it in.

4. Give yourself deadlines.

This is the corollary of point 1, above. Even within a work of limited scope, it’s easy to iterate forever and never get anywhere, or to turn things over and over in your head without ever committing it to writing until all your enthusiasm for it dribbles away. Your first RPG should take no more than a couple of weeks to write; make time to work on it every day during that span.

(In fact, writing a complete RPG of this scope in a single day is an exercise that a lot of designers use to keep themselves sharp. You can Google “24 hour RPG” for numerous examples. Do not attempt to do this as your very first game, of course - it’s basically hard mode game design.)

5. Take notes.

Once you’re in the game-creating headspace, neat ideas on how to address various bits of your premise will be occurring to you at all hours of the day. If you have school or a day job, it’ll often be at times when you can’t drop everything to chase after the idea in question. You may be confident that you’ll remember it for later. You will not. Keep a notebook or a tablet on hand so that you can jot stuff down as it occurs to you.

6. Be a dictator.

Don’t be afraid to tell people how they ought to play the game. Some folks will tell you that this is bad design. These people are wrong. All game rules encode assumptions about how the game ought to be played; some games are merely more honest about it than others. You’ll save yourself a heap of trouble by being one of the honest ones.

7. Beta readers. Lots of ‘em.

This ties into the preceding point: as you write, you’re going to be making a vast array of assumptions about how the game ought to be played and how the rules are supposed to be executed. Many of these assumptions will seem so obvious to you that it wouldn’t occur to you to write them down, or will be so deeply embedded in your thinking about the game that you don’t even realise you’re making them.

The ability to step back and go “okay, what assumptions am I making about the player’s understanding and prior knowledge, and are these assumptions warranted?” is a skill. Unless you’re a technical writer or something in your day job, you do not yet possess this skill. The upshot is that your first attempt at a game (and your second, and your third…) will be incomprehensible to anyone who’s not you.

This doesn’t mean you’re a bad game designer. It does, however, mean that you need to get as many sets of eyes on your work as possible, and you need to respect and seriously consider the questions they ask, no matter how obvious the answers feel to you.

8. Never throw anything away.

You’re going to have many ideas that you can’t find a place for in your game. You’re going to have many more that you end up cutting because they turn out not to directly support your premise (see point 2, above). Don’t just delete them - keep a master document of your of unused ideas, preferably on Google Drive or another cloud-hosted service so it’s always accessible and impossible to accidentally lose.

Not only are you accumulating a store of material for future projects, but emotionally it’ll be a lot easier to give material you’ve put a lot of thought and work into the axe because it’s not working out in your current game when you can tell yourself that you’re not getting rid of it for good: you’re just not using it right now.

The Great Podcast Masterlist

In which I list all the podcasts I am listening to or have listened to, including all that you’ll ever want to know about them before listening yourselves.

I update this regularly as I find new ones, and of course, any recs y’all might have (especially for narrative fiction podcasts, for which I have a particular soft spot) are always welcome.  Please also feel free to shoot me an ask if you’re after more personalised recs.

And of course, if you want to talk about any of the ones on this list (ie. rant about Cecilos or Eiffera or Adleb), my inbox is always open.

Keep reading


A Galaxy Far, Far Away Pheryon

An inner rim gas planet with floating cities that are buffeted by strong winds and roaring cloud-to-cloud lightning storms. Pheryon hosts stormsail races, visible from its capitol cantinas and glassed-in bleachers. Poe Dameron was tricked into a near-capture by the First Order on Pheryon when his longtime friend Suralinda Javos invited him there as a pretext to gather information about the then-secret (and illegal) Resistance.

It was then that Badb and Macha and Morrigan went to the Knoll of the Taking of the Hostages, and to the Hill of Summoning of Hosts at Tara, and sent forth magic showers of sorcery and compact clouds of mist and a furious rain of fire, with a downpour of red blood from the air on the warriors’ heads; and they allowed the Fir Bolg neither rest nor stay for three days and nights.
—  The First Battle of Magh Turedh


70) In addition to dead animals, the Glow Cloud sends hail to the PTA when it doesn’t get its way.

76) The Glow Cloud felt bad about destroying Cecil’s painting — after all, Cecil hadn’t been the actual target and the host has always had a pleasing intonation when hailing the mighty Glow Cloud.  Unfortunately, the Glow Cloud’s attempt at apology is not what either we or Cecil would recognize as an apology.  Or comprehend at all, for that matter.

79) The weather is codified. For example: songs about love are a sign of hail, songs about the Glow Cloud are a sign of “all hail!”

107) The Glow Cloud is actually Lumpy Space Princess from Adventure Time.

109) Night Vale changes those who move to it, but for the banal. Glow Clouds join the PTA, five-headed dragons run for mayor…and unscrupulous, cold-hearted scientists become adorkable boyfriends.

112) Deb and the Glow Cloud are distant relatives.

136) The Smiling God is Desert Bluffs’ version of the Glow Cloud.

157) Deb the Sentient Haze is the child of the Glow Cloud who is just entering the workforce, hence her sometimes nervous tone.

214) Of all the teenagers in Night Vale, the offspring of the Glow Cloud is by far the most embarrassed at its parents.

222) In Nulogorsk, the Glow Cloud HAILS ALL OF YOU.

Call for Osomatsu-san Artists!

Have you ever wanted to be featured in an art book or zine? Have you got a lot of love for a certain second brother? Have you got at least some sort of basic art skills? Then I have a proposition for you!

Do any of you remember this?

Yes, Karamatsu’s one-time gag, the “Beauty  Karamatsu” photo book. (just look at that toned body, those roses, those glasses, i’m shuddering)

The idea is to make “Beauty Karamatsu” a reality, available to read online or purchase a hard copy of from online for all Karamatsu Fans! 

It would basically be a nice big book full of pictures featuring and centering on Karamatsu, our lovely, painful, favorite brother.

Keep reading


** Synopsis: Using observations from ESA’s Venus Express satellite, scientists have shown for the first time how weather patterns seen in Venus’ thick cloud layers are directly linked to the topography of the surface below. Rather than acting as a barrier to our observations, Venus’ clouds may offer insight into what lies beneath. **

Venus is famously hot, due to an extreme greenhouse effect which heats its surface to temperatures as high as 450 degrees Celsius. The climate at the surface is oppressive; as well as being hot, the surface environment is dimly lit, due to a thick blanket of cloud which completely envelops the planet. Ground-level winds are slow, pushing their way across the planet at painstaking speeds of about 1 metre per second – no faster than a gentle stroll.

However, that is not what we see when we observe our sister planet from above. Instead, we spy a smooth, bright covering of cloud. This cloud forms a 20-km-thick layer that sits between 50 and 70 km above the surface and is thus far colder than below, with typical temperatures of about -70 degrees Celsius – similar to temperatures found at the cloud-tops of Earth. The upper cloud layer also hosts more extreme weather, with winds that blow hundreds of times faster than those on the surface (and faster than Venus itself rotates, a phenomenon dubbed ‘super-rotation’).

While these clouds have traditionally blocked our view of Venus’ surface, meaning we can only peer beneath using radar or infrared light, they may actually hold the key to exploring some of Venus’ secrets. Scientists suspected the weather patterns rippling across the cloud-tops to be influenced by the topography of the terrain below. They have found hints of this in the past, but did not have a complete picture of how this may work – until now.

Scientists using observations from ESA’s Venus Express satellite have now greatly improved our climate map of Venus by exploring three aspects of the planet’s cloudy weather: how quickly winds on Venus circulate, how much water is locked up within the clouds, and how bright these clouds are across the spectrum (specifically in ultraviolet light).

“Our results showed that all of these aspects – the winds, the water content, and the cloud composition – are somehow connected to the properties of Venus’ surface itself,” says Jean-Loup Bertaux of LATMOS (Laboratoire Atmosphères, Milieux, Observations Spatiales) near Versailles, France, and lead author of the new Venus Express study. “We used observations from Venus Express spanning a period of six years, from 2006 to 2012, which allowed us to study the planet’s longer-term weather patterns.”

Although Venus is very dry by Earth standards, its atmosphere does contain some water in the form of vapour, particularly beneath its cloud layer. Bertaux and colleagues studied Venus’ cloud-tops in the infrared part of the spectrum, allowing them to pick up on the absorption of sunlight by water vapour and detect how much was present in each location at cloud-top level (70 km altitude).

They found one particular area of cloud, near Venus’ equator, to be hoarding more water vapour than its surroundings. This ‘damp’ region was located just above a 4,500-metre-altitude mountain range named Aphrodite Terra. This phenomenon appears to be caused by water-rich air from the lower atmosphere being forced upwards above the Aphrodite Terra mountains, leading researchers to nickname this feature the ‘fountain of Aphrodite.’

“This ‘fountain’ was locked up within a swirl of clouds that were flowing downstream, moving from east to west across Venus,” says co-author Wojciech Markiewicz of the Max-Planck Institute for solar system Research in Göttingen, Germany. “Our first question was, ‘Why?’ Why is all this water locked up in this one spot?”

In parallel, the scientists used Venus Express to observe the clouds in ultraviolet light, and to track their speeds. They found the clouds downstream of the ‘fountain’ to reflect less ultraviolet light than elsewhere, and the winds above the mountainous Aphrodite Terra region to be some 18 percent slower than in surrounding regions.

All three of these factors can be explained by one single mechanism caused by Venus’ thick atmosphere, propose Bertaux and colleagues.

“When winds push their way slowly across the mountainous slopes on the surface they generate something known as gravity waves,” adds Bertaux. “Despite the name, these have nothing to do with gravitational waves, which are ripples in space-time – instead, gravity waves are an atmospheric phenomenon we often see in mountainous parts of Earth’s surface. Crudely speaking, they form when air ripples over bumpy surfaces. The waves then propagate vertically upwards, growing larger and larger in amplitude until they break just below the cloud-top, like sea waves on a shoreline.”

As the waves break, they push back against the fast-moving high-altitude winds and slow them down, meaning that winds above Venus’ Aphrodite highlands are persistently slower than elsewhere.

However, these winds re-accelerate to their usual speeds downstream of Aphrodite Terra – and this motion acts as an air pump. The wind circulation creates an upwards motion in Venus’ atmosphere that carries water-rich air and ultraviolet-dark material up from below the cloud-tops, bringing it to the surface of the cloud layer and creating both the observed ‘fountain’ and an extended downwind plume of vapour.

“We’ve known for decades that Venus’ atmosphere contains a mysterious ultraviolet absorber, but we still don’t know its identity,” says Bertaux. “This finding helps us understand a bit more about it and its behaviour – for example, that it’s produced beneath the cloud-tops, and that ultraviolet-dark material is forced upwards through Venus’ cloud-tops by wind circulation.”

Scientists already suspected that there were ascending motions in Venus’ atmosphere all along the equator, caused by the higher levels of solar heating. This finding reveals that the amount of water and ultraviolet-dark material found in Venus’ clouds is also strongly enhanced at particular places around the planet’s equator. “This is caused by the mountains way down on Venus’ surface, which trigger rising waves and circulating winds that dredge up material from below,” says Markiewicz.

As well as helping us understand more about Venus, the finding that surface topography can significantly affect atmospheric circulation has consequences for our understanding of planetary super-rotation, and of climate in general.

“This certainly challenges our current general circulation models,” says Håkan Svedhem, ESA Project Scientist for Venus Express. “While our models do acknowledge a connection between topography and climate, they don’t usually produce persistent weather patterns connected to topographical surface features. This is the first time that this connection has been shown clearly on Venus – it’s a major result.”

Venus Express was in operation at Venus from 2006 until 2014, when its mission concluded and the spacecraft began its descent through Venus’ atmosphere.

The study by Bertaux and colleagues made use of several years of Venus Express observations gathered by the Venus Monitoring Camera (VMC) – to explore the wind speeds and ultraviolet brightness of the clouds – and by the SPICAV (Spectroscopy for Investigation of Characteristics of the Atmosphere of Venus) spectrometer – to study the amount of water vapour contained within the clouds.

“This research wouldn’t have been possible without Venus Express’ reliable and long-term monitoring of the planet across multiple parts of the spectrum. The data used in this study were collected over many years,” adds Svedhem. “Crucially, knowing more about Venus’ circulation patterns may help us to constrain the identity of the planet’s mysterious ultraviolet absorber, so we can understand more about the planet’s atmosphere and climate as a whole.”