31.10.2020 | 21:20
[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]
  • Страница 1 из 1
  • 1
Форум L2edit.Ru » Lineage 2 » Java сервер » Протестировать производительность сервера
Протестировать производительность сервера
LestatДата: Воскресенье, 09.01.2011, 21:22 | Сообщение # 1
Lestat
Группа: Постоянный
Сообщений: 22
Награды: 1
Репутация: 0
Статус: Offline
Привет.
Есть модифицированная сетевая часть сервера, которая должна давать куда лучшую производительность при большом количестве пакетов. Как можно это протестировать? Я слышал что есть софт, который может зафлудить сервер пакетами... Можно ссылочку, если кто знает?

загрузка наград ...
 
asasinnДата: Вторник, 11.01.2011, 17:29 | Сообщение # 2
asasinn
Группа: Заблокированные
Сообщений: 453
Награды: 49
Репутация: -10000
Статус: Offline
Даже не понял о чём ты


загрузка наград ...
 
LestatДата: Вторник, 11.01.2011, 23:52 | Сообщение # 3
Lestat
Группа: Постоянный
Сообщений: 22
Награды: 1
Репутация: 0
Статус: Offline
Делать было нечего и я покопался в сетевой части сервака, подфиксил часть, которая теоретически может дать неплохой прирост производительности при большом количестве пакетов. Теперь хочу проверить это на практике: мне нужно завалить его пакетами и сравнить производительность (количество обработанных пакетов в единицу времени), желательно имитировать большое количество одновременных игроков. Я слышал, что есть боты, которые такое умеют делать, вроде как "хлап" называется - точно не помню... Вот хочу что-то такое найти.
загрузка наград ...
 
asasinnДата: Среда, 12.01.2011, 19:58 | Сообщение # 4
asasinn
Группа: Заблокированные
Сообщений: 453
Награды: 49
Репутация: -10000
Статус: Offline
По материалам статьи Neil Boyle на swynk.com "SQL Server two minute memory tune-up"
http://www.swynk.com/friends/boyle/default.asp

В своей статье, Нейл предлагает нам удобный способ оценки оптимальности настроек SQL сервера для обеспечения максимального КПД использования памяти. Ниже представлен используемый автором для этих целей скрипт, который запускается, как на SQL 6.5, так и на 7 (с учётом некоторых оговорок, следующих по тексту статьи).

dbcc traceon(3604)
go
dbcc sqlperf(lrustats)
go
dbcc bufcount(1)
go
-- dbcc memusage - Перед использованием прочтите комментарий для SQL Server 7
go
dbcc proccache
go
dbcc traceoff(3604)

Dbcc traceon - разрешает использование некоторых команд из представленного скрипта (иначе они не выполняются). Traceoff - в конец выключает эту возможность.
Dbcc sqlperf(lrustats) - выдаёт подробности использования кэша. Наиболее интересные для Вашего анализа значения: "cache hit ratio" - которое у Вас должно стремиться к 100 %; "cache flushes" - которое выдаёт число сброса данных из кэша на диск, для высвобождения места другим данным. В идеальном случае, значение "cache flushes" должно равняться нулю (если только размер Вашей базы данных не значительно превышает размер ОЗУ).
Если выданные Вам значения не выглядят удовлетворительными, используйте команду "Sp_configure memory", чтобы понять, имеет ли SQL сервер достаточно памяти. Это особенно важно для 6.5, у которого по умолчанию установлено очень маленькое значения отводимой серверу баз данных памяти. В SQL 7 память выделяется автоматически. См. "Причины не эффективного использования кэша" в конце этой статьи, если с памятью у Вас всё в порядке.
Размер памяти, которую Вы отдаёте SQL 6.5, зависит от того, какие еще задачи обслуживает ваш сервер. Для получения более подробной информации, посмотрите статью Microsoft:
http://support.microsoft.com/support/kb/articles/Q110/9/83.asp
которая содержит примеры, рекомендации и параметры настройки памяти.
Dbcc bufcount(1) пользователи SQL 7 могут пропустить эту команду, поскольку конфигурирование у них автоматическое. Для пользователей SQL 6.5 особый интерес представляет выводимая в отчёте строка, подобная "The Average Chain Size is: 2.922601".
Это означает, что эффективность структуры индексации кэша - оценивается между 2 и 4. Величина близкая к 3, является оптимумом в SQL 6.5. Помочь в регулировке этого значения может - "sp_configure hash buckets", которая плохо документирована в документации по SQL 6.5. Как правило, у многих DBA сохраняется настройка по умолчанию. Дополнительную информацию относительно этой установки смотрите на узле поддержки Microsoft:
http://support.microsoft.com/support/kb/articles/Q151/2/56.asp
Dbcc memusage детализирует информацию о Ваших больших таблицах, которые находятся в настоящее время в кэше. Идеально они должны находиться в кэше как можно дольше, так что желательно, при каждом запуске скрипта, помечать себе какие объекты находятся в кэше, и какое пространство они там занимают.
SQL 6.5 детализирует также информацию о самых больших хранимых процедурах, находящихся в Вашем кэше. Более подробно о процедурах - ниже по тексту.

