- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Задача такова!
Есть сервер не сильно мощный но все же, на данном сервере нужно разместить 150 ... блогов (не сплоги).
Нужно оптимизировать расход ресурсов сервера на размытые по доменам запросы.
Так вот смысл в том, что если скажем оптимизировать 1 блог под большое кол-во траффика это без вопроса, а вот если надо оптимизировать скажем большое число запросов которые размыты по доменам? Как это сделать? Тут кешь по свое сути не целесообразно держать.
- На что налегать программисту при написании такого скрипт или при тюнинге существующего?
Ему надо ведь грамотно обосновать еще это все.
PS скрипт блога будет либо писаться либо тюниться какой то уже существующий (php без Mysql).
Нагрузка зависит от возможностей скрипта. Простой блог скрипт написанный "под себя", хоть 100к уников в сутки на дохлом сервере выдержит.
Могу посоветовать OpenBlog, сделанный на CodeIgniter.
Сомневаюсь что получиться оттюнить какой то существующий. Лучше всего писать. Делать минимальное ядро 2-3 класса и получиться тот же CodeIgniter, только генерация страницы будет 50 раз меньше. Потом поставить какой то аксселератор. Использовать http кеш на проксирующем сервере. Да много чего еще можно оптимизировать, только тут нужно уже считать дешевле работа программиста или взять нормальный сервер.
Лучше drupal он быстрее и править несложно
Без кеша?
Все верно я его верный противник. Это не движек а windows.
По подробнее можно? Лучше один раз прогреу заплатить чем постоянно платить за железяки, да и это более умно чем ставку делать в сторону железа!
MaxSite CMS для любителей вордпреса
но не такой прожорливый.
какой друпал какой MaxSite CMS? Вы о чем говорите? Это не реально вообще 150 блогов активных держать на этих движках и при этом экономить на железяках. Там монстр сервер нужен. Я еще раз подчеркиваю активных! А не те кто встали с кешем месячным и стоят.
Alian добавил 16.12.2010 в 14:00
Сейчас копаю скрипт именно Zebrum Lite (думал дописать к нему мультиадминку аля WPMU), но к моему сожалению авторы скрипта идут настолько туго на контакт и мало что пишут, да и долго они это делают, что я уже подумываю попросту реально конечно же написать свой.
Мультиадминка - Zebrum CMS. Правда, она платная.
20 сайтов с посещялкой в 20-30 уников в сутки комфортно чувствуют себя на хостинге за 2 уе. CMS - Zebrum Lite, управляю ими из Zebrum CMS
я не против но саппорт не дает демку смотреть говорит а нет ее у нас.
Какого кеша, кеша чего ?
Имея четкие требования к функционалу, можно вполне уложиться в 2-3 запроса к базе на страницу. А это в общем то копейки.
Если блоги стандалоне то смотрите в сторону MaxSite, а если мультиблоговая система то подойдёт LifeType. На обычном хостинге у меня этот движок спокойно работал при 500 уникальных. Разработчики утверждают что у нормального хостинг провайдера и 2000 посетителей не проблема.
На оперативку придется раскошелиться по любому. Проц может быть минимальный что уже есть. Возможные варианты оптимизации такие:
1) Писать с нуля и только с нуля. У готовых скриптов overhead большой всегда будет
2) Исключить все по минимуму. Т.е. например сессии, юзать memcached вместо файлов. Если сессии не нужны то лучше исключить вообще.
3) Поставить PHP 5.3 и php акселератор. Можно выиграть таким образом до 30-40% производительности.
4) Использовать 2 сервера как бэкенд и как фронт. Бэк сервер будет генерировать страницу только если нужно, если что-то изменилось. Фронт любой легкий http сервер как проксирующий(lighttpd, nginx) и написать реализацию HTTP кэша. Это нужно сделать в движке. Читаем тут http://docs.symfony-reloaded.org/guides/cache/http.html что и для чего нужно это.
5) Ни в коем случае не юзать файлы вместо БД. Насколько я понимаю данных много. Индексы в реляционных БД и нужны чтобы быстро найти данные. На файлах это не сделаете или в итоге придете к тому что изобретаете велосипед с теми же индексами.
Чтобы еще ускорить нужно смотреть полностью все, информации нет могу только предполагать. Поэтому таких вещей как MongoDB не предлагаю так как не знаю какого рода данные будут и что вообще планируется. Блог это понятно, но его можно сделать по разному.