List:General Discussion« Previous MessageNext Message »
From:BAUMEISTER Alexandre Date:April 28 1999 8:53am
Subject:Reaction: Compression with CLIENT_COMPRESS protocol !!!
View as plain text  
Bonjour,

MW> MySQL does use the gzip algorithm for the compression.  The difference
MW> is that MYSQL does a separate gzip for each package to keep things
MW> safe.

MW> You can get better compression simply by increasing the
MW> 'max_allowed_packet' variable in your client.

  In  fact, most of the file which are uploaded to the Mysql table are
  about  45ko.  The  biggest  are  about  400ko.  And  I  found on the
  documentation :

  "The client's default maximum is 24M, but the default maximum in the
  server is 1M."

  So  I  suppose  that  all  the file is sent in one time and that the
  compression should already by maximum isn't it ?

MW> Have you checked that client/server protocol is really compressed?
MW> (In other words:  Are you sure your server and client both are
MW> compiled with compression ?)

  Server  compiled  with  compression  ?  I  didn't see that option in
  ./configure --help .

  Both  the  server  and the client are 3.22.21. I thought compression
  was   by  default  allowed  by  server  and  on  the  demand  using
  CLIENT_COMPRESS with mysql_real_connect() in the client. Isn't it ?

MW> MySQL inserts the rows at the same time it gets them;  In other words,
MW> your other clients are locked during the whole transfer.

  Waou.  That  sounds  really horrible for my solution. In fact I have
  about  4  little  programs  which are continuously updating a remote
  table  with  some  quotation updates (about once per minute for each
  program  taking the quotations from little text files which are well
  designed  for  LOAD  DATA  command). And on the server side, we have
  many  web  sites  which are querying the Mysql quotation database (a
  lot  of  select  with joins ...). This solution can't suffer of a to
  long lock delay while inserting the updates.

  Isn't  there  a  simple  way  to  add an option which would tell the
  server to do the insert into the table only once it has received all
  the data (for LOAD DATA _LOCAL_) ?

  If  for  example  someone  uses LOAD DATA LOCAL in order to update a
  remote table with large files on a slow network, the delay while all
  SELECT on this table will be locked may be a REAL problem. Don't you
  agree ?

  On    my   own,   yesterday  I  reached  for  the  first  time  the
  max_connections   of   256  which  I configured on the server and  I
  was   really   surprised.  But now I know why ! with the table being
  SELECT locked for 3-4 seconds due to the network transfer delay, the
  number of clients locked is rapidly increasing.

  Yours,
  Alex


Thread
Compression with CLIENT_COMPRESS protocol ?BAUMEISTER Alexandre27 Apr
  • Re: Compression with CLIENT_COMPRESS protocol ?unknown27 Apr
    • Re: Compression with CLIENT_COMPRESS protocol ?Paul DuBois27 Apr
      • Re: Compression with CLIENT_COMPRESS protocol ?unknown27 Apr
    • Re: Compression with CLIENT_COMPRESS protocol ?Michael Widenius28 Apr
  • Compression with CLIENT_COMPRESS protocol ?Michael Widenius28 Apr
    • Reaction: Compression with CLIENT_COMPRESS protocol !!!BAUMEISTER Alexandre28 Apr
      • Reaction: Compression with CLIENT_COMPRESS protocol !!!Michael Widenius28 Apr
        • Re: Reaction: Compression with CLIENT_COMPRESS protocol !!!BAUMEISTER Alexandre28 Apr
        • Stupid question!!Ryan28 Apr
          • Re: Stupid question!!Darrell Shifflett28 Apr
            • RE: Stupid question!!Ryan28 Apr
Re: Compression with CLIENT_COMPRESS protocol ?Fred Lindberg27 Apr