May 9th, 2016

Book

Redundant Array of Inexpensive VPSes

Так у нас выглядит "мягкий" отказ:

Due to lack of resources and the departure of administrative staff, I can no longer maintain the services offered by our company. In order to ensure all users have ample time to migrate their services I will be keeping equipment active and online until June 30th, 2016. After that date all VPS instances will be shut down permanently and data will be destroyed without warning. As a part of our apology for cancellation of your service, outstanding invoices dated May or June can be ignored, your instance(s) will stay online until the termination date. Please ensure your data is migrated before then.

Any customer with a renewal period ending past that date may be eligible for a partial refund, depending on type of service. If you have any other questions please contact the helpdesk

"Жёсткий" отказ выглядит как выдёргивание сервера из розетки и увоз в неизвестном направлении.
Book

Task queue курильщика

Когда-то давно я, видя насколько ужасным по производительности бывает код, предлагал конкурс, в котором задачу нужно решить как можно медленнее, и определить с помощью жюри самый остроумный вариант. То есть, не вставлять явные замедления, а максимально правдоподобно написать код, который пройдёт ревью типичным курильщиком, однако будет крайне медленным по сравнению с правильным решением. Эдакая диверсия, месть увольняющегося здорового человека.

Сейчас я нашёл подходящий для этого строительный блок.

С его помощью задача 10к раз применить toUppercase() к строке "abc" занимает 700 секунд! Т.е. 70мс на каждый вызов.

Сделано вставкой в плёвую задачу кода индирекшона, который по всем понятиям (что курильщика, что здорового человека) должен занимать заведомо меньше 70мс.

Эти "abc" ставятся в task queue, и задействованы 3 процесса, соединенные через локалхост: клиент, сервер очереди сообщений типа request/response, и воркер.

Я так понимаю, внутри очереди есть какие-то квадратичные алгоритмы, не рассчитанные на 10к сообщений в очереди, причём, скорее всего во всех 3-х компонентах. Достоверно известно, что там точно всё написано по принципу наивного неконкурентного программирования - т.е. двойных буферизаций, учета bandwidth*latency и прочих трюков нет.

Интересно, где зарыта собака окажется.

Upd: сделал бенчмарк, с квартилями, нормализацией, усатыми графиками и шлюхами. Выяснилось, что исправление, которое умозрительно не может замедлять код, его таки замедляет, причём аж на 8%. Но замедляет только говнореализацию сервера на локалхосте. Нормальную реализацию которая на С++ - не замедляет, как и подсказывает нам голова. А сишную нормальную реализацию по WAN даже ускоряет, собственно ради WAN всё затевалось. Говнореализацию по WAN не тестил, но там думаю ускорение в 270% победит замедление в 8%.