Комментарии 35
Изменили больше 14 000 файлов.
модуль Веб-кластера
вот за это вас и не любят
Не могли бы Вы развернуть свой комментарий:
— чем плох модуль веб-кластера
— по какой причине Вы считаете, что изменение такого количества файлов в рамках рефакторинга — плохо?
— чем плох модуль веб-кластера
— по какой причине Вы считаете, что изменение такого количества файлов в рамках рефакторинга — плохо?
НЛО прилетело и опубликовало эту надпись здесь
14 тыщ файлов? 4 тыщи запросов? Да как такое возможно-то вообще?
Такого добиться легко, если выполнять запросы в цикле и без джоинов :)
А что там выбирать? Один запрос на выборку товаров из категорий, один запрос с парочкой жоинов на выборку инфы товара. Плюс еще ну 10-20 запросов на построение страницы, половина которых в кеше.
А уж раз с циклами, то на странице, ну максимум, может быть 50 товаров + несколько запросов на выбор цены, параметров, картинки = 400-600 запросов. Но это тоже неправильно.
А уж раз с циклами, то на странице, ну максимум, может быть 50 товаров + несколько запросов на выбор цены, параметров, картинки = 400-600 запросов. Но это тоже неправильно.
еще: один запрос на регион, один запрос на меню, примерно 20 на формирование динамических фильтров, которые подстраиваются под характеристики товаров в наличии, один запрос на цены, один запрос на наличие, штук 5-10 на корзину, несколько запросов на различные акции, несколько запросов на дополнительную информацию о товаре, которая не хранится в информации о товаре (типа отзывов), почти все с джоинами, потому что все связано или с регионами, или с товарами.
Да, мы тоже сначала не поверили — но статистика репозитория и статистика отладчика говорили, что именно столько. Это очень сомнительные цифры, мы понимаем, но у нас есть экземпляр старого сайта и перед написанием статьи мы все проверили.
Также мы добавили бонус для последующих разработчиков проекта: для того, чтобы в дальнейшем код легко читался, мы разбросали многотысячные простыни кода на отдельные классы и файлы
Бонус так бонус.
Думаю, дело «в общем», а не в рефакторинге.
С одной каталожной страницы генерируется от 3000 до 4000 запросов к БД без кэша, с кэшем—около двухсот запросов.
до рефакторинга и реинжиниринга системы при нагрузке в 25 одновременных пользователей страница грузится около 8с, а после нее – только 4,2с.
О_о
Как же там все ужасно, похоже. 4,2с это не нормально, тем более для всего 25 юзеров.
Имхо — готовые CMS для проектов сколько нибудь серьезного уровня использовать… ну не стоит, мне кажется. Да и дешевле может выйти, если нормально разрабатывать заточенное решение. Чем потом заказывать такие рефакторинги на полгода.
Когда клиент к нам пришел, решение уже было сделано на 1С-Битриксе, мы лишь помогли спасти проект. Но как следует из описания, проблема была не в CMS, и мы это успешно доказали финальным нагрузочным тестированием. Готовые CMS хороши с точки зрения преемственности кода, в таком случае смена программистов на проекте не будет критичной. Если вы разрабатываете полностью свое кастомное решение, уход носителя знаний с проекта будет очень критичен, потому что каждый новый человек будет начинать с фразы «давайте перепишем все с нуля».
Странно, но для меня пол секунды на страницу — уже очень много. Кеш — это не способ исправить плохую архитектуру.
какой то перебор мне кажется в цифрах, что за 3000-4000 запросов, мне кажется столько mysql не сможет пережить если они выполняются на каждой странице.
Хорошо, что Вы не сталкивались в своей практике с подобными проектами, нам, к сожалению, не так повезло. 3000-4000 запросов к БД как раз и были критичными для данного проекта, когда мы замерили статистику после первичной стабилизации — было 600 со страницы. Проект начал работать, хоть и медленно.
НЛО прилетело и опубликовало эту надпись здесь
Я правильно понимаю, что Заказчик получил расхода на битрикс, на интеграцию с 1С, на разработку сайта + работы по ускорению системы?
Эти расходы больше или меньше чем решения на фреймворках?
Эти расходы больше или меньше чем решения на фреймворках?
Это сравнимо. Решение в пользу рефакторинга было принято из-за клиентских данных, из-за интеграционных частей не на стороне сайта и из-за легкости перехода с одного ядра на другое. Если вы помните, то Утконос, чтобы перевести сайт на другую платформу, закрывался на неделю. Даунтайм нашего клиента при переходе составил всего 36 часов.
Перевод сайта с одной платформы на другую при сохранении связей с бэком (УТ или что там еще стоит) можно сделать за 5 секунд (без учета времени разработки системы на новой платформе.)
Интересно через какое время Заказчик упрется в очередной «потолок».
Интересно через какое время Заказчик упрется в очередной «потолок».
К сожалению, у нас не было права выбора в данном случае. Мы рассчитывали, что на данных серверных мощностях ему хватит примерно на полтора-два года. После этого нужно будет масштабироваться по серверам.
Все просто: Упрется в потолок — заплатит еще раз
6 месяцев человекочасов — это же такая большая приятная куча денег
6 месяцев человекочасов — это же такая большая приятная куча денег
77 запросов в секунду. И что в этом такого?
Не понимаю как после таких статей хоть кто-то еще пользуется битриксом
На последовательное проведение всех перечисленных работ у нас ушло около 6 месяцев.
Вот это прикол :)
Внимание вопрос:
Сколько надо времени чтобы сделать интернет магазин, если выкинуть битрикс и учесть что уже готово следующие: дизайн, верстка, всякие js и БД??
это чё ж за магазин такой?
Вот это прикол :)
Внимание вопрос:
Сколько надо времени чтобы сделать интернет магазин, если выкинуть битрикс и учесть что уже готово следующие: дизайн, верстка, всякие js и БД??
это чё ж за магазин такой?
Интернет магазин с 8ю серверами и 300 уникальных посетителей в день?
Что это за магазин такой, наркотиками что ли торгуют?
Может ссылку хотя бы опубликовать на него?
Что это за магазин такой, наркотиками что ли торгуют?
Может ссылку хотя бы опубликовать на него?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как заставить интернет-магазин выдерживать нагрузку 280 000 посетителей в час?