Hello, mihailik!
m> Кажется, единственным минусом ThreadPool является "зашитое" количество m> потоков в пуле.
Ну это не проблема.......
// Mike Woodring
// http://staff.develop.com/woodring
//using System.Runtime.InteropServices;
// To access the thread pool, either do this:
//
// ICorThreadPool tp = (ICorThreadPool)new CorRuntimeHost();
//
// (the cast is required since interop shims like CorRuntimeHost
// cannot have methods, which would be required if it were to
// advertise that it implements ICorThreadPool statically).
//
// or this (a little cleaner):
//
// ICorThreadPool tp = CLRThreadPool.Controller;
//
//
[
// CLSID_CorRuntimeHost from MSCOREE.DLL
Guid("CB2F6723-AB3A-11D2-9C40-00C04FA30A3E"),
ComImport
]
public class CorRuntimeHost
{
}
public class CLRThreadPool
{
public static ICorThreadPool Controller
{
get { return thePool; }
}
private static ICorThreadPool thePool = (ICorThreadPool)new CorRuntimeHost();
}
// The ICorThreadpool interface is documented (prototypes only) in
// mscoree.h, but is not made available from mscoree.tlb. So the
// following interop stub lets us get our hands on the interface
// in order to query/control the CLR-managed thread pool.
//
// Because I'm only interested in adjusting the thread pool
// configuration, most of the members are actually invalid and
// cannot be called in their current form.
//
[
// IID_ICorThreadpool
Guid("84680D3A-B2C1-46e8-ACC2-DBC0A359159A"),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)
]
public interface ICorThreadPool
{
void RegisterWaitForSingleObject(); // DO NOT CALL - INCORRECT STACK FRAMEvoid UnregisterWait(); // DO NOT CALL - INCORRECT STACK FRAMEvoid QueueUserWorkItem(); // DO NOT CALL - INCORRECT STACK FRAMEvoid CreateTimer(); // DO NOT CALL - INCORRECT STACK FRAMEvoid ChangeTimer(); // DO NOT CALL - INCORRECT STACK FRAMEvoid DeleteTimer(); // DO NOT CALL - INCORRECT STACK FRAMEvoid BindIoCompletionCallback(); // DO NOT CALL - INCORRECT STACK FRAMEvoid CallOrQueueUserWorkItem(); // DO NOT CALL - INCORRECT STACK FRAMEvoid SetMaxThreads( uint MaxWorkerThreads, uint MaxIOCompletionThreads );
void GetMaxThreads( out uint MaxWorkerThreads, out uint MaxIOCompletionThreads );
void GetAvailableThreads( out uint AvailableWorkerThreads, out uint AvailableIOCompletionThreads );
}
Posted via RSDN NNTP Server 1.8 beta
Re[3]: Server на C#. Эффективность и быстродействие.
Я реализовал ориентировучную моель сервера на C#. Интересует насколько быстрее(эффективнее) работает аналогичная(параметры описаны ниже) реализация на чистом C++ под win и под linux(unix). Параметры машины не беруться во внимание, то есть имеется ввиду сама реализация. Вообще насколько целесообразно использовать сервер C# для поставленной задачи.
Параметры реализации:
— мультиплексный ассинхронный;
— протокол TCP;
— неблокируемые сокеты;
— для каждого клиента создается нить;
— синхронизациия обрабатываемых запросов с помощью критических секций;
— размер запросов от клиента менее одного килобайта;
— частота поступления запросов варьируется — пик приходится на момент подключения, далее данные передаются прмемерно одинаковыъ размеров;
— [другие параметры могу описать если возникнут вопросы].
Еще раз подчеркну, меня интересует целесообразность с точки бытсродействия и эффективности работа реализованного сервера на C#. А так же смысл переписывания модели согласно вышеописанным требованиям.
__A>Интересует насколько быстрее(эффективнее) работает аналогичная(параметры описаны ниже) реализация на чистом C++ под win и под linux(unix).
под unix пока на .Net реально писать нельзя, нет надежной платформы
__A>Еще раз подчеркну, меня интересует целесообразность с точки бытсродействия и эффективности работа реализованного сервера на C#. А так же смысл переписывания модели согласно вышеописанным требованиям.
у нас примерно такой сервер работает и замечательно
тут главное нагрузка — если у тебя предпологается что-то сверхестественное, то можно ли это масштабировать на несколько машин? зависит уже от того, что этот сервер делает
Re[2]: Server на C#. Эффективность и быстродействие.
Здравствуйте, Banch, Вы писали:
__A>>Еще раз подчеркну, меня интересует целесообразность с точки бытсродействия и эффективности работа реализованного сервера на C#. А так же смысл переписывания модели согласно вышеописанным требованиям.
B>у нас примерно такой сервер работает и замечательно
Это интересно, а не мог бы ты, ответить на несколько вопросов, в плане эксплуатации вашего сервера:
— какое предельное число запросов он обрататывал;
— какое кол-во пользователей в среднем "висит" на нем;
— какой траффик проходит через него и нет ли потерь или отказов.
B>тут главное нагрузка — если у тебя предпологается что-то сверхестественное, то можно ли это масштабировать на несколько машин? зависит уже от того, что этот сервер делает
Ничего такого сверестественного:
— предполагается от 500 до 1000-1300 клиентов;
— частоту запросов точно сказать не могу зависит от активности клиентов, но максимум — на момент подключения, далее более менее ровный поток, при чем каждый пользователь дожидается ответа от сервера и не может послать сразу несколько запросов не получив ответ на предущий;
Здравствуйте, mihailik, Вы писали:
__A>>- для каждого клиента создается нить
M>В дотнете есть ThreadPool, который в большинстве случаев намного быстрее создания-убийства потоков.
M>Кажется, единственным минусом ThreadPool является "зашитое" количество потоков в пуле.
Ну это не совсем минус, т.к. позволяет более эффективно использовать процессор (ы), уменьшая затраты на переключения потоков. Где то приводились тесты, что последовательное выполнение процедур в 2 раза занимает меньше времени чем при паралельном. И при ThreadPool получается симбиоз последовательного и паралельного. Тот же SQL сервер так или иначе использует ThreadPool.
и солнце б утром не вставало, когда бы не было меня
Re[3]: Server на C#. Эффективность и быстродействие.
M>>Кажется, единственным минусом ThreadPool является "зашитое" количество потоков в пуле. S> Ну это не совсем минус, т.к. позволяет более эффективно использовать процессор (ы)
Чего-то я сегодня торможу?
... << RSDN@Home 1.1.3 beta 1 >>
Re[4]: Server на C#. Эффективность и быстродействие.
Здравствуйте, mihailik, Вы писали:
M>>>Кажется, единственным минусом ThreadPool является "зашитое" количество потоков в пуле. S>> Ну это не совсем минус, т.к. позволяет более эффективно использовать процессор (ы)
M>Чего-то я сегодня торможу?
Помоему не такое оно уж зашитое
public static bool SetMinThreads(int workerThreads, int completionPortThreads);
Если удастся
и солнце б утром не вставало, когда бы не было меня
Re[5]: Server на C#. Эффективность и быстродействие.
Впрочем, я до сих пор немного не уверен, работает ли это на уровне AppDomain или всего процесса. Где-то в MSDN говорилось, что параметр касается всего процесса.
В общем, ThreadPool рулит, но его настройка требует напрягов.
... << RSDN@Home 1.1.3 beta 1 >>
Re[6]: Server на C#. Эффективность и быстродействие.
Здравствуйте, mihailik, Вы писали:
M>В общем, ThreadPool рулит, но его настройка требует напрягов.
M>Впрочем, я до сих пор немного не уверен, работает ли это на уровне AppDomain или всего M>процесса. Где-то в MSDN говорилось, что параметр касается всего процесса
public static bool SetMinThreads(int workerThreads, int completionPortThreads)
{ return ThreadPool.SetMinThreadsNative(workerThreads, completionPortThreads);
}
Вообще весь этот ThreadPool нативный а значит процесса, и а может касается всей ОС для всех процессов, но это ИМХО.
и солнце б утром не вставало, когда бы не было меня
Re[3]: Server на C#. Эффективность и быстродействие.
B>>у нас примерно такой сервер работает и замечательно __A>Это интересно, а не мог бы ты, ответить на несколько вопросов, в плане эксплуатации вашего сервера: __A> — какое предельное число запросов он обрататывал; __A> — какое кол-во пользователей в среднем "висит" на нем; __A> — какой траффик проходит через него и нет ли потерь или отказов.
честно говоря тестов по нагрузке не проводили
__A>Ничего такого сверестественного: __A>- предполагается от 500 до 1000-1300 клиентов; __A>- частоту запросов точно сказать не могу зависит от активности клиентов, но максимум — на момент подключения, далее более менее ровный поток, при чем каждый пользователь дожидается ответа от сервера и не может послать сразу несколько запросов не получив ответ на предущий;
если несколько сотен клиентов одновременно будут ломиться к одной машине, то она наверняка не сможет всех обслужить за должное время, так что думаю стоит заранее подумать о масштабируемости, чтобы какой-нть роутер стоял и раскидывал запросы на несколько серверов
тогда в случае нехватки ресурсов на одной машине всегда можно будет сделать несколько
Re[4]: Server на C#. Эффективность и быстродействие.
