On Thu, Apr 16, 2015 at 10:43 AM, Hannes Magnusson <hannes.magnus...@gmail.com> wrote: > On Thu, Apr 16, 2015 at 10:14 AM, Ferenc Kovacs <tyr...@gmail.com> wrote: >> >> >> On Thu, Apr 16, 2015 at 5:29 PM, Pierre Joye <pierre....@gmail.com> wrote: >>> >>> On Thu, Apr 16, 2015 at 10:02 PM, Ferenc Kovacs <tyr...@gmail.com> wrote: >>> > >>> > >>> >> >>> >> As of the uncompressed data, I see something like less 0.01% of the >>> >> requests actually requesting non compressed archives, the box he uses >>> >> must on of the 3-4. We are in the 21st century and compressed output >>> >> is quite a standard. It makes the server serves faster too as we rely >>> >> on X-SendFile, as I reportedly said on this list during the migration, >>> >> and ask for tests. >>> > >>> > >>> > hi Pierre, >>> > >>> > where do you get this 0.01%? >>> > from a quick look: >>> > root@pecl:~# grep '.tar.gz ' /var/log/apache2/pecl.php.net-access.log|wc >>> > -l >>> > 242 >>> > root@pecl:~# grep '.tar ' /var/log/apache2/pecl.php.net-access.log|wc -l >>> > 1350 >>> > so the majority of the download requests are looking for the >>> > uncompressed >>> > tar file, which is doesn't work now thanks to your changes. >>> > is there another metric or something that I'm missing? >>> > it seems that this is something which we should fix/restore even if it >>> > costs >>> > us a bit more cpu. >>> >>> I check with the whole old log, was low. >>> >>> No need to change the download code. >>> >>> I will run a script to store both tgz and tar, easier and better. And >>> changing the release code to save the uncompressed archive as well. >>> Way better than what we had before. And if we like to be the only one >>> to provide uncompressed download of our releases, why not, I do not >>> mind much ;-) >>> >>> But that's actually not a bug as of now, the SSL thing Hannes was >>> experiencing is what I was asking for, it is what I wonder what >>> happened to get the installer requesting SSL: in the 1st place and how >>> it ends up like that and failed. But Hannes seems to do not care, so I >>> will simply enable SSL again and that should be it. >>> >>> Cheers, >>> -- >>> Pierre >>> >>> @pierrejoye | http://www.libgd.org >> >> >> >> ok, after discussing with Pierre I gunzipped the release tarballs so now >> they are there, Pierre will update the release upload/delete code so that we >> also store/delete the .tar files so they can be also served via sendfile. > > $ sudo pecl install memcached > Could not download from "http://pecl.php.net/get/memcached-2.2.0.tar";, > cannot download "pecl/memcached" (File > http://pecl.php.net:80/get/memcached-2.2.0.tar not valid (received: > HTTP/1.0 404 Not Found > )) > Error: cannot download "pecl/memcached" > Download failed > install failed > > > Still doesn't work... Maybe peclweb hasn't updated yet? > > >> about the ssl related changes: we should look into the cause and there is a >> chance that we will also need to fix/update the pear installer. > > > The fix would need to be BC though -- prioritize https, and issue > warning on failure. You cannot just remove http downloads without > announcing it. > > You have to be able to install pecl extensions with minimal PHP install: > ./configure --disable-all --enable-cli && pecl install foobar > > heck, currently even standard PHP-out-of-the-box ./configure is good > enough to install pecl extension because it doesn't even enable zlib > and openssl by default.
Whopsy, typo alert -- that is supposed to say "currently even standard PHP is _NOT_ good enough" :) Before the recent changes during the server move, everything worked just fine. Thanks for looking at this Martin & Ferenc! -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