Предупреждение для пользователей SQL 7!
Статья Microsoft: http://support.microsoft.com/support/kb/articles/Q196/6/29.ASP
не рекомендует Вам выполнять команду dbcc memusage на SQL 7. Нейл пишет, что никогда не имел проблем с этой командой, но советует Вам не использовать её на промышленных серверах.

Dbcc proccache выводит краткую информацию об использования кэша процедур.
В SQL 7 достаточно дескрипторов, характеризующих это, но в SQL 6.5 дополнительная информация, выдаваемая этой командой, будет Вам полезна. Это происходит потому, что SQL 6.5 по умолчанию распределяет 30 % памяти SQL сервера для кэша хранимых процедур, в то время как остальная память отводится данным. В конфигурациях с большой емкостью памяти это может привести к тому, что для процедур выделяется не оправдано большая часть памяти, которая фактически не используется, а могла бы быть выделена для кэширования данных. Для регулировки этого значения можно использовать - "sp_configure procedure cache".
Помните, что существует опасность для нормальной работы сервера баз данных, если установлено слишком маленькое значение кэша процедур. Изменяйте это значение поэтапно и на небольшую величину и никогда его не обнуляйте. Этой теме посвящена статья Microsoft:
http://support.microsoft.com/support/kb/articles/Q192/9/62.ASP

Причины не эффективного использования кэша

Наиболее очевидной причиной неэффективного использования кэша является недостаток доступной оперативной памяти или выделение SQL серверу недостаточного её количества. Нейл рекомендует, прежде чем Вы отправитесь к поставщикам за дополнительными DIMM модулями, проанализируйте другие возможные причины не эффективного её использования:
1. Отсутствие индексов может вызывать частое сканирования таблиц, которые вытесняют другие данные из кэша. В SQL 7 можно наблюдать эти процессы с помощью SQL Profiler и Index Wizard. Ознакомьтесь с материалами на
http://www.swynk.com/friends/boyle/indextuningwizard.asp ,
чтобы обнаружить вредные сканирования таблицы и улучшать эффективность использования индексов. К сожалению, пользователи SQL 6.5 должны делает это более сложным путём.
2. Плохо организованный проект базы данных и не достаточно продуманные проекты запросов могут приводить к сканированию таблицы без использования существующих индексов, что становится причиной чрезмерной утилизации дисковой подсистемы и неэффективному использованию памяти.
3. Смешивание баз данных с OLTP (короткие транзакции) и OLAP (большие отчёты) на одном сервере баз данных, также можно стать причиной неэффективного использования кэша и появления других проблем.
Дополнительную информацию на эту тему можно почерпнуть из статьи Microsoft:
http://support.microsoft.com/support/kb/articles/Q110/3/52.asp

Другие возможности распределения памяти

