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/000295.html | |
| download | nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.tar.xz nevrax-website-self-hostable-0ea5fc66924303d1bf73ba283a383e2aadee02f2.zip | |
Initial commit
Diffstat (limited to 'pipermail/nel/2001-February/000295.html')
| -rw-r--r-- | pipermail/nel/2001-February/000295.html | 68 |
1 files changed, 68 insertions, 0 deletions
diff --git a/pipermail/nel/2001-February/000295.html b/pipermail/nel/2001-February/000295.html new file mode 100644 index 00000000..e4127c7d --- /dev/null +++ b/pipermail/nel/2001-February/000295.html @@ -0,0 +1,68 @@ +<!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:cblt%40cblt.org"> + <LINK REL="Previous" HREF="000294.html"> + <LINK REL="Next" HREF="000297.html"> + </HEAD> + <BODY BGCOLOR="#ffffff"> + <H1>[Nel] NeL Network Engine</H1> + <B>Nicolas Hognon</B> + <A HREF="mailto:cblt%40cblt.org" + TITLE="[Nel] NeL Network Engine">cblt@cblt.org</A><BR> + <I>Wed, 28 Feb 2001 15:10:53 +0100</I> + <P><UL> + <LI> Previous message: <A HREF="000294.html">[Nel] NeL Network Engine</A></li> + <LI> Next message: <A HREF="000297.html">[Nel] NeL Network Engine</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#295">[ date ]</a> + <a href="thread.html#295">[ thread ]</a> + <a href="subject.html#295">[ subject ]</a> + <a href="author.html#295">[ author ]</a> + </LI> + </UL> + <HR> +<!--beginarticle--> +<PRE>><i> Looking at Apache or Samba projects, it seems that a good compromise is to +</I>><i> set a 'maximum client requests by thread' and spawns threads accordingly. +</I>><i> Apache uses process forking and memory sharing, but the design remains the +</I>><i> same. You then just tune this max_request_by_thread for each OS, say 1 for +</I>><i> Solaris which is said thread-efficient, 10 for Linux ? Just a hint ... +</I> +ok this is a solution +but as i said in my last mail the problem +is how managing more than one socket per thread efficiently ? + +under windows i know other solution than select / poll but under +unixes i don't know other solutions. + +some one knows other one ? + +-- +Nicolas Hognon +<A HREF="mailto:nicolash@virtools.com">nicolash@virtools.com</A> + +Virtools - The Behavior Company +Tel. (+33) 1 42 71 46 86 / Fax. (+33) 1 42 71 86 53 +<A HREF="http://www.virtools.com/">http://www.virtools.com/</A> + + +</pre> + + +<!--endarticle--> + <HR> + <P><UL> + <!--threads--> + <LI> Previous message: <A HREF="000294.html">[Nel] NeL Network Engine</A></li> + <LI> Next message: <A HREF="000297.html">[Nel] NeL Network Engine</A></li> + <LI> <B>Messages sorted by:</B> + <a href="date.html#295">[ date ]</a> + <a href="thread.html#295">[ thread ]</a> + <a href="subject.html#295">[ subject ]</a> + <a href="author.html#295">[ author ]</a> + </LI> + </UL> +</body></html> |