[prev in list] [next in list] [prev in thread] [next in thread] 

List:       squid-dev
Subject:    Re: Introduction
From:       "Evgeny Kotsuba" <evgen__k () rambler ! ru>
Date:       2005-04-30 20:14:39
Message-ID: web-157407880 () mail1 ! rambler ! ru
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]