Replay2024 conference held in Seattle on September 19th and 20th, 2024.
| 0-mail.com | |
| 007addict.com | |
| 020.co.uk | |
| 027168.com | |
| 0815.ru | |
| 0815.su | |
| 0clickemail.com | |
| 0sg.net | |
| 0wnd.net | |
| 0wnd.org |
This sets up a publically-available domain that loops back to localhost IP address 127.0.0.1. For example, this address could be localhost.example.com if we controlled the example.com domain. This relies on having a public domain name whose DNS records you can control. We can then generate LetsEncrypt certificates for this domain.
Our HTTP server runs on localhost:80 (default HTTP port). This lets us visit http://localhost.example.com in a web browser and see the server running on localhost:80.
We then run an HTTPS proxy server on localhost:443 (default HTTPS port) that uses the LetsEncrypt certificates we generated for localhost.example.com. Visiting https://localhost.example.com hits the proxy, which returns the correct certificates meaning the browser displays the "Secure" message. The proxy then passes the request through to the HTTP server.
Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.
This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would
RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.
On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.
So, many developers have started going straight t
- Code for generating the user_hash value for Intercom's Identity verfication (Note: Identity verification was prevoiusly called Secure Mode)
- Based on http://www.jokecamp.com/blog/examples-of-creating-base64-hashes-using-hmac-sha256-in-different-languages/#ruby
- When creating this for mobile, the final output needs to be in lowercase (the web version accepts both upper and lower case)
- So Javascript code below should only be used for testing unless modified and used to run on a server
Moved to git repository: https://github.com/denji/nginx-tuning
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.
| global | |
| #debug | |
| #daemon | |
| log 127.0.0.1 local0 | |
| defaults | |
| log global | |
| option httplog | |
| frontend unsecured *:80 |