Кэш это один из наиболее важных показателей ОПЕРАТИВНОЙ ПАМЯТИ, но ни в коем случае ни единственно важный. SQL сервер выделяет память для кэширования только после того, как выполнены многие другие требования. Из этого следует, что Вы можете увеличивать или уменьшать количество памяти, доступной для кэша, регулируя распределение памяти между другими аспектами сервера, особенно это существенно для версии 6.5, которая не умеет динамически распределять память, как более поздние версии.
Для примера, посмотрите некоторые параметры настройки, которые Вы можете изменять:
Sort Pages (только 6.5);
Index Create Memory (только 7);
Locks;
Open Objects;
Tempdb In RAM (только 6.5, и обычно не рекомендуемые Microsoft
http://support.microsoft.com/support/kb/articles/Q115/0/50.asp );

Существуют и другие важные параметры, о которых Вы можете узнать на
http://support.microoft.com/

Предупреждение! Неправильная установка для любого из перечисленных параметров может привести к "краху" Вашего сервера! Поэтому, тщательно изучите рекомендации Microsoft по установке и изменению конфигурационных значений и меняйте их постепенно на небольшую величину, анализируя поведение сервера с помощью специализированных утилит или по результатам работы соответствующих процедур.

КОМЕНТАРИЙ АВТОРА ПЕРЕВОДА:

От себя к этому добавлю, что нельзя забывать также о том, что сервер баз данных находится в плотном взаимодействии с операционной системой и другим программным и аппаратным обеспечением. Поэтому проблемы кэширования и распределения памяти нужно анализировать комплексно, особенно тщательно следя за разделяемыми между сервером, ОС и другими программами ресурсами.



загрузка наград ...
 
asasinnДата: Среда, 12.01.2011, 19:59 | Сообщение # 5
asasinn
Группа: Заблокированные
Сообщений: 453
Награды: 49
Репутация: -10000
Статус: Offline
Процессор: "% Processor Time" - показывает загрузку CPU. В многопроцессорной системе возможна диагностика загрузки, как каждого процессора в отдельности, так и всех вместе. Также, одноимённый параметр можно использовать для определения утилизации процессора каждым потоком. Если "% Processor Time" показывает среднее значение в диапазоне 80 % - 100 %, это говорит о проблеме с производительностью Вашей системы. Необходимо принимать меры по масштабированию системы или изменения конфигурации. В то же время, кратковременное достижение "% Processor Time" - 80 % уровня или даже пики до 100 % ничто опасного или нежелательного не представляют. Поскольку ресурсы процессора использует не только сервер баз данных, Вы должны определить является ли SQL Server причиной высокой утилизации процессорного времени. Используйте SQLServer: CPUtime для определения доли SQL сервера в "% Processor Time". Выяснив, что причина повышенной загрузки процессоров является SQL сервер, а также какой процесс её провоцирует, Вы должны проанализировать проект исполняемого в это время запроса. Убедитесь, что в запросе индексы используются оптимальным образом. Возможны случаи, когда неумело построенный запрос не использует или не оптимально использует существующий индекс.
Запрос может хорошо кэшироваться но, в то же время, перегружать систему ввода - вывода (I/O), что отвлекает большое количество циклов CPU.
Это может говорить о том, что при проектировании таблицы индекс был задуман не оптимально. Если проект запроса оптимален, можно решить проблему за счёт масштабирования, например, добавить процессоры или установить более производительный процессор. Естественно, добавлять процессоры следует только в том случае, если Ваш объe:м ОЗУ достаточно велик, чтобы удовлетворить запросы SQL сервера.
Напротив, если "% Processor Time" постоянно показывает очень низкую утилизацию CPU, это, как правило, говорит о наличии проблем. Вариант, когда сервер чрезвычайно избыточен для решения задач СУБД, в данной статье не рассматривается. Низкая утилизация возможна из-за ограничений в конфигурации SQL сервера (например, используются значения по умолчанию, когда требуется их увеличение) или проблема кроется в Вашем приложении прикладной задачи.

Процессор: "% Privileged Time" - удобен для определения чрезмерной загрузки I/O. Если средне значение превышает 20%, а "% Processor Time"- существенно ниже 80 %, это говорит о том, что SQL Server чересчур сильно утилизирует систему I/O. Вам необходимо проанализировать проект базы данных, загрузку RAID контроллера и сетевой платы. Существенное влияние на "% Privileged Time" могут оказывать и работающие параллельно с SQL сервером процессы или сервисы, в том случае, когда сервер используется не только для обслуживания СУБД. Одним из распространe:нных вариантов решения роблемы высокой утилизации I/O является размещение tempdb в ОЗУ.

Система: "Processor Queue" - предназначен для диагностики очередей процессоров. Если его значение больше чем 2 значит, что CPU работает с перегрузкой. Очевидно, что для решения этой проблемы необходимы дополнительные процессорные мощности.

Система: "Context Switches/sec" - переключение контекста, когда NT или SQL Server переключают обслуживание процессором с одного потока на другой, что вызывает всплеск утилизации CPU. Если при этом "Processor Queue" > 2-х, постарайтесь изменить число потоков, используемых SQL сервером.

Процесс: "Thread Count" - число активных потоков. Значение этого счётчика совместно с "Context Switches/sec" можно использовать для оптимального конфигурирования SQL сервера, чтобы снизить чрезмерную утилизацию CPU.

Процесс: "Virtual Bytes" - позволяет определить, сколько памяти использует SQL сервер и какие приложения используют её недостаточно эффективно; процесс: "Working Set" - объe:м памяти используемый процессом. Изменение конфигурационных настроек SQL сервера после анализа этих счe:тчиков позволит оптимизировать распределение памяти между сервером баз данных, операционной системой и другими приложениями сервера.

SQLServer: "Cache Hit Ratio" - для хорошо сбалансированных приложений число попаданий в кэш должно стремиться к 100%. Часто, достижение высокого уровня попадания в кэш достигают просто увеличением ОЗУ. Боле тонко регулировать кэширование можно контролируя 1081 trace flag, добиваясь, что бы страницы индексов оставались в кэше данных дольше, чем страницы данных.

[В начало]

Настройка конфигурационного параметра SQL Server 7.0: "Max Async I/O"

Как правило, значение по умолчанию параметра Max Async I/O достаточно только для дисковых подсистем нижнего класса. Для более продвинутых RAID - контроллеров с очень высокой пропускной способностью и обслуживающих большое количество дисков этого может оказаться недостаточно или просто возможности системы будут сдерживаться.
Исключение составляет случай использования в качестве операционной системы Windows 95/98, которая просто не поддерживает асинхронный ввод - вывод. Оптимальный выбор значения Max Async I/O позволит серверу полностью отработать Checkpoint, до его следующего цикла и, при этом, не помешает выполнению параллельно исполняемых процессов/потоков.
Microsoft предлагает следующее эмпирическое правило для установки
максимального значения Max Async I/O, если Вы используете RAIDE с большим количеством дисков: "Умножьте число физических дисков, доступных для одновременного ввода/вывода на 2 или на 3, и полученное значение присвойте параметру Max Async I/O".
После этого, наблюдайте средствами Performance monitor или Microsoft Management Console поведением дисковой подсистемы и очередей.
Следите, что бы Checkpoint не монополизировал всю ширину, которая обслуживает дисковую подсистему.

[В начало]

Мониторинг производительности сервера баз данных с помощью SQL Server Profiler

(По материалам статьи Maxim Smirnov на swynk.com «Monitoring Performance With SQL Server Profiler»)

Как пишет Максим, контроль исполнения хранимых процедур и производительности баз данных может помочь Вам прогнозировать на ранних стадиях появление возможных проблем с утилизацией ресурсов системы.

Обычно, анализируя простые счётчики (например, продолжительность исполнения процедур и количество чтений, выполненных ядром базы данных), можно в достаточной степени идентифицировать процедуры или запросы, которые создают чрезмерную перегрузку. Как правило, это случается из-за возможных алгоритмических ошибок в коде, не продуманности проекта базы данных, неправильной стратегии индексации, и т.д.

Одним из эффективных инструментов анализа работы сервера баз данных является SQL PROFILER. Основным его преимуществом является возможность сохранения собранной в процессе трассировки информации в специально созданных администраторам таблицах базы данных. Кроме того, этот инструмент DBA имеет простой, дружественный интерфейс.

[В начало]

Установка трассировки в SQL PROFILER

Запустите SQL PROFILER, и в пункте меню FILE выберите NEW, а затем TRACE. Введите информацию о SQL сервере, который Вы хотите исследовать. Введите имя сервера, логин и пароль. В появившейся форме введите название новому заданию для трассировки, например TRACE1. Для опции "Save to table" - Вы должны указать базу данных и таблицу в которую Вы хотите сохранять собранную информацию. Очень хорошая идея, использовать отдельный SQL сервер (например, настольную версию), чтобы избегать конкуренции за ресурсы между последовательной записью данных трассировки в таблицу и другими процессами сервера баз данных.

В настройках для таблицы результатов трассировки (EVENTS) лучше удалить все заданные по умолчанию счётчики и затем выбирать всё, что относится к хранимым процедурам и запросам TSQL и любым другим дополнительным событиям, которые Вас интересуют.

В настройках фильтров задают параметр OBJECTID для дерева и флаг проверки "Exclude system objects". После этого можно вернуться в основную форму и нажать кнопку RUN. С этого времени SQL PROFILER начнёт собирать информацию обо всех процедурах, исполняемых сервером баз данных. Процесс трассировки можно оставить запущенным на несколько часов, в течение обычной активности пользователей. После этого, Вы готовы к анализу данных трассировки.

[В начало]

Анализ Данных

Максим предлагает, в первую очередь, обратить внимание на два счётчика: READS и DURATIOIN. В листинге трассировщика будет содержаться информация по каждой завершённой процедуре или запросу наряду с id пользователей и другими параметрами.

Перед составлением запросов к таблице данных трассировки (TRACE1), Максим предлагает создать два индекса для полей DURATION и READS. Это существенно ускорит анализ.

CREATE NONCLUSTERED INDEX IND_TRACE_1 ON dbo.TRACE1(Duration)
GO

CREATE NONCLUSTERED INDEX IND_TRACE_2 ON dbo.TRACE1(Reads)
GO

Первое, что Вас может заинтересовать в работе сервера, это наиболее длительные в исполнении процедуры и запросы. Следующий запрос выводит 20 процедур, которые выполняются дольше всех:

SELECT * FROM TRACE WHERE Duration IN
(SELECT DISTINCT TOP 20 Duration
FROM TRACE ORDER BY Duration DESC)

Чтобы понять, почему процедура исполняется так долго, нужно анализировать параметры для READS. Когда текущая величина READS не высока, вероятно предположить, что требуемые ресурсы (например таблицы или представления) были заблокированы другим процессом. Это указывает на возможные проблемы блокировок, и Вы можете искать процедуры, которые в это время используют те же самые объекты.

Высокое значение READS может указывать на сканирование таблиц или на не оптимальные индексы. Обычно, нужно добиваться, что бы параметр READS был настолько низким, насколько это возможно получить (при отсутствии существенного влияния блокировок), потому что задачи ввода/вывода являются самыми медленными в исполнении системой.

Перетащите долго выполняемый запрос в Query Analyzer и с помощью Плана Выполнения запроса определите, какие таблицы сканируются или какие индексы используются. Простого сканирования можно избежать, если применить надлежащий индекс к полям, участвующим в предложении WHERE или объединении. Просмотр индекса исполняется намного быстрее чем сканирование таблицы (для этого их и придумали). Часто, для таблиц создаётся составной индекс, и, если поля, используемые в WHERE или объединении, не входят ни в один из существующих индексов, можно создать дополнительные, не составные индексы для этих столбцов, что может существенно снизить READS и повысить эффективность исполнения запроса.

Задачи, которые используют большие массивы данных (высокий READS) но не исполняются в разумные сроки, можно найти с помощью следующего запроса:

SELECT * FROM TRACE WHERE Reads IN
(SELECT DISTINCT TOP 20 Reads
FROM TRACE ORDER BY Duration DESC)

В случае прямого сканирования таблиц, также можно использовать аналогичные запросы к таблице результатов трассировки.

[В начало]

Снижение интенсивности операций ввода-вывода

По материалам сообщения John Savill на:
http://www.ntfaq.com/Articles/Index.cfm?ArticleID=14921

Если Ваш сервер баз данных чересчур интенсивно использует I/O, можно изменить значение параметра операционной системы I/O Page Lock Limit, который может увеличить эффективную норму чтения/записи данных операционной системой на жесткий диски.
Сначала, выполните эталонный тест I/O для вашей обычной загрузки сервера. Затем, в regedit.exe откройте ключ:

HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement\IoPageLockLimit

Смысл Ваших действий состоит в пошаговом подборе значений этого ключа до наиболее оптимального, с точки зрения изменений результатов эталонного тестирования, значения.
В этом ключе операционная система считывает максимальное число байт, которые она можете использовать для операций I/O. По умолчанию установлено значение 0, которому соответствует 512КБ. Увеличивайте это значение по шагам, каждый раз прибавляя по 512КБ (например: "512", "1024", и т.д.), и выполняйте после каждого изменения эталонное тестирование вашей системы. Увеличивать этот параметр есть смысл только до тех пор, пока вы наблюдаете увеличение пропускной способности операций ввода – вывода, которое может проявляться в снижении временных затрат на стандартные дисковые операции. Когда Вы перестанете наблюдать существенное улучшение, возвратитесь в редактор реестра и уничтожьте последнее приращение.

Предостережение: Есть ограничение на максимальный размер значения этого ключа. Если Вы имеете 16 МБ ОЗУ, не устанавливайте IoPageLockLimit более 2048 байт; для 32МБ ОЗУ, не превышайте 4096 байт, и так далее.

[В начало]

“Тюнинг” – для Windows NT, обеспечивающий более эффективную работу MS SQL Server

По материалам статьи Sergey A. Vartanyan на swink.com “Tips on tuning the Windows NT server”.

Как DBA или разработчик, Вы должны знать некоторые общие аспекты конфигурирования системы Windows NT для повышения эффективности работы SQL сервера. В этой статье, Сергей предлагает некоторые настройки Windows NT, на котором предполагается запускать MS SQL Server:

Если у Вас ОЗУ большого размера, Вы можете запретить Windows NT сбрасывать страницы в pagefile. Для этого, с помощью regedit.exe, установите значение ключа

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SessionManager\MemoryManagement

в единицу. (Замечание Автора: лично я этот ключ трогать боюсь…)

Создать на каждом отдельном физическом дисковом массиве свой page file. Исключение может составить только тот диск, где расположен системный каталог Windows NT.

Установите для сервера опцию "Maximize Throughput for Network Applications":
Start => Settings => Control Panel => Network => Services
Выберите Server и потом Properties.
Из списка выберите последний пункт "Maximize Throughput for Network Applications".

Вы можете повысить производительность отключив учёт даты последнего доступа к файлам. Для этого нужно установить в единицу ключ:
HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisableLastAccessUpdate

Используйте минимальный набор сетевых протоколов. Например, только TCP/IP. Если Вы используете несколько протоколов, определите наиболее часто используемый, и поместите его на первое место в Bindings листе.

Используйте как можно меньшее количество счётчиков в Performance Monitor.

Не используйте Open GL хранители экрана, потому что они используют очень много системных ресурсов.

При настройке Audit Policy, добавляйте новые проверки очень осторожно. Не проверяйте "File and Objects Access" и "Process Tracking", т.к. это может привести к почти полной потере доступности сервера.

Укажите серверу запускать приложения с консоли с тем же приоритетом, что и background applications
Start => Settings => Control Panel => System => "Performance"
Далее с помощью клавиши табуляции перейдите к нужному пункту и установите "Application Performance" в "None".



загрузка наград ...
 
asasinnДата: Среда, 12.01.2011, 19:59 | Сообщение # 6
asasinn
Группа: Заблокированные
Сообщений: 453
Награды: 49
Репутация: -10000
Статус: Offline
Люди, учитесь пользоваться поисковиком


загрузка наград ...
 
LestatДата: Четверг, 13.01.2011, 00:00 | Сообщение # 7
Lestat
Группа: Постоянный
Сообщений: 22
Награды: 1
Репутация: 0
Статус: Offline
eek wacko сколько текста и все не по теме... может я плохо объяснил... база тут не причем - мне надо подконектится к игровому серверу и его забрасывать пакетами....
загрузка наград ...
 
asasinnДата: Четверг, 13.01.2011, 07:55 | Сообщение # 8
asasinn
Группа: Заблокированные
Сообщений: 453
Награды: 49
Репутация: -10000
Статус: Offline
Даже не знаю. Может за ДДосить самого себя?


загрузка наград ...
 
La2bluffДата: Четверг, 13.01.2011, 13:37 | Сообщение # 9
La2bluff
Группа: Постоянный
Сообщений: 240
Награды: 17
Репутация: 53
Статус: Offline
Попробуй server attack

Почему нельзя разводить пингвинов в холодильнике???
загрузка наград ...
 
LestatДата: Пятница, 14.01.2011, 00:54 | Сообщение # 10
Lestat
Группа: Постоянный
Сообщений: 22
Награды: 1
Репутация: 0
Статус: Offline
server attack, как я понял, просто валит запросами сервер... я ищу больше бота, который бы зашел на сервер и, например, бегал там... причем очень часто кликая...
загрузка наград ...
 
ОвощДата: Пятница, 14.01.2011, 01:41 | Сообщение # 11
Овощ
Группа: Администратор
Сообщений: 2491
Награды: 162
Репутация: 5547
Статус: Offline
l2phx попробуй. поставь какой-нибудь пакет и укажи частоту отправки. может быть тебе это нужно.
пакеты можно найти в интернете


Вёрстка макетов и создание клан сайтов на uCoz, STRESS - в ICQ
Хлеба и зрелищ

загрузка наград ...
 
LestatДата: Суббота, 15.01.2011, 00:31 | Сообщение # 12
Lestat
Группа: Постоянный
Сообщений: 22
Награды: 1
Репутация: 0
Статус: Offline
спасибо, что-то такое я искал
загрузка наград ...
 
Форум L2edit.Ru » Lineage 2 » Java сервер » Протестировать производительность сервера
  • Страница 1 из 1
  • 1
Поиск: