Комментарии на: Особенности средних нагрузок

От: Иван

Иван — Wed, 20 Jan 2010 16:54:45 +0000

Хорошая статья. Интересная. Об этом можно целый блог отдельный открыть. А может быть такой уже есть и кто то знает?

Для начинающего (растущего) программиста, менеджера проектов подобную информацию не найти. Она очень ценная. Спасибо.

От: asserte

asserte — Tue, 22 Dec 2009 12:44:13 +0000

Немного критики )

>> Во всех системах статистики производится частые вставки (INSERT) в одну таблицу или группу таблиц…
Во всех системах статистики ведется т.н. промежуточное кеширование информации. Т.е. висит себе демон в памяти и сбрасывает все в файлик с критической частотой. А по расписанию кидает все в базу (вспоминаем пересчеты статистики li.ru и иже с ними)

>> Другой случай может оказаться сложнее, и в другую БД будет писаться информация, которая потом будет использоваться на проекте (на основном сервере). Поэтому данные двух баз данных нужно как-то синхронизировать.
Схему репликации Master-Master крайне не советую использовать.

По поводу базы. Некритичные данные можно инсертить на мастер-сервер, а забирать из слейв-сервера. Но такая схема работы подразумевает жесткое условие: Идет обновление данных – работаем с мастером. Идет чтение – работаем со слейвом. На проектах, с 1к запросами в секунду (биллинг) только так и получается балансировать на грани сохранения резерва вычислительной мощности двух серверов.

>> Сессии, как и база данных, по сути, является файловым хранилищем (файлы сессий хранятся на жестком диске сервера), поэтому обращение к ним следует минимизировать.
Даже если вы уберете данные из сессии, то идентификатор-то все-равно лежит на ФС. А скорость доступа к файлу, в основном, зависит от скорости поиска. Т.е. изменение размера файла сессии с 5кб на 1кб вы ничего не получите. Только геморрой и будете тратить лишнее процессорное время на операции анализа куков (или, неявно, воспользуетесь стандартным разборщиком). Обратите внимание, что от хранения файлов сессий на ФС вы так и не отказались

>> Скрипты, как их не оптимизируй создают большую нагрузку на процессор.
Число пи высчитываете? При загрузке процессора 0.75 php-cgi (спаунинг) ест не более 0.01. Остальное – СУБД.

От: Ivan

Ivan — Fri, 11 Dec 2009 13:27:10 +0000

Вы еще не упомянули про раздельную обработку статики и динамики. Статику (картинки, джаваскрипт и CSS) можно отдавать легким сервером, наподобие nginxX или lighttpd.
Динамику можно перекидывать на Апач или другой сервер (томкат, например, если используется Java).
Т.е. используется двухзвенная система из веб-серверов. На фронте (на морде) стоит легкий сервер, который обрабатывает статику. А запросы на динамику он передает на бек-енд сервер (Апач, томкат и т.п.).
…
Я бы начинал оптимизировать именно с этого.
Второй вещью, которой бы сделал – это использование кешера, типа memcached.

От: Юриус

Юриус — Fri, 11 Dec 2009 00:21:51 +0000

>> Для больших проектов лучше использовать DLE.Особенно кеш >> мне там нравиться

Серьезно? ) Цифры есть или голословно?

Статья неплохая, правда вот теория кругом одна, нет бы что-нибудь из реализации показать )

От: Alex

Alex — Mon, 07 Dec 2009 13:35:38 +0000

Спасибо. Продолжение было бы весьма интересно.

От: Алексей

Алексей — Wed, 21 Oct 2009 15:20:04 +0000

Интересно…. реальная цифра…. с трудом верица мне..

От: VolAnd

VolAnd — Tue, 29 Sep 2009 17:25:26 +0000

“300 тысяч человек” – АХРЕНЕТЬ!!! (завидую)
Толковая статейка. Хотелось бы узнать из Вашего блога больше про XML. Вы очень доходчиво пишете.