Как вы думаете, эквиваленты ли по производительности эти два варианта проверки условий внутри цикла?

		
if a > b && c*2 > d {
	....
}
// и
if a <= b  { 
  continue;
}
if c*2 > d {
 ....
}

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



Автор материала, перевод которого мы публикуем, решил добраться до сути средств выделения памяти в Go и рассказать об этом.

На прошлой неделе компания ARM Holdings объявила, что разрабатывает новую микро-архитектуру для серверных процессоров. Вычислительное ядро, которое будет в ней использоваться, носит кодовое имя Ares, и по обещаниям должно дать 60% прирост по сравнению с текущей платформой. С каждым следующим поколением производительность должна расти еще на 30%.

Серверный рынок — пока не самый большой для ARM. Сейчас процессоры на ее архитектуре используются в мобильных и встраиваемых устройствах. Скачок производительности, который компания обещает производителям серверов, будет выше чем Intel и IBM проделали за последние несколько лет.

Тем не менее, создатель Linux Линус Торвальдс скептично прокомментировал анонс. Он считает, что будущее новой архитектуры не так радужно.

В течение последних 7 лет я вместе с командой занимаюсь поддержкой и развитием ядра продукта Miro (экс-RealtimeBoard): клиент-серверным и кластерным взаимодействием, работой с базой данных.

У нас Java с разными библиотеками на борту. Запускается всё вне контейнера, через Maven-плагин. В основе — платформа наших партнёров, которая позволяет работать с базой данных и потоками, управлять клиент-серверным взаимодействием и т.д. БД — Redis и PostgreSQL (мой коллега написал о том, как мы переезжаем с одной БД на другую).

С точки зрения бизнес-логики приложение содержит:

• работу с пользовательскими досками и их контентом;
• функционал по регистрации пользователя, созданию и управлению досками;
• генератор пользовательских ресурсов. Он, например, оптимизирует загруженные в приложение большие изображения, чтобы они не тормозили на наших клиентах;
• множество интеграций со сторонними сервисами.

В 2011 году, когда мы только начинали, весь Miro находился на одном сервере. На нём было всё: Nginx, на котором крутился php для сайта, Java-приложение и базы данных.

Продукт развивался, росло количество пользователей и контента, который они добавляли на доски, поэтому нагрузка на сервер тоже росла. Из-за большого количества приложений на нашем сервере мы в тот момент не могли понять, что именно даёт нагрузку и, соответственно, не могли это оптимизировать.Чтобы это исправить, мы разнесли всё на разные сервера, и у нас появились веб-сервер, сервер с нашим приложением и сервер с базами данных.

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



Дальше расскажу о сложностях, с которыми мы столкнулись при развитии кластеров и масштабировании Java-приложения и инфраструктуры.

Иногда нужно быстро распечатать много картинок с котиками документов, а открывать для этого каждый файл совсем не хочется. Первым делом напрашивается использование контекстного меню проводника, но у этого способа есть свои ограничения и нюансы. Поэтому пришлось искать альтернативу. За подробностями — прошу под кат.

Когда мы запустили в 2013 году Discourse, наши требования к серверу были высокими:

• 1 ГБ ОЗУ
• быстрый двухядерный ЦП
• быстрый твердотельный накопитель от 20 ГБ

Я имею в виду не дешёвый общий cpanel-сервер, а выделенный виртуальный частный сервер с такими характеристиками.

Нам этого было достаточно, потому что в течение следующего десятилетия Интернета мы писали на Ruby. Я сразу предсказывал, что цена аренды VPS с такими характеристиками упадёт до 5 долларов в месяц, и благодаря Digital Ocean это действительно случилось в январе 2018 года.

Облако стало дешевле и быстрее. И это не очень удивляет, ведь со временем цена железа снижается до нуля. Но это всё-таки облако, то есть оно не совсем дёшево. В конце концов, это чей-то компьютер, за привилегию аренды которого вы платите.


Но постойте… а что если вы сможете засунуть «в облако» свой компьютер?

Приветствую, друзья!

В предыдущих двух статьях (раз, два) мы погружались в сложность выбора между технологиями и искали оптимальные настройки для нашего решения в Ostrovok.ru. Какую тему поднимем сегодня?

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

Примечание переводчика

Большинство современных программных продуктов не являются монолитными, а состоят из множества частей, которые взаимодействуют друг с другом. При таком положении дел необходимо, чтобы общение взаимодействующих частей системы происходило на одном языке (притом что сами эти части могут быть написаны на разных языках программирования и выполняться на разных машинах). Упростить решение этой задачи помогает gRPC — open-source-фреймворк от Google, выпущенный в 2015 году. Он решает сразу ряд проблем, позволяя:

• использовать язык Protocol Buffers для описания взаимодействия сервисов;
  
• генерировать программный код на основании описанного протокола для 11 разных языков как для клиентской части, так и для серверной;
  
• реализовать авторизацию между взаимодействующими компонентами;
  
• использовать как синхронное, так и асинхронное взаимодействие.
  

gRPC показался мне довольно интересным фреймворком, и мне было интересно узнать про реальный опыт компании Dropbox по построению системы на его основе. В статье есть масса деталей, связанных с использованием шифрования, построением надёжной, наблюдаемой и производительной системы, процессом миграции со старого RPC-решения на новое.

Для корпоративных учетных систем характерно постепенное увеличение объёма баз данных из-за накопления исторической информации. С течением времени размер БД может достигать таких размеров, что это провоцирует ряд проблем с производительностью, сервисным обслуживанием, доступным дисковым пространством и прочее. Сегодня рассмотрим два подхода к решению этой проблемы: наращивание аппаратных ресурсов и свёртка исторических данных.