diff options
| author | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
|---|---|---|
| committer | neodarz <neodarz@neodarz.net> | 2018-08-11 20:21:34 +0200 |
| commit | 0ea5fc66924303d1bf73ba283a383e2aadee02f2 (patch) | |
| tree | 2568e71a7ccc44ec23b8bb3f0ff97fb6bf2ed709 /pipermail/nel/2001-February/000294.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to 'pipermail/nel/2001-February/000294.html')
| -rw-r--r-- | pipermail/nel/2001-February/000294.html | 62 |
1 files changed, 62 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000294.html b/pipermail/nel/2001-February/000294.html new file mode 100644 index 00000000..5bb46c8b --- /dev/null +++ b/pipermail/nel/2001-February/000294.html @@ -0,0 +1,62 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> +<HTML> + <HEAD> + <TITLE> [Nel] NeL Network Engine</TITLE> + <LINK REL="Index" HREF="index.html" > + <LINK REL="made" HREF="mailto:v.caron%40zerodeux.net"> + <LINK REL="Previous" HREF="000291.html"> + <LINK REL="Next" HREF="000295.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Nel] NeL Network Engine</H1> + <B>Vincent Caron</B> + <A HREF="mailto:v.caron%40zerodeux.net" + TITLE="[Nel] NeL Network Engine">v.caron@zerodeux.net</A><BR> + <I>Wed, 28 Feb 2001 15:30:32 +0100</I> + <P><UL> + <LI> Previous message: <A HREF="000291.html">[Nel] NeL Network Engine</A></li> + <LI> Next message: <A HREF="000295.html">[Nel] NeL Network Engine</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#294">[ date ]</a> + <a href="thread.html#294">[ thread ]</a> + <a href="subject.html#294">[ subject ]</a> + <a href="author.html#294">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>Vianney Lecroart wrote: +><i> +</I>><i> What we don't know is the thread number limit after what the system uses too +</I>><i> much CPU. In the linuxthread faq, they +</I>><i> said that an application should not create more than 100 thread. In this +</I>><i> case, we have to forget the solution where each +</I>><i> socket is on a thread and use a blocked receive(). The problem is that +</I>><i> select() is quite slow and if we have only 100 thread, +</I>><i> each thread needs to manage, with a select(), around 50 players and we ll +</I>><i> lost lot of time to create the array for the select() +</I>><i> and check who have wakeup the select(). +</I> +Looking at Apache or Samba projects, it seems that a good compromise is to +set a 'maximum client requests by thread' and spawns threads accordingly. +Apache uses process forking and memory sharing, but the design remains the +same. You then just tune this max_request_by_thread for each OS, say 1 for +Solaris which is said thread-efficient, 10 for Linux ? Just a hint ... + +</pre> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="000291.html">[Nel] NeL Network Engine</A></li> + <LI> Next message: <A HREF="000295.html">[Nel] NeL Network Engine</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#294">[ date ]</a> + <a href="thread.html#294">[ thread ]</a> + <a href="subject.html#294">[ subject ]</a> + <a href="author.html#294">[ author ]</a> + </LI> + </UL> +</body></html> |