Re: Introduction

From: Evgeny Kotsuba <evgen__k@dont-contact.us>
Date: Sun, 01 May 2005 00:14:39 +0400

On Sat, 30 Apr 2005 16:00:40 +0200
  Serassio Guido <guido.serassio@acmeconsulting.it> wrote:
> Hi Evgeny,
>
> At 13.05 30/04/2005, Evgeny Kotsuba wrote:
>>>I have removed similar things some time ago from the Windows port for
>>>poor performance reasons.
>>I don't understand this. Really call to read/write/sevd/recv is
>>call to a number of system's API calls and one more call get
>>0.0001% performance
>
> Experimental results:
>
> old style: 10 - 15 % CPU usage for a 100 MB file transfer
> new style: 0.1 - 05 % CPU usage for the same transfer
> The CPU was a 1.6 GHz P4
> The test was done using MS Visual Studio C++ 6.0, a very bad C++
>compiler.
> Now the development is made with Visual Studio 2005 Beta 2 (The only
>MS C++ compiler able to compile Squid 3.0 ....)
> Really I don't know if it was a compiler "optimization" problem.
>
>>>But this is not enough, because don't solve the second problem. Here
>>>the solution could be the usage of something like a Squid_Socket
>>>class with all socket calls encapsulation.
>>
>>I am not quite understand problem
>>I have made:
>>class squid_fde wich is analog to filedescriptor
>>and
>>class squid_fdeArray
>>{...
>> squid_fde *fd_table;
>>....
>>extern squid_fdeArray squid_fd_table;
>>with typical usage as squid_fd_table.fd_table[fd] instead of
>>fd_table[fd]
>>
>>usage of squid_fd_table class may be not very efficient, but very
>>convenient so that it is single place for all filedescriptor's
>>operetion. It is possible to have variable number of fds etc.
>
> Not sure to understand: How you find the right socket handle into
>the squid_fd_table ? with a for loop search ?
>
class squid_fde { /* former struct _fde */
    int fh; /* real file handle or socket */
public:
     unsigned int type;
     u_short local_port;
     u_short remote_port;
......
class squid_fdeArray
{
   public:
   int n; /* number of used items in fd_table i.e. analog
of Biggest_FD */
   int nAllocated; /* allocated siseof fd_table */
   int iCurrent; /* current index */
   squid_fde *fd_table; /* */
   int *SocketToIndex;
                       /* array for getting index number on socket */

>>In os/2 there is two limits on socket's number: first is 2048 with so
>>called 16-bit old TCP/IP stack and default 8K with 32-bit TCP/IP
>>stack. But with 32-bit stack there is one more problem: select,
>>macroses FD_XXX, fd_set structure and
>>#pragma pack(4)
>>typedef struct fd_set {
>> u_short fd_count; /* how many are SET? */
>> int fd_array[FD_SETSIZE]; /* an array of SOCKETs */
>>} fd_set;
>>#pragma pack()
>>and it's usage in comm_select.c(pp)
>>
>>Nevertheless this it seems solved
>
> Sorry, but I can't understand this last question.

look at comm_select.c(pp) how fd_set without macros FD_XXX is used.
  It is supposed that fd_set is bitfield that is wrong with
  structure above.

>
> OT: Evgeny, Do you can take a look into this OS/2 bugzilla ?
> http://www.squid-cache.org/bugs/show_bug.cgi?id=1040
>
mmm.. This is for Squid3 ... But I really work only with 2.5

SY,
Evgeny Kotsuba
Received on Sat Apr 30 2005 - 14:14:41 MDT

This archive was generated by hypermail pre-2.1.9 : Sun May 01 2005 - 12:00:06 MDT