• DOU лучше оптимизирован чем Хабрахабр

    Кстати, Pagespeed показывает рейтинг по мобильной оптимизации: 75 для DOU и 57 для Хабра :) Конечно, речь не о победах, но это важные показатели, Интернет ускоряется.

  • как настроить кеширование картинок с амазона и их отдачу как своих?

    Кстати, вот полезные инструменты для оптимизации картинок. В случае использования амазона — экономия места будет важна.

  • MySQL vs MongoDB

    Если для масштабирования — лучше посмотрите на техники шардинга и репликации.

  • Highload — это сколько?

    Хайлоад — это относительное состояние, когда наступает время масштабироваться. Советую почитать Что такое хайлоад

  • Менеджмент highload проектов

    Не хватает конкретики в каждом примере: рефакторинг — это хорошо, команда — это очень важно и т.п. Неправда ли, общие фразы? Есть такой прекрасный сайт http://highscalability.com/, где постоянно разбираются кейсы конкретных систем. Хотелось бы прочитать о чем-то подобном (только на личном опыте или опыте каких-то наших команд, а не в переводе).

    Спасибо! Если Вас интересует техническая составляющая, рекомендую блог: http://highload.com.ua. А в этой статье я попытался выделить самые важные компоненты в работе. Понимание того, что важно, а что нет — это уже 50% успеха. Дальше планирую писать о более специфических вопросах.

  • Менеджмент highload проектов

    Какой именно вид рефакторинга вас в таком проекте напрягает больше всего?

    Меня не напрягает рефакторинг, совсем наоборот. Я попытался донести правильную практику его проведения — понемногу и постоянно, а не все сразу.

  • Менеджмент highload проектов

    Владимир, спасибо!

    Робота на великому по трафіку проекті (кілька терабайт трафіку в день), це — активний пошук можливих проблем (напр. закритий тікет має містити розділ “можливі проблеми” та пропозиції по їх упередженню чи вирішенню); планування — планування змін, тестування, релізів, навантаження, перездів, замін, і т.д.; фільтрація змін — dev -> testing -> staging -> production; версіонування — поки нова функціональність розробляється і тестується, стара версія того самого коду підтримується паралельно поки не буде оголошена застарілою.

    У Вас был опыт работы в подобных проектах? Если да, то думаю Вы понимаете, что большинство проблем с нагрузками практически невозможно прогнозировать (т.е. не возможно написать, вот в этой функции возможна такая проблема). И это связано не столько с функционалом, сколько с распределением нагрузки на практике.

    Дитячий садок. Рефакторинг — це зміна коду без зміни функціональності. Якщо в результаті рефакторингу у вас щось у функціональності міняється, то комусь треба за це відірвати яйця. Ви напевно мали на увазі оптимізацію коду?

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

    Якщо тести показують, що через місяць датацентр А не справлятиметься з піковими навантаженнями, що приведе до збільшення часу обробки запитів, то необхідно провести аналіз варіантів вирішення проблеми — збільшення кількості серверів, оптимальніше використання вільних ресурсів (напр. використання європейського датацентру для обробки частини американського трафіку поки не будуть введені в стрій нові потужності). Код пишеться і відлагоджується довго — навіть тривіальна зміна може пройти весь цикл за 1−2 місяці, і немає ніякої гарантії що вдасться викинути частину коду, тому ставити в залежність роботу датацентру від можливого успіху програмістів ніяк не можна.

    Не совсем понимаю какое отношение имеет датацентр к вопросу “справляется с нагрузками” — с нагрузками справляется система. Если датацентр не обеспечивает нужную пропускную способность, то в этом виноват уж никак не датацентр, а тот, кто его выбирал. Вы все правильно написали, но люди, которые принимают эти решения — это не саппорт датацентра, а Ваша команда.

  • Менеджмент highload проектов

    Владимир, спасибо... Учтем Ваши суровые замечания, только менеджера учить «что делать с кодом» мы не будем:)