Skip to content
This repository has been archived by the owner on Nov 28, 2020. It is now read-only.

Add Ghost.js workload to the benchmarking #159

Closed
uttampawar opened this issue Oct 10, 2017 · 10 comments
Closed

Add Ghost.js workload to the benchmarking #159

uttampawar opened this issue Oct 10, 2017 · 10 comments
Assignees

Comments

@uttampawar
Copy link
Contributor

I'm opening this issue based on the discussion in "benchmarking WG" at the Node.js interactive conference to track progress of addition of Ghost.js workload. This application is on github.com at,
https://github.com/TryGhost/Ghost

@mhdawson
Copy link
Member

+1, its been in our list of suggested workloads so if you have time to generate the scripts that would be great.

@sathvikl
Copy link
Contributor

@uttampawar @gareth-ellis @mhdawson @bmeurer @kunalspathak
I would like your opinion on what version of this benchamark needs to be merged into the Jenkins system.

I have been using this version of https://github.com/sathvikl/ghostjs-benchmark , internally to benchmark a server system, compare compatible versions of node and to do perf-analysis.
(For instance to test this Issue #nodejs/node#16131)

Ghost.js version 0.11 is compatible only with Node v6 and earlier. (as recommended by Ghost.js team)

The changes required to run it with node 8 are here #TryGhost/Ghost#8770 but unless it's declared LTS, Ghost.js team will not support it.

I am proposing that

  • We create and maintain a stable github repo that will serve as a benchmark for ghost.js, currently hosted at https://github.com/sathvikl/ghostjs-benchmark
    rather than creating a benchmark on the fly, on the jenkins machine, using various scripts.
    This will also serve to be a go-to link for anyone interested in using this benchmark on their machine.

  • In order to test the performance of the latest versions of node, and the master branch, this benchmark repo will stay compatible with the latest.
    So I will hack through the code/package.js of a specific Ghost.js version to achieve this.

A little about the Ghost.js versions available out there..

  • The current version of the benchmark is based from Ghost.js release 0.11.7 and v0.11's LTS support was dropped on March 20 2017, https://dev.ghost.org/lts/
    Ghost 1.0 was released on July 2017 and the most recent stable release version is 1.16

I think I should first migrate/re-create the benchmark, using Ghost v1.16 and then add it to my repo.
rather than using a version whose LTS support has been dropped.

  • Once the Ghost.js benchmark repo is updated, I will add scripts to the Jenkins machine to pull the repo code, benchmark the version of node and report the results.

@mhdawson
Copy link
Member

mhdawson commented Nov 2, 2017

What licence is the ghostjs-benchmark ? If the licence is compatible I'd prefer if the stable version of the benchmark was in a directory in the benchmarking repo.

@sathvikl
Copy link
Contributor

sathvikl commented Nov 2, 2017

@mhdawson it's released under the MIT license.

I created a repo of its own, because none of the other benchmarks are hosted in this benchmarking repo itself, although I would prefer that instead of having it in my account.

@mhdawson
Copy link
Member

mhdawson commented Nov 3, 2017

I think some of the smaller ones are. If we are going to have it in a repo which is not the original, I'd prefer it to be in a repo under the foundation org.

@sathvikl
Copy link
Contributor

We can move the repo to the foundation org. I'm not sure which one it is or the process to do so.

I have created an issue for regarding Ghost 1.0 TryGhost/Ghost#9231
So let's use 0.11 version of Ghost and have it integrated into the Jenkins system.

@uttampawar
Copy link
Contributor Author

@mhdawson Sathvik has prepared ghost.js v0.11 (older version) and ghost.js v1.17 (latest stable LTS) to be submitted to benchmarking. My question is do we really care about older version of this application? They do not have LTS support for v0.11 anymore. My suggestion is to use the latest version only. Please share your thoughts so that we can submit PR. Thanks.

@mhdawson
Copy link
Member

@uttampawar is going to take this over. Most of the code is ready but @sathvikl is changing roles so he won't have time to work on it.

@raoulmillais
Copy link

I watched the WG meeting and heard you debating locking down the jenkins user to only be able to start one service. You can specify the specific full commands in the sudoers file. E.g.

<username> <hostname>=/usr/sbin/service docker start,/usr/sbin/service docker stop

@mhdawson
Copy link
Member

mhdawson commented Mar 5, 2019

Discussed in the team meeting this week. Uttam has commented he does not think it is the best one to pursue and it does not run with master branch or canary. For that reason closing for now.

@mhdawson mhdawson closed this as completed Mar 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants