Comments 27
Каким образом изменение хостинга привело к увеличению количества одновременных пользователей на сайте?
У меня только одна версия: прошлый хостинг был настолько плох, что его Гугл понизил в выдаче.
У меня только одна версия: прошлый хостинг был настолько плох, что его Гугл понизил в выдаче.
Время ответа увеличилось -> Гугл поднял в выдаче.
Спасибо за вопрос. Эта фраза была про нагрузку. Проблема первоначальная была в том, что при определенном количестве пользователей показатели CPU и RAM сервера поднимались до 100% и в работе сайта происходил сбой. Решение описано в ответах на другие комментарии и тексте. Но если про пользователей. Для тестирования нагрузки использовалась программа Apache Jmeter. Тестирование проводилось с разным количеством юзеров (Threads) примерно от 10 до 1000. Под них, соответственно до поставленных задач, настраивалась (Ramp-Up Period) от 10 к 1000 секундам, чтобы обеспечить тест на уровне “1 пользователь в 1 секунду”, иногда для больших нагрузок использовали меньше времени, и количество циклов Loop Count.
Блин, вот AWS по стоимости хостинга нифига не дешёвый, сервисы тоже у них настроены не на производительность, а на стабильность.
Это судя по всему раньше был просто ужасный дорого хостинг.
Или ключевое «Потом занимались настройкой сервисов. Это заняло около недели»
Если бы настроили нормально сервисы на старой платфформе — думаю, что производительность тоже выросла бы
Это судя по всему раньше был просто ужасный дорого хостинг.
Или ключевое «Потом занимались настройкой сервисов. Это заняло около недели»
Если бы настроили нормально сервисы на старой платфформе — думаю, что производительность тоже выросла бы
Нам и стабильность была нужна. Сначала анализировались AWS, Vultr, goDaddy, Linode и другие. Наш выбор пал как раз на AWS, и мы делимся своим опытом. Наш предыдущий провайдер, как и другие облачные хостеры, не дает возможности реализации сложного проекта ввиду отсутствия сервисов или их аналогов таких как AWS RDS, ELB, ASG. Покупка и реализация таких возможностей на «своём железе» заняла бы огромное количество человеко-часов и требовала бы постоянной поддержки, чего не требуется в случае с AWS. Поэтому изначально просто перевели сайт на AWS, без каких-либо сервисов.
Больше тегов.
AWS не панацея, особенно в России. К примеру ресурс unsplash использует AWS.
С недавнего времени третий сегмент AWS стал недоступен у большинства провайдеров. Т.к. на одном из ресурсов, AWS содержал запрещенный в РФ материал. Соответсвено под раздачу попало множество ресурсов, которые использовали данный AWS.
AWS не панацея, особенно в России. К примеру ресурс unsplash использует AWS.
С недавнего времени третий сегмент AWS стал недоступен у большинства провайдеров. Т.к. на одном из ресурсов, AWS содержал запрещенный в РФ материал. Соответсвено под раздачу попало множество ресурсов, которые использовали данный AWS.
Мы согласны, что в целом можно использовать другие хостинги, но мы выбрали AWS для управленческого звена конфигурации проекта и в целом делимся своим опытом и хотим показать, что существует возможность использования данных сервисов для решения подобных проблем. Проект международный и хостинги изначально рассматривались в Европе.
Что это за мусор я только-что пролистал?
Интересно ROI люди считают. Делят флопсы на деньги, впаяв бизнесу двойные прямые расходы и замену хостера. Современные economics, success story и cloud :)
У нас ресурс рассчитывает ROI, учитывая параметры пользователя ИТ-продуктов и характеристики продукта. Можете попробовать на примере популярного продукта Microsoft Office 365
Так рассчитывался ROI и этого внедрения.
Так рассчитывался ROI и этого внедрения.
Имел бы право — заминусовал бы статью… Кроме сухого текста, в которой ни грама инфографики, больше ничего нет…
Такое ощущение, что статья не для жителей хабра, а для заказчика из мухосранска…
Такое ощущение, что статья не для жителей хабра, а для заказчика из мухосранска…
В плане производительности основное техническое решение было, как я понял, дать больше ресурсов? У старого хостера уперлись в потолок вертикального масштабирования, который у него был ниже? Или основным стало создание кеша для тяжёлых запросов? Или сделали горизонтальное масштабирование?
В потолок мы не уперлись. Нам просто необходимо было кеш, базу вынести с локального инстанса и настроить лоад балансер, на котором мы держим наш SSL сертификат, соответственно это все дает выигрыш по перфоменсу и масштабируемости.
Ну 100% загрузки процессора — это потолок, хотя бы в рамках текущего тарифного плана хостера.
Ну, тогда именно AWS и даже облака в целом, особого прироста производительности не дали. Разделяемый кэш на отдельной ноде или даже кластере, разделяемая база на отдельной ноде или кластере, кластер апп-серверов (желательно stateless или soft state) с балансировщиком — стандартные пути горизонтального масштабирования, хоть в облаке, хоть на базе своего парка железных серверов.
Тем не более, несмотря на крайне паршивый контент и кучу негативных отзывов — 1.7 к просмотров.
Не хабровский какой-то пост получился. Никакой конкретики.
Какие сервисы крутятся на серверах (почта, базы данных, Java, PHP, nodeJS, это вообще Web или кокой-то REST)?
Сколько и каких серверов использовалось до и после?
В каких попугаях мерили нагрузку до и после? CPU — весьма неоднозначный показатель особенно если было 100%?
Почему если бюджет вырос вдвое нельзя было добавить пару серверов в изначальную конфигурацию?
Какая она была изначально? Другой не облачный хостер? Или серверная комната? Канал в сеть какой был?
Почти ни один технический аспект не освещен, не удивительно, что народ минусует.
Даже если поменять заголовок на: «Как мы переехали на AWS» и то ничего не понятно. Что уж говорить про «улучшить производительность сайта в 8 раз»
Какие сервисы крутятся на серверах (почта, базы данных, Java, PHP, nodeJS, это вообще Web или кокой-то REST)?
Сколько и каких серверов использовалось до и после?
В каких попугаях мерили нагрузку до и после? CPU — весьма неоднозначный показатель особенно если было 100%?
Почему если бюджет вырос вдвое нельзя было добавить пару серверов в изначальную конфигурацию?
Какая она была изначально? Другой не облачный хостер? Или серверная комната? Канал в сеть какой был?
Почти ни один технический аспект не освещен, не удивительно, что народ минусует.
Даже если поменять заголовок на: «Как мы переехали на AWS» и то ничего не понятно. Что уж говорить про «улучшить производительность сайта в 8 раз»
Да, вы правы, этот пост больше про организации и настройки сервисов на AWS для нормальной работы веб-сайта.
Если углубиться в конкретику, то изначально сайт был на VPS от другого провайдера (не будем называть с кого переходили, чтобы не создавать антирекламу) и имел такую конфигурацию: 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth. Наш предыдущий провайдер, как и другие облачные хостеры, не дает возможности реализации сложного проекта ввиду отсутствия сервисов или их аналогов таких как AWS RDS, ELB, ASG. Покупка и реализация таких возможностей на «своём железе» заняла бы огромное количество человеко-часов и требовала бы постоянной поддержки, чего не требуется в случае с AWS. Поэтому изначально просто перевели сайт на AWS, без каких-либо сервисов. Вариант реализации этой серверной архитектуры изображён на рис.
Но в силу масштабирования проекта и увеличения функционала было принято решение во избежание рисков перейти на более надежный хостинг, который легко позволяет настраивать нужные сервисы и легок в администрировании. Тем более в современном мире, где любой «дурак» может без особых усилий устроить тебе DDos-атаку при помощи разных веб-инструментов. Поэтому выбрали AWS, где на серверах крутится PHP, почтовик, nodeJS и REST.
Для тестирования нагрузки использовалась программа Apache Jmeter. Тестирование проводилось с разным количеством юзеров (Threads) примерно от 10 до 1000. Под них, соответственно до поставленных задач, настраивалась (Ramp-Up Period) от 10 к 1000 секундам, чтобы обеспечить тест на уровне “1 пользователь в 1 секунду”, иногда для больших нагрузок использовали меньше времени, и количество циклов Loop Count.
По результатам тестирования был проделан ряд работ, как по оптимизации проекта, так и по конфигурации серверов. А именно: разделение сложного функционала на разные микро сервисы, каждый из которых находится в своем AWS-контейнере, настроено auto scaling group, DB read replics, Elastic Cashe, медиа-контент был вынесен на S3.
Из сложного функционала у нас калькуляторы. ROI-калькулятор и калькулятор цены ИТ-продуктов. Примеры можно посмотреть по ссылкам, чтобы было нагляднее (на ссылках даны примеры расчета цены и ROI конкретных продуктов, а такие расчеты возможны абсолютно для всех без исключения решений и продуктов, даже самых сложных). Именно такие расчеты при одновременном использовании определенном количеством пользователей ранее тормозили работу сервиса.
Обновленный вариант архитектуры
Если углубиться в конкретику, то изначально сайт был на VPS от другого провайдера (не будем называть с кого переходили, чтобы не создавать антирекламу) и имел такую конфигурацию: 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth. Наш предыдущий провайдер, как и другие облачные хостеры, не дает возможности реализации сложного проекта ввиду отсутствия сервисов или их аналогов таких как AWS RDS, ELB, ASG. Покупка и реализация таких возможностей на «своём железе» заняла бы огромное количество человеко-часов и требовала бы постоянной поддержки, чего не требуется в случае с AWS. Поэтому изначально просто перевели сайт на AWS, без каких-либо сервисов. Вариант реализации этой серверной архитектуры изображён на рис.
Но в силу масштабирования проекта и увеличения функционала было принято решение во избежание рисков перейти на более надежный хостинг, который легко позволяет настраивать нужные сервисы и легок в администрировании. Тем более в современном мире, где любой «дурак» может без особых усилий устроить тебе DDos-атаку при помощи разных веб-инструментов. Поэтому выбрали AWS, где на серверах крутится PHP, почтовик, nodeJS и REST.
Для тестирования нагрузки использовалась программа Apache Jmeter. Тестирование проводилось с разным количеством юзеров (Threads) примерно от 10 до 1000. Под них, соответственно до поставленных задач, настраивалась (Ramp-Up Period) от 10 к 1000 секундам, чтобы обеспечить тест на уровне “1 пользователь в 1 секунду”, иногда для больших нагрузок использовали меньше времени, и количество циклов Loop Count.
По результатам тестирования был проделан ряд работ, как по оптимизации проекта, так и по конфигурации серверов. А именно: разделение сложного функционала на разные микро сервисы, каждый из которых находится в своем AWS-контейнере, настроено auto scaling group, DB read replics, Elastic Cashe, медиа-контент был вынесен на S3.
Из сложного функционала у нас калькуляторы. ROI-калькулятор и калькулятор цены ИТ-продуктов. Примеры можно посмотреть по ссылкам, чтобы было нагляднее (на ссылках даны примеры расчета цены и ROI конкретных продуктов, а такие расчеты возможны абсолютно для всех без исключения решений и продуктов, даже самых сложных). Именно такие расчеты при одновременном использовании определенном количеством пользователей ранее тормозили работу сервиса.
Обновленный вариант архитектуры
Спасибо за ответ. Но он все еще недостаточно «технический» :-) Перечитайте мой вопрос снова и найдите конкретный ответ на каждый, заданный мной изначально вопрос. Я не смог найти ответ практически ни на один из заданных. Кроме подтверждения того что переезд был с одного из необлачных хостеров на AWS. Но далее — туман… никаких попугаев «до» и «после». Изначально: 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth. Памяти маловато почти для любой задачи. Соединение в сеть — возможно не испрользовалось и на 10% а возможно на 100% — опять нет конкретики. После переезда — упало до 10%? или до 90%? а CPU? В целом статья читается как ракламный проспект и возможно для не специалистов вполне «звучит». Предоставленные разъяснения тоже носят хоть и более технический и «архитектурный» характер все же не дает ответа на то как и почему AWS «улучшить производительность сайта в 8 раз». А скорее просто говорит: обращайтесь к нам и будет вам счастье!
Спасибо за ваши вопросы. Мы постараемся на все ответить.
В начале на одном сервере было все Apcahe, PHP версия 5.6 (уже перешли на 7), MariaDB, почта и также кэш локально хранили. Теперь на AWS все разнесли.
Сначала использовался сервер 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth, после переезда на AWS используем c4.xlarge (конфигурацию можно посмотреть на сайте AWS)
Выводы касательно нагрузки делали по времени по таким показателям (Load Time, First Byte, Start Render, Response time и также по пропускной способности выполняемых запросов). С переходам на AWS мы вынесли SSL сертификат на ELB, что сократило время получения First Byte на 0,5 сек. Вынесли медиа-контент на EFS, чтобы нормально отрабатывал автоскелинг и вынесли кэш на AWS Elastic Cache. Также, благодаря RDS, где настроили несколько Read Replica, увеличилась пропускная способность запросов к БД, количество одновременных конекшенов в БД. Так при старом хостере при тестировании 100 человек с интервалом 10 секунд, 10 чел/сек – сайт падал. Новый спокойно выдерживает тестирование 500 человек с интервалом 10 секунд, 50 чел/сек.
К вашей заметке “обращайтесь к нам и будет вам счастье!” — счастье всем, мы надеемся, будет :) Но если вдруг эта статья похожа на рекламу AWS, то это совершенно не так. Наш ресурс не продает ни продукты, ни услуги по интеграции. Мы для покупателей ИТ вообще работаем бесплатно. И пока мы на стадии бета-тестирования — для поставщиков ИТ тоже. Мы — площадка, которая помогает поставщикам, покупателям и производителям найти друг друга на наиболее выгодных и быстрых для всех условиях. Сами AWS купили, интегрировали другие. Мы поделились тем, что нам помогло, т.к. это и слоган проекта “Узнайте пользу ИТ” — стараемся придерживаться, узнавать и другим рассказывать, в данном случае на собственном примере.
Кстати, мы очень заинтересованы в таких тестерах как Вы. Вам было бы интересно взглянуть на весь проект и дать свои комментарии? Воспользоваться теми функциями, которые могут быть вам интересны. Еще раз напомним, мы на стадии бета-тестирования, поэтому это очень актуально для нас. Вот проект
В начале на одном сервере было все Apcahe, PHP версия 5.6 (уже перешли на 7), MariaDB, почта и также кэш локально хранили. Теперь на AWS все разнесли.
Сначала использовался сервер 2 vCPU, 4096mb RAM, 60gb SSD, 3GB/s bandwidth, после переезда на AWS используем c4.xlarge (конфигурацию можно посмотреть на сайте AWS)
Выводы касательно нагрузки делали по времени по таким показателям (Load Time, First Byte, Start Render, Response time и также по пропускной способности выполняемых запросов). С переходам на AWS мы вынесли SSL сертификат на ELB, что сократило время получения First Byte на 0,5 сек. Вынесли медиа-контент на EFS, чтобы нормально отрабатывал автоскелинг и вынесли кэш на AWS Elastic Cache. Также, благодаря RDS, где настроили несколько Read Replica, увеличилась пропускная способность запросов к БД, количество одновременных конекшенов в БД. Так при старом хостере при тестировании 100 человек с интервалом 10 секунд, 10 чел/сек – сайт падал. Новый спокойно выдерживает тестирование 500 человек с интервалом 10 секунд, 50 чел/сек.
К вашей заметке “обращайтесь к нам и будет вам счастье!” — счастье всем, мы надеемся, будет :) Но если вдруг эта статья похожа на рекламу AWS, то это совершенно не так. Наш ресурс не продает ни продукты, ни услуги по интеграции. Мы для покупателей ИТ вообще работаем бесплатно. И пока мы на стадии бета-тестирования — для поставщиков ИТ тоже. Мы — площадка, которая помогает поставщикам, покупателям и производителям найти друг друга на наиболее выгодных и быстрых для всех условиях. Сами AWS купили, интегрировали другие. Мы поделились тем, что нам помогло, т.к. это и слоган проекта “Узнайте пользу ИТ” — стараемся придерживаться, узнавать и другим рассказывать, в данном случае на собственном примере.
Кстати, мы очень заинтересованы в таких тестерах как Вы. Вам было бы интересно взглянуть на весь проект и дать свои комментарии? Воспользоваться теми функциями, которые могут быть вам интересны. Еще раз напомним, мы на стадии бета-тестирования, поэтому это очень актуально для нас. Вот проект
Хотел ответить развернуто снова. Но затем перечитал последний абзац. Может мне показалось но
«Кстати, мы очень заинтересованы в таких тестерах как Вы.»думал это комплимент. Типа я дотошный в хорошем смысле слова и вам нужна профессиональная помощь.
«Вам было бы интересно взглянуть на весь проект и дать свои комментарии?»хотел ответить «да». Но затем вчитался:
«Воспользоваться теми функциями, которые могут быть вам интересны.»Опять какая то реклама каких то гипотетических но весьма полезных и очень полезных не только мне, но видимо ВСЕМ «функций».
«Еще раз напомним, мы на стадии бета-тестирования, поэтому это очень актуально для нас. Вот проект»на секунду показалось, что вам таки нужен совет и мое мнение. Но пройдя по ссылке которая ведет на ваш сайт, а не на какой не проект, понял что вы супер маркетологи. Хабра минус, Хабра плюс — вам без разницы! Ссылочная масса растет, ключевые слова на месте. SEO работает, а все остальное по боку! Молодцы!
Спасибо Вам за Ваши ответы.
«думал это комплимент. Типа я дотошный в хорошем смысле слова и вам нужна профессиональная помощь.» — Вы все правильно поняли, нам важно мнение и комментарии о проекте, тем более от таких внимательных, как Вы.
Если фичи, предлагаемые проектом, не пересекаются с вашии профессиональными интересами — Вы можете дать общее мнение о восприятии вами проекта, о чем он даже. Если Вам будет это интересно.
У нас есть проблема, из-за первых страниц сайта многие воспринимают проект как маркет плейс, но это не так.
«что вам таки нужен совет и мое мнение.» — он-таки нужен :) И если вы поделитесь им — будем благодарны.
«Но пройдя по ссылке которая ведет на ваш сайт, а не на какой не проект» — это сайт проекта. Вот здесь и хотелось бы узнать подробнее, что именно вас смутило и вызвало реакцию, «что это не проект». — будем благодарны.
«понял что вы супер маркетологи.» — вот это настоящий комплимент, потому что маркетологов у нас еще нет, да и PR мы еще не занимаемся, и ссылочная масса не столько важна, мы готовим проект к этому, нам сейчас важно пройти стадию бета-тестирования, услышать мнения о проекте и сделать его лучше прежде чем двигать проект в массы.
Эта статья была с целью поеделиться своим опытом. С нашим потенциальным пиаром она не пересекается, так как проект международный и наша основная целевая аудитория — это западный рынок. Спасибо.
«думал это комплимент. Типа я дотошный в хорошем смысле слова и вам нужна профессиональная помощь.» — Вы все правильно поняли, нам важно мнение и комментарии о проекте, тем более от таких внимательных, как Вы.
Если фичи, предлагаемые проектом, не пересекаются с вашии профессиональными интересами — Вы можете дать общее мнение о восприятии вами проекта, о чем он даже. Если Вам будет это интересно.
У нас есть проблема, из-за первых страниц сайта многие воспринимают проект как маркет плейс, но это не так.
«что вам таки нужен совет и мое мнение.» — он-таки нужен :) И если вы поделитесь им — будем благодарны.
«Но пройдя по ссылке которая ведет на ваш сайт, а не на какой не проект» — это сайт проекта. Вот здесь и хотелось бы узнать подробнее, что именно вас смутило и вызвало реакцию, «что это не проект». — будем благодарны.
«понял что вы супер маркетологи.» — вот это настоящий комплимент, потому что маркетологов у нас еще нет, да и PR мы еще не занимаемся, и ссылочная масса не столько важна, мы готовим проект к этому, нам сейчас важно пройти стадию бета-тестирования, услышать мнения о проекте и сделать его лучше прежде чем двигать проект в массы.
Эта статья была с целью поеделиться своим опытом. С нашим потенциальным пиаром она не пересекается, так как проект международный и наша основная целевая аудитория — это западный рынок. Спасибо.
Нас действительно масштабно заминусовали за эту статью. Благодарим за все вопросы, как конструктивную критику. Мы готовы максимально ответить на все вопросы, которые у Вас возникают. Благодаря Вашим комментариям мы обратили внимание на несовершенство статьи и дополним ее деталями, которые Вас интересовали. Спасибо за все вопросы.
Эта статья про наш опыт преодоления разных проблем, которые исторически сложились при разработке проекта, и возможность их решить, на наш взгляд, не самым плохим образом, — это переездом на AWS. Плюс в статье на собственном примере мы раскрыли ключевые возможности ресурса — это взаимодействия между Производителем в данном примере AWS и дистрибьютором, а также возможность расчета выгоды (roi), что в нашем случае принесло нам выигрыш по деньгам и по времени разработки.
Эта статья про наш опыт преодоления разных проблем, которые исторически сложились при разработке проекта, и возможность их решить, на наш взгляд, не самым плохим образом, — это переездом на AWS. Плюс в статье на собственном примере мы раскрыли ключевые возможности ресурса — это взаимодействия между Производителем в данном примере AWS и дистрибьютором, а также возможность расчета выгоды (roi), что в нашем случае принесло нам выигрыш по деньгам и по времени разработки.
Sign up to leave a comment.
Как улучшить производительность сайта в 8 раз: наш опыт интеграции сервисов AWS