pieroxy.netjavascript

Remote real time computer monitoring

Tue, 27 Jul 2021 05:48:00 GMT

Conkw is a new project I've been working on for a few month. It stands for web-based Conky.

Just like Conky, it is aimed at hobbyists that want a small dashboard where their most essential data is displayed. CPU, temperature, fan speeds, but also the weather forecast, stock market, latest emails received, etc.

Unlike conky, the metrics are exposed through a REST API and there is a HTML UI to display your stuff on any browser. The goal is to find some use to the old ipads/tablets/laptops we all have lying around. You can put them next to your screen and have your metrics displayed there, with no real estate consumed from your screens. The UI has been properly prepared to run on old browsers.

The very nature of the web based architecture allows a conkw running on a machine to send all of its metrics to another central one for instance. So it is right out of the box ready to monitor a large park of machines, all reporting to one or more central instances.

It is also very lightweight to deploy as it stores nothing, it is real time! As such, one other way of using it is to gather all of your monitoring data through one instance, and have all that data exported to grafana, graphite or any other monitoring system that stores data.

Hop on the github for more details.

Apple is so great

Fri, 24 Apr 2020 07:29:00 GMT

Apple invented the personal computer with the Apple II, igniting the personal computer revolution. Apple is unique in that regard.

Apple made the mouse ubiquitous and popular, as well as the GUI. That's goundbreaking.

Apple changed twice of CPU architecture (68k -> PPC -> x86) in their computers, maintaining backward compatibility. That's no small feat.

Apple invented what we know today as being a smartphone. "The smartphone revolution". That was Apple starting it.

Apple introduced tablets and is arguably the biggest tablet manufacturer in the world. In fact, it produces one third of all tablets produced. Wow!

No other company has that track record.

Yet, Apple, to this day, still fails at making available to devs the number of pixels available for a webpage. CSS doesn't know. JavaScript doesn't know. HTML doesn't know. There is no way.

No other company has that track record indeed.

node.js vs Java nashorn

Mon, 29 Jun 2015 19:52:00 GMT

Why did I test it?

In my current Java project, I make some use of JavaScript. Performances were quite horrendous with Rhino in java 6 and 7, but in Java 8 there is a brand new JavaScript runtime: Nashorn.

Its principal feature is that it's much faster than Rhino. At last, we're going to be able to execute some serious javascript on the server side. Given the richness of the node.js ecosystem, that's a whole new bunch of tools at our disposal. But will they run fast, or fast enough?

First, why not just run those scripts with node?

There are several things in there. When I do Java, I know that what I do is highly portable. Much more so than in any other language, node.js included. So dragging a dependency on node.js annoy me. Also, it's much easier to communicate with nashorn (give it inputs, get outputs back or even callbacks) than with an external process. But most of all, the stability of the whole ecosystem kind of scares me. npm is broken every other day and more often than not, upgrading anything leads to a whole bunch of problems. The simple fact that this whole thing is not even packaged for Ubuntu leaves me wondering.

What did I test?

So, for a practical test, I wanted to minify javascript libs on the fly. So I took a typical Javascript payload from my website and applied UglifyJS to it. The initial payload is the blind concatenation of all the JS files at my disposal in my repo. That's about 62kb of JavaScript. This is real JavaScript used in a real world application, not some dummy routine.

First of all, the compression result. I have a slightly different script to run on node.js and on Java, but they all give an output of 28909 bytes out of 62498. I used the same options for both: do it all, compress as hell.

Notes: I'm running this on an Ubuntu 14.04LTS with a Q6600, an old quad-core from Intel not hyper-threaded. I've tested Java 1.7.0_11, 1.8.0_05 and 1.8.0_45 (with the optimistic type system enabled in nashorn)

The test

The results of the first run (that's after uglifyjs has been loaded):

node.js: 910ms
Java 8u05: 22s
Java 8u45: 28s
Java 7: 19s

So, Java 8 is slower than Java 7. Node crushes them pretty hard - and that's quite an understatement. Note that the newer the version of Java, the worse it is. I surely did not expect that. I don't know much about V8 (node js engine), but I know a few things about Java. HotSpot takes its time to optimize the code it runs. Let's do a for loop with 10 iterations and see how much time it takes at the 10th iteration:

node.js: 600ms - one core used
Java 8u05: 3.6s - three cores used - about 10.8s cpu time
Java 8u45: 3s - three cores used - about 12s cpu time
Java 7: 17s - one core used

Now, this is more interesting. Java 8 is clearly ahead, but still about 6 times slower than node. Java8u45 is a bit ahead on that one. Java7 is still dreadful, but that was expected.

A last note on the cores used. I noticed it during this test because it runs for longer than the first one. Both tests involving Java 7 and node.js take about 100% CPU, which means they use one core (out of my quad core). The test in Java 8 uses about 300% CPU, which means bout three cores. This is also true for the first test of course, but I didn't notice it at first.

Let's do one more test: After 100 compressions, how much time does it take?

node.js: 560ms, one core used
Java 8u05: 1.5s, two cores used so about 3s cpu time
Java 8u45: 2s, three cores used so about 6s cpu time
Java 7: 17s - one core used

Well, this isn't much of a game changer, but it show one thing: Java 8 takes its time to optimize its shit. The Java8u05 process went from 300% to 200% cpu at around iteration 55. Java8u45 went down to 200% CPU at iteration 140, getting the script done in around 1.3s but that was too late for the iteration 100 threshold.

Even after the 10th iteration, it continues to go faster. And after a while, it only takes two cores, not three. This is less bad for Java 8 than the previous one. Now Java is only 2.7 times slower than node and 5.4 times if you count CPU time.

Edit: Let's do one more test: After 1000 compressions, how much time does it take?

node.js: 670ms, one core used
Java 8u05: 1.3s, 1.2 core used
Java 8u45: 1.1s, 1 core used
Java 7: 17s - one core used

Yes, you read that correctly, node.js is going slower after 1000 iterations...

Well, the least one can say it's that Java isn't fast... to become fast. The cpu consumption went from 200% to 120% at around iteration 155. My guess is that the extra cores used were due to the optimizer. It seems to be a heck of a lot of work.

Well, now we can say that Java 8 warmed up is a bit less than 2 times slower than node. But it takes a hell of a lot of time to get there. That said, the result isn't bad at all, given all the resources Google did put in its V8 engine. Java is capable to execute JavaScript at a decent speed.

Wrap up

seconds	Iteration 1	Iteration 10	Iteration 100	Iteration 1000
node.js	0.910	0.6	0.56	0.67
Java 8u05	22	3.6	1.5	1.3
Java 8u45	28	3	2	1.1
Java 7	19	17	17	17

After discarding all results above 5s (so discarding Java7 entirely) and discarding iterations above 200 (they don't seem to change anything but for node who keeps climbing a little to 670ms and then stabilizes), here are the numbers:

I don't know about you, but for my server, I'd rather have a curve that does down than a curve that goes up like node. It would seem as if Java8u45 is longer to warm up but gives better results when warmed up. In the end, Java is 1.6x slower than node, so it can execute its share of JavaScript on the server side. Depending on what you need, it might do the trick. It has to warm up though before being that performant.

The other thing I've learned is that if I want to minify my JavaScript on the fly, I'm going to need some sort of caching mechanism, because none of those run times gives me acceptable performance. This mitigates the 1.6x factor between Java8 and nodejs.

I've also learned that I'll need some sort of warmup at startup, not for my app, but for my JVM. I mean, the first guy getting there will have to wait 22 seconds before getting its JavaScript served? No way, thankyouverymuch.

I've tried a little playing with Java9 but it isn't really mature at this point so I won't disclose anything. Results are on par with Java 8u45. I strongly hope Oracle will pull their shit together and optimize this further.

That is unless they decide to enforce their copyrights on the Java API in which case they'll have to license this JavaScript API from Netscape. It seems only fair. Then again, they'll have to get a license for SQL from IBM, or else they'll go out of business.

Oracle, please spend less in lawyers that undermine your core business and more on engineers which will give a chance to your products. My $.02.

A final note on performance

This warmup that we have seen in the graph is a mix of the JVM warmup and Nashorn engine. But mostly, it is Nashorn. This means that if you create an engine every time you need to execute a script, you won't benefit from it. Here is the most simple way to create an engine:

ScriptEngine engine = factory.getEngineByName("JavaScript");

Well, those pesky ScriptEngine objects created? Never discard them, or else you'll discard the entire optimizations with them.

Google: developers, developers, browsers !

Mon, 24 Jun 2013 12:24:00 GMT

Is it possible that a single company be responsible for both the best browser out there along with the worst one?

As it turns out, yes it is possible, and yes it does exist: Google.

Since the first release of Chrome, it has become my browser of choice: Fast, fast, stable, fast, versatile, and the easiest to debug. I did not think about it for a minute. Plus, as a developer, it is one of the most advanced browsers and allow many cool things. All in all, kuddos for your browser there, good work.

Then came Android, with a default browser also based on WebKit. I - among many - thought that it was a "mobilized" version of Chrome. But no, they did another browser altogether. Fine.

Now, it isn't as fine as we hoped at the time. It seemed obvious - knowing Google - that their browser would kick ass. But no, it doesn't kick ass: it sucks. In fact, among friends we call it "The IE6 of WebKit". "The IE6" refers to the disabled child in the family. There is a surprisingly homogeneity in the WebKit browsers if you exclude Android's default browser. And once every 5 times, you do something that works on iOS, Chrome, Safari... and Android stumbles on it.

Now, it's been several loooong years for web developers, and still there are so many areas that lag behind all other mobile browsers... that I'm starting to lose hope. Really. Despair crawls into me day after day, week after week, month after month.

So Google, pleeeeeeease, just give it the attention it needs, or replace it with Chrome, but pleeeeeeeease, do it fast. Seeing as 1/3 of the traffic from Android comes from version 2.3, we know one thing for sure: even when Google gets its act together on that front, it'll be quite a while for web developers to be able to forget this pain.

Please. Act quickly.

Just released: color-finder

Thu, 20 Jun 2013 16:19:00 GMT

ColorFinder is a small javascript library that detects the main color in an image. The algorithm is simple and flexible. By the way of a callback method, you can influence the results by favoring certain types of colors. You can find it here: https://pieroxy.net/blog/pages/color-finder/index.html You can also have a look at the GitHub repo.

lz-string: We'll try to make it faster

Tue, 21 May 2013 08:19:00 GMT

I've setup a small page where I share my findings in trying to optimize the implementation of lz-string. This work will continue in the coming weeks. You can leave a comment in this blog entry for any feedback.

Just released: lz-string

Thu, 09 May 2013 09:27:00 GMT

lz-string is a compression program for JavaScript in the browser, based on LZW. It is fast, meant for localStorage or any other string-based storage in JavaScript, and is particularly efficient on short strings.

All can be read on the home page: https://pieroxy.net/blog/pages/lz-string/index.html And a demo can be found below for live compression: https://pieroxy.net/blog/pages/lz-string/demo.html

How is my website doing?

Sat, 26 Jan 2013 15:34:00 GMT

How to monitor JavaScript exceptions

It's a question that everyone with a website should have in mind all the time, and often a question that is pretty hard to answer. I mean, how do you know how your website is doing? You can open it up, but that says nothing of what it looks like to your users.

For one, you can look into your server logs. Errors are usually logged in one or more files and this is a good place to start when checking the health of your website. That takes care of the server side of things. What about the front? How can you know if in that particular browser your website is not blowing up in JavaScript errors?

Well, fortunately, you can trap JavaScript errors. All errors on a page. And then, you can call a specific URL on your server in order to log those errors. You may want to log the date, the User-Agent string along with it.

So, how does that work?

Programming in a browser

Tue, 20 Nov 2012 07:30:50 GMT

From a developer's perspective, a web application (called a website back in the days) is made of two parts: The server side code and the client side code.

Writing a program for a web browser is something different than writing for a server. Most of the time, web developers do both as client-side programming is seldom enough to build a UI. Both programming are similar in many ways: You write loops, classes, functions, tests, etc. but they are also very different. This article tries to explain the fundamental differences and what it means for the developer.

Drag and Drop in HTML5

Wed, 07 Nov 2012 13:01:00 GMT

You can find below a link to a very nice article on how to do Drag and Drop on all browsers out there. Very well written and comprehensible. http://weblogs.java.net/blog/manningpubs/archive/2012/10/29/natural-user-interaction-drag-and-drop

WebPlatform.org

Tue, 09 Oct 2012 05:15:00 GMT

the ultimate resource for Web technologies?

It most certainly looks like it's the intent. The major contributors behind the website do add some credibility to the claim: W3C, Google, mozilla, Microsoft, Opera, Apple, Adobe, facebook, HP, NOKIA. Well... that's ... impressive. Go and take a look for yourself.

The goal of this site is to be the place to come for answers to your trickiest (and simplest) development and design questions about the Open Web Platform.

More after the break.