8 сентября 2011 в 1:05
есть заказ, размышляем над реализацией.
надо магазин.
по условиям, должен держать нагрузку:
150к хитов в день, из них 50к хитов за первые три часа
500 заказов в день, из них 300 в первые два часа.
примерно 30% трафика - авторизованные пользователи
планируем d7+ubercart
мы такими серьезными в плане нагрузки проектами еще не занимались.
какие шансы что это все будет нормально работать без извращений ( в виде хаков ядра и отказа от вьюсов и всех модулей кроме user и node ), но с memcached+varnish+nginx+возможно бд на отдельной машине? (например, на главной ожидается пара-тройка вьюсов)
читал много-много всего, но конкретных примеров - мол семерка без хаков с вьюсами и варнишем тянет такое-то кол-во авторизованных - не видел.
еще вопрос, кто чем посоветует проводить стресс-тесты (надо генерировать анонимный/авторизованный траффик 70/30, и эмулировать создание заказов)?
заранее благодарен.
вот этот доклад представляет интерес: http://romka.eu/blog/doklad-na-drupalconfmoscow-2011
но там нет второй части, про сетап машин - не понятно какой кластер все это обслуживает.. ну и boost мне кажется не очень полезен будет в нашем случае
Комментарии
вните когонибудь из Патруля, или на орге, не думаю что у многих есть похожий опыт для д7
если "по деньгам" отдельный серваки держать...
Наверное и от вьюса отказаться осилите?
тем более, что API и системы темизации и кэширования в семерке - "пальчики оближешь"-)))
Такие примеры могут быть только на конкретном уже сделанном проекте, и они вам ничего на самом деле не дадут, минимальные отличия могут изменить всё в разы...
Сделайте главную, сделайте тестовые данные, нагрузите, профилируйте, оптимизируйте БД, и.т.п. Как сделаете, так работать и будет...
Не полагайтесь на то, что все авторы модулей которые вы будете использовать хотя бы задумывались об оптимизации производительности - пилить наверняка будет что.
Siege, например.
Varnish зачем тут? Memcached не такой и быстрый кеш, он полезен в первую очередь, когда доступ к кешу нужен не только локально, как локальный кеш будет шустрее APC, а часто хорошим вариантом является и кеш файловой системы, вы же не на шаред хостинге, тут многое зависит от объёма данных и от того, что и как кешируется. БД на отдельном сервере большой плюс, если хороший линк к ней. Надо правильно под базу и сайт подобрать конфиг, качественно всё настроить.
П.С. А 500 заказов за 2 часа, на самом деле, не так и много.
Ставлю клеймо тролля.
Отказ от вьюса в данном случае малооправдан.
Автору смотреть на дедики средней ценовой категории, 300-500 баксов
Опровергаешь...аргументируй..
иначе сам знаешь как это называется...
Опыт - главный аргумент, вас я причислю к оптимизаторам по переписке.
Про экономию на копейках слышали?
Я в вашем предложении переписывания на самопис аргументации не слишком много вижу.
Угомонитесь, а то накликаете того кого нельзя называть
спасибо за ответы!
сейчас как раз будем заниматься тестами.
главное, чтобы не пришлось потом пилить всё что есть
отказ от views - можно в крайнем случае, но неудобно. хотелось бы избежать вступления в армию "да мы все с нуля написали на голом Друпале, и работает у нас быстро", потому что это нездоровый подход - пожалуй, проще взять yii в таком случае.
Друпал не голый-))
У него есть, довольно мощное API.
А сделать выборку из БД и темизировать вывод... немного дольше чем настроить Вьюс... но гибче.
Можно оптимизировать под конкретные задачи запросы к бд, темизацию, систему кеширования вывода..
а еще гибче на фреймоворке
спасибо за информацию
мое дело - предложить вариант... ваше дело - отказаться..
швабода...
Чем все закончилось? Взяли проект? Если да, то как реализовали?
ну 150 килохитов то понятно как для нагрузки, но причем тут кол-во заказов?
разобрался с jMeter, погоняли тестовый сайт на облаке, в принципе все нормально, само собой придется кое-что оптимизировать, а проект пока откладывается до янв-февраля.