Your message dated Mon, 09 May 2016 18:05:08 +0000
with message-id <[email protected]>
and subject line Bug#821504: Removed package(s) from unstable
has caused the Debian Bug report #160909,
regarding htcheck: parallel checking mode requested
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
160909: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=160909
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: htcheck
Version: 1:1.1-1
Severity: wishlist
The LoLL team runs htcheck once per week to find any link problems in the
LoLL site (Loads of Linux Links at loll.sourceforge.net/linux/links). This
is a large site with ~3500 links which would quickly become unmanageable if
we didn't have a fine tool like htcheck to help keep the links on our site
relatively clean. However, one drawback of htcheck is it takes something
like 3 hours (or ~3 seconds per site) to trawl all the way through the URL's
on the LoLL site.
This time seems quite excessive since neither bandwidth or cpu are being
used appreciably during the course of a report period. What I believe is
going on is htcheck spends most of its time waiting for a response from web
servers that have several seconds of latency built in to responding to a
request.
If several seconds latency per site is the problem, then I suggest the whole
htcheck process could be enormously speeded up if htcheck did its queries in
a parallel manner. Suppose htcheck initiated checks for N websites at the
start, and each time a transaction with a website was completed and stored
in the database another transaction were started. Then you should reduce the
perceived latency by a factor of N, and the whole report would finish N
times faster. Of course this rule would begin to fail for N large enough so
that bandwidth or your cpu speed became the limiting factor, but I don't
think htcheck is anywhere near that limit for the current N=1. Thus, you
might get a large increase in speed out of this idea which would be most
helpful for htchecking relatively large sites like the LoLL one.
Alan
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux starling 2.4.17starling.3 #1 Mon Feb 11 08:22:51 PST 2002 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages htcheck depends on:
ii libc6 2.2.5-14.1 GNU C Library: Shared libraries an
ii libmysqlclient10 3.23.49-8 mysql database client library
ii libstdc++2.10-glibc2.2 1:2.95.4-7 The GNU stdc++ library
ii zlib1g 1:1.1.4-1 compression library - runtime
--- End Message ---
--- Begin Message ---
Version: 1:2.0.0~rc1-2+rm
Dear submitter,
as the package htcheck has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see https://bugs.debian.org/821504
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)
--- End Message ---
