denji

Moved to git repository: https://github.com/denji/nginx-tuning

NGINX Tuning For Best Performance

For this configuration you can use web server you like, i decided, because i work mostly with it to use nginx.

Generally, properly configured nginx can handle up to 400K to 500K requests per second (clustered), most what i saw is 50K to 80K (non-clustered) requests per second and 30% CPU load, course, this was 2 x Intel Xeon with HyperThreading enabled, but it can work without problem on slower machines.

You must understand that this config is used in testing environment and not in production so you will need to find a way to implement most of those features best possible for your servers.

haykuro

http://ctf.infosecinstitute.com/

## Level 1:

View the source, at the top we see:

<!-- infosec_flagis_welcome -->

Level 1 PASS: infosec_flagis_welcome

chjj

'use strict';

// original: https://gist.github.com/indutny/8d0f5376ee643962a9f0

const BN = require('bn.js');
const elliptic = require('elliptic');
const bcoin = require('bcoin');

const ecdsa = new elliptic.ec('secp256k1');

xjdrew

package main

import (
	"crypto/tls"
	"crypto/x509"
	"flag"
	"io"
	"io/ioutil"
	"log"
	"os"

miguelmota

# Generate the private and public keys
openssl ecparam -name secp256k1 -genkey -noout | openssl ec -text -noout > key

# Extract the public key and remove the EC prefix 0x04
cat key | grep pub -A 5 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^04//' > pub

# Extract the private key and remove the leading zero byte
cat key | grep priv -A 3 | tail -n +2 | tr -d '\n[:space:]:' | sed 's/^00//' > priv

# Generate the hash and take the address part

sapran

# All scripts
```
--tamper=apostrophemask,apostrophenullencode,appendnullbyte,base64encode,between,bluecoat,chardoubleencode,charencode,charunicodeencode,concat2concatws,equaltolike,greatest,halfversionedmorekeywords,ifnull2ifisnull,modsecurityversioned,modsecurityzeroversioned,multiplespaces,nonrecursivereplacement,percentage,randomcase,randomcomments,securesphere,space2comment,space2dash,space2hash,space2morehash,space2mssqlblank,space2mssqlhash,space2mysqlblank,space2mysqldash,space2plus,space2randomblank,sp_password,unionalltounion,unmagicquotes,versionedkeywords,versionedmorekeywords
```
# General scripts
```
--tamper=apostrophemask,apostrophenullencode,base64encode,between,chardoubleencode,charencode,charunicodeencode,equaltolike,greatest,ifnull2ifisnull,multiplespaces,nonrecursivereplacement,percentage,randomcase,securesphere,space2comment,space2plus,space2randomblank,unionalltounion,unmagicquotes
```
# Microsoft access
```

goodwill

[Install]
WantedBy=multi-user.target

[Unit]
Description=Google Cloud Compute Engine SQL Proxy
Requires=networking.service
After=networking.service

[Service]
Type=simple

chrisdlangton

import hashlib
import hmac
from base64 import b64encode
from functools import wraps
from datetime import datetime, timedelta
from flask import request, abort
from flask_login import login_user
from models import User, ApiKey

def require_hmac(not_before_seconds: int = 3, expire_after_seconds: int = 3):

yorickdowne

Overview

I was looking after a Dell PowerEdge R420 server with a hardware RAID card in it, a PERC8 H710P Mini. Connected to this were two WD Blue 3D NAND SATA SSDs in RAID-1, that were handling a write-intensive database: Geth, in this case.

After 11 months of running without problems, I had reason to "resync" Geth, and the server could not keep up with the required IOPS. Symptoms were Database compacting, degraded performance messages for hours, without recovery, and read/write latency in excess of 20/70ms, as measured by sudo iostat -mdx and its r_await and w_await data.

The cause of this was that the RAID controller does not support TRIM on the SSD, and the SSD's performance degraded over time because of it.

yorickdowne

Overview

Syncing an Ethereum node is largely reliant on IOPS, I/O Per Second. Budget SSDs will struggle to an extent, and some won't be able to sync at all.

This document aims to snapshot some known good and known bad models.

For size, 4TB comes recommended as of mid 2024. The smaller 2TB drive should last an Ethereum full node until early 2025 or thereabouts, with crystal ball uncertainty. Remy wrote a migration guide to 4TB.

High-level, QLC and DRAMless are far slower than "mainstream" SSDs. QLC has lower endurance as well. Any savings will be gone when the drive fails early and needs to be replaced.