Как стать автором
Обновить
30
0
Сергей Осипчук @osypchuk

Пользователь

Отправить сообщение
airtable достаточно серьезная контора, в США они на слуху:
www.crunchbase.com/organization/airtable#section-overview
Отжимать танкеры в международных водах должно быть недопустимо на международном и государственном уровне.
Иран нарушил этот закон. 3 или 4 раза за последний месяц. Что делать?

Не говоря уже о полуостровах с миллионами жителей.

Ничего лучше чем санкции, который бьют по всем бизнесам и гражданам целиком, пока не придумали.
Предполагаю, там счас очередь этих Appeal Requests сформируется на месяцев 5…
Но в Сирии ими бомбили террористов.

нет.
Карта расположения террористов — Игил на востоке Сирии, что логично, поскольку они пёрли с Ирака cofda.files.wordpress.com/2015/01/syria-territory-map-jan-2015.jpg

РФ же бомбила запад, к примеру Идлиб: www.independent.co.uk/news/world/middle-east/syria-russian-air-strikes-kill-at-least-73-people-in-rebel-held-idlib-a6780741.html

Скорее всего основная цель не столько защита Ассада как создание потока беженцев чтобы Европе и Турции было чем заняться.

Пишут что также в «счастливчиках» Крым, Сирия, Северная Корея и Куба.
Сам гит достаточно децентрализован, по сравнению с другими сервисами, но сколько инструментов построено вокруг него!

Так и есть.
И хотя среднюю скорость загрузки уложить в 2-3 секнуды не так уж сложно, добиться этого от первой загрузки хотя бы для 90% клинетов довольно сложно.
С точки зрения борьбы с монополистами я бы стразу выбросил Google drive (я им еще google reader не простил), OneDrive и Yandex.

С точки зрения NSA и ко — они работают на сетевом уровне — это проще, тем более о дыре в openssl они знали.

Для Dropbox пользователи их системы это все, они будут на них молиться и защищать любой ценой. Запрет на распространение copyright контента — это защита вашего же контента от жалоб правообладателей, потому что закрытый судом dropbox явно не входит в ваши интересы. Судиться и что-то им доказывать, конечно, можно но вам то ваш файл нужен будет сегодня а не через 5 лет, когда закончится судебный процесс.
Интересный ньюанс, Спасибо.
Однако, судя по разделу «О себе» — Microsoft MVP & Microsoft Regional Director — статья должна заканчиваться примерно так:
«Также я создал bug в проекте MVC 5 — обещали исправить»
Если вас не пугает 25% ставка по ипотечным и прочим кредитам, отсутствие дорог и избирательность правосудия — добро пожаловать!
Ваша формулировка вопроса теоретически верна, но она вступает в силу только когда требуется масштабирование и autoscaling
При вычислительной мощности 100+ страниц в секунду и реальной нагрузке 3 страницы в секунду мы наоборот сидим и думаем — чем бы ещё пригрузить сервер, чтобы сделать лишний заказ в день?
Не знаю, как у кого, но я не вижу особого смысла кэшировать страницы кроме главной.
К примеру, вчера сайт отдал 111 тысяч страниц.
Из них — 40845 разных.
Страниц, запрошенных более 100 раз за день всего 36.

С другой стороны, ежедневно меняются цены и наличие для примерно 20000 товаров.

Вот и какой смысл кэшировать?
Наверно, посещаемость будет 10M страниц в день, я буду думать по другому, но сколько таких eCommerce проектов в мире — 200?
1. Данные выглядят субъективными:
У меня boutique ~1с, sotmarket.ru — 1.5с, что не соотвтествует данным результам.

На самом деле писать такие тесты можно только для себя. Чтобы увидеть реальную картину лучше использовать данные от реальных пользователей. К сожалению, google analytics не раскрывает таких данных о чужих сайтах, но есть и другие варианты.
К примеру, Alexa.com — плагин, который стоит у многих пользователей и репортит время загрузки. По её данным, у пользователей sotmarket.ru открывается в среднем за 1.163 с, boutique.ru — 1.634 Seconds, что вполне неплохо. А вот Komus.ru, занявший 3е место — 1.238 Seconds?

2. Мы для abo.ua добились отдачи страниц с скоростью порядка 100mbps (1 сервер), что в десятки раз превышает текущие потребности. По мнению алексы, пользователи получают страницу в течении 0.565 Seconds.

Если вы хотите сделать быстрый магазин — актуальнее тестировать не закэшированную домашнюю страницу, либо простую страницу товара, а рандомную выборку товаров, которая бы показала силу «движка». К примеру, телевизоры с ценой до random().
И тогда результаты будут совсем другими. Чтобы это тестировать мы делаем специальную «рандомную» страницу, которая каждый раз ищет разные данные и тестируем на скорость.

И я не сказал бы, что добиться высокой скорости работы сложно, особенно, что касается времени загрузки в браузере. Достаточно воспользоваться google pagespeed insights.
Если вдруг кому интересно как мы оптимизировали serverside — основные советы собраны в этой презентации socialtalents.com/page/100mbps (правда, на английском)

Ну и вообще, нужно оценивать степень параллелизма — каким образом меняется скорость работы с увеличением количества клиентов. К примеру, у нас начинаеся снижение производительности после 80 параллельных юзеров в секунду, и это уже проблема, которая заставляет задуматься…
Много интересных фактов. Выводы, как по мне, слишком стратегически, но в любом случае спасибо.
Мне почему-то кажется, вам может быть интересно почитать историю flickr:
gizmodo.com/5910223/how-yahoo-killed-flickr-and-lost-the-internet
Математика, конечно же, представляет собой ценность, но предположение о равномерной загрузке на протяжении трех (!) лет само по себе сомнительно.
В моем опыте:
1) меняется ТЗ
2) улучшается алгоритм (за год мы улучшили время работы в одном проекте раза в 4е, в другом — раз в двадцать). Т.е. одна и та же мощность может обслуживать всё большее количество клиентов
3) меняется схема развертывания — проект/его части переписывается на другие технологии, которые могут менять желаемую конфигурацию, выделяются компоненты, и их тоже удобно размещать на отдельных серверах.
4) А вот объем информации и трафик растёт постоянно. И это тут не учитывается.

Возможно, вы там кодируете видео, либо занимаетесь каким-то другими задачми, где алгоритмы особо не меняются, но это скорее исключения.

Если год назад 1.5 терабайт трафика (обычный + cloudfront) влетел нам в usd250, то с сегодняшней посещаемостью это была бы примерно тысяча долларов в месяц, и превысило бы затраты на вычислительную мощность раза в два.

Как следствие, оказалось выгоднее перенести проект на банальный dedicated server, с тарификацией порядка $10/TB вместо $150 у амазона. Скорость выросла в 3 раза. затраты снизились в 4 раза.

Для надёжности информация реплицируется в amazon, в котором есть snapshot приложения, которое можно стартонуть (15 минут), пользователи получат доступ к проекту в течении обновления dns (ttl у нас 15 минут). Да, не так красиво, но реальная экономия более 10 тысяч долларов в год.
тут пишут что 7.7 кг:
www.trustedreviews.com/news/lenovo-ideacentre-horizon-table-pc-launched

Думаю, за год еще клиограмм-другой скинет. Ну и может подешевеет.
Так это ж mysql, статья то про монго, которую, как минимум, легко раскидать по разным серверам.

В монго у вас будет другая база, другие запросы и другие индексы.
Вообще, когда индексов больше данных, это как-то нездорово.
Тогда вам один путь — искать возможность уменьшить объем данных. Когда проект станет зарабатывать данных, скорее всего, станет еще больше.

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

Ну и на всякий случай
— убедиться, что количество запросов при каждой загрузке страницы o(1)
— Можно посмотреть, здесь описываются детальная оптимизация запросов: derickrethans.nl/indexing-free-tags.html

ссылка классная, так тоже можно работать.
Задумывался, но для нас вопрос транзакций вообще не актуально.

Функция это хорошо, но ведь админ по ошибке может вырубить свет как раз в момент ее выполнения. Я бы скорее завел таблицу операций, писал бы туда всю необходимую информацию в одну запись.
Асинхронный процесс выгребает операции и обновляет связанные объекты — habrahabr.ru/post/149047/#comment_5040625

Информация

В рейтинге
Не участвует
Откуда
Киев, Киевская обл., Украина
Дата рождения
Зарегистрирован
Активность