{23} Trac comments (3729 matches)

Results (801 - 900 of 3729)

← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 →
Ticket Posixtime Author Newvalue
#535 1283167040000000 rgrp Duplicate of #434
#536 1286376029000000 dread I did this a few weeks ago.
#537 1283325156000000 wwaites See #540 for a story about Varnish. Strongly favouring squid at this juncture.
#537 1288023097000000 dread Can this ticket be updated? Were any tasks listed here done? Anything remaining still planned?
#537 1311178929000000 thejimmyg Consolidation of caching has been moved in ticket #995.
#538 1294412635000000 thejimmyg Rufus, is this something you want to take on or shall we close the ticket as wontfix?
#538 1294414537000000 rgrp We don't use reports any more -- just the query module -- so closing as wontfix.
#539 1303118486000000 thejimmyg Old ticket, not sure exactly what it is referring to, closing.
#540 1283324947000000 wwaites Cut-and-paste from ckan-discuss: I had a look at Varnish and I agree that the configuration language is complicated. In fact by default Varnish disregards cache control headers and in general behaves in a very standards non-compliant way. I have no doubt that it is very fast -- if you are willing to spend the efford to customise its configuration for the exact layout of pages and headers and such that each web site it is going to be used with will use. In other words, there is a large administrative burden. So I decided to change tack and see where the Squid proxy has gotten to in the decade or so since I last met it. Squid is a general purpose caching proxy that can be configured as an http accelerator. The configuration is simple. You tell it where your web servers are for which sites. The web servers make sure to set the cache control headers appropriately. Here are some results from my testing, against http://de.ckan.net/package/list?page=B which is an example of a slow page. Except for the first, which only did 100 requests, the tests were set to 8 simultaneous connections and a total of 1000 requests. {{{ No caching of any kind: Requests per second: 0.44 [#/sec] (mean) Beaker Cache (filesystem): Requests per second: 43.16 [#/sec] (mean) SQUID setting cache control headers correctly: Requests per second: 421.33 [#/sec] (mean) }}} The results are clear. Using the application cache is about 100 times faster than doing nothing. Using squid is about 1000 times faster. (Doing both wouldn't necessarily help very much). I'm sure we could squeeze a bit more performance out of it if we used Varnish, but probably not an order of magnitude and I don't think it is worth the administrative burden. If we set up a production Squid instance (or farm), with a bare minimum of work it can cache for any number of sites, not just CKAN. For the python coders, here's what you have to do to set the headers properly so that squid will cache the page: {{{ del response.headers["Pragma"] del response.headers["Cache-Control"] from time import gmtime, strftime response.headers["Last-Modified"] = strftime("%a, %d %b %Y %H:%M:%S GMT", gmtime()) response.cache_expires(seconds=3600) }}} A further advantage is that the *browsers* will also understand these cache-control headers and do their own caching - just setting them properly without even using Squid should result in some subjective performance improvements. That's all for now, I suggest we dedicate a machine to just running squid, the more RAM the better and big discs are good, and put it between the world and the ckans. Oh, and comb through the controllers setting the headers correctly where appropriate...
#540 1302694845000000 dread Closing - all the suggestions have been implemented: squid instance and cache headers set for high traffic pages.
#541 1294924872000000 wwaites this is implemented with the cookie javascript technique. not so suitable for pages where content is radically differerent depending on the logged in user but for small bits like the logged in status works perfectly well, likewise for edit links.
#542 1283278896000000 wwaites Implemented with: * cset:2bbc186459cb * cset:eba23cc027e5 * cset:e89e0b82b24e * cset:943ed812e237
#543 1311178918000000 thejimmyg Consolidation of caching has been moved in ticket #995.
#544 1291638966000000 rgrp Duplicate of #672
#546 1286896167000000 anonymous [http://www.pokers.li Jeux de poker en ligne]
#546 1286896450000000 anonymous [http://www.bonus-pokers.eu Poker en ligne]
#546 1286896814000000 anonymous [http://www.salle-de-poker-legal.com Jouer au poker en ligne]
#548 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#549 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#550 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#551 1283340866000000 johnbywater Referencing ticket #546 has changed sprint.
#552 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#553 1283340874000000 johnbywater Referencing ticket #547 has changed sprint.
#554 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#555 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#556 1283340873000000 johnbywater Referencing ticket #547 has changed sprint.
#558 1283781883000000 pudo fixed in cset:2c4c43302f21
#559 1288085627000000 pudo Still missing: the possibility to remove an added entry before committing the form (i.e. you look up a package and then decide not to include it after all).
#559 1310126313000000 shevski I don't understand this one. It is older than 6 months so marking invalid.
#559 1310127694000000 dread Makes sense to me... Works for me too, so leaving closed.
#560 1285430085000000 [email protected] I think I'm seeing a variation on this behavior: I'm retrieving the packages in the lodcloud group (http://ckan.net/api/rest/group/lodcloud) and finding bibbase, and then fetching the package details (http://ckan.net/api/rest/package/bibbase) and getting a 403 Access Denied. If access to the package isn't available I would think it wouldn't be listed in the lodcloud group response.
#560 1288002971000000 dread This is still an issue.
#560 1297084192000000 kindly changeset https://bitbucket.org/okfn/ckan/changeset/b899085071a8 cset:b899085071a8
#562 1284063574000000 pudo fixed by ww by upgrading python-openid
#563 1294231961000000 thejimmyg There is a choice here as to whether we provide an export to GeoNetwork or support a minimal CSW interface ourselves.
#563 1296592472000000 thejimmyg This is a duplicate of #496
#564 1294412714000000 thejimmyg This is a Drupal requirement rather than a CKAN one for the timebeing.
#565 1294412708000000 thejimmyg Don't understand this one? Anyone else know about it?
#565 1294417752000000 thejimmyg OK, just looked this up. We are moving to a publisher/provider model as a first step, not moving to code lists. Marking invalid.
#566 1294232284000000 thejimmyg To a large extent it does now so closing this ticket in favour of more specific ones.
#568 1285957164000000 johnbywater Moved from sprint 1.2.5
#568 1286786419000000 johnbywater Moved from sprint 1.2.6
#568 1287392122000000 johnbywater Moved from sprint 1.2.8
#568 1287776309000000 johnbywater Moved from sprint 1.2.9
#569 1285957164000000 johnbywater Moved from sprint 1.2.5
#569 1286786420000000 johnbywater Moved from sprint 1.2.6
#569 1287392122000000 johnbywater Moved from sprint 1.2.8
#569 1288038146000000 johnbywater Moved from sprint 1.3.0
#569 1294408084000000 thejimmyg Our metadata validation will consist of: * Testing the schema * Testing the schematron * Checking we can get out the data we need
#569 1297177220000000 wwaites so this means a dependency on amara (finally). on the plus side it is one of the better xml python libraries, xpath, xslt, etc. on the down side it how many xml libraries do we depend on and use now? this is for the schematron...
#569 1297177522000000 wwaites *sigh* but it relies on 4suite in version 1.x and amara2 doesn't have the schematron anymore...
#569 1297177695000000 wwaites *sigh* again. the gemini schematron schema isn't compatible with the amara scimitar... despite the instructions to use the implementation from schematron.com...
#569 1297347214000000 thejimmyg This is now complete in ckanext-csw.
#570 1286786420000000 johnbywater Moved from sprint 1.2.6
#570 1287392123000000 johnbywater Moved from sprint 1.2.8
#570 1288038146000000 johnbywater Moved from sprint 1.3.0
#570 1294407974000000 thejimmyg Merged with #569.
#572 1285957164000000 johnbywater Moved from sprint 1.2.5
#572 1286786420000000 johnbywater Moved from sprint 1.2.6
#572 1287392122000000 johnbywater Moved from sprint 1.2.8
#572 1287776309000000 johnbywater Moved from sprint 1.2.9
#575 1288012749000000 johnbywater This was supported with harvesting jobs.
#576 1284212162000000 wwaites * cset:9b1255e02e5e removes a reference to Package.c which is deprecated even in 0.4 * cset:d7e583948c95 wraps the session creation in if/else block on SQAlchemy version as the default behaviours and options have changed Unit Tests appear to work as before... Boy do they take a long time to run...
#576 1284215009000000 wwaites cset:7a04e78cec97 ''pool_threadlocal=True'' is no longer the default with 0.5. Setting it to ''False'' (the default) causes unit tests to hang. So explicitly set it to ''True'' to retain compatibility. It is an open question whether this is the ''correct'' setting, the defaults were changed as apparently they led to surprising behaviour. One hopes that our unit tests have already eliminated any such surprises.
#576 1284222948000000 wwaites Most of the way to 0.6 compatibility with cset:ce6b870570c1/vdm All tests still pass with 0.4 and 0.5
#576 1294753848000000 dread Seb's completed this now I believe. It's merged into head CKAN cset:68d63fda4814.
#581 1284219829000000 johnbywater Referencing ticket #580 has changed sprint.
#582 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#583 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#584 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#585 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#586 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#587 1284216078000000 johnbywater Referencing ticket #491 has changed sprint.
#588 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#589 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#590 1284216104000000 johnbywater Referencing ticket #492 has changed sprint.
#591 1284216120000000 johnbywater Referencing ticket #493 has changed sprint.
#592 1284216120000000 johnbywater Referencing ticket #493 has changed sprint.
#593 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#593 1284225618000000 johnbywater Referencing ticket #494 has changed sprint.
#594 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#594 1284225618000000 johnbywater Referencing ticket #494 has changed sprint.
#595 1284216137000000 johnbywater Referencing ticket #494 has changed sprint.
#595 1284225618000000 johnbywater Referencing ticket #494 has changed sprint.
#596 1284216140000000 johnbywater Referencing ticket #495 has changed sprint.
#596 1284225651000000 johnbywater Referencing ticket #495 has changed sprint.
#597 1284216140000000 johnbywater Referencing ticket #495 has changed sprint.
#597 1284225651000000 johnbywater Referencing ticket #495 has changed sprint.
#599 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#600 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#601 1284216189000000 johnbywater Referencing ticket #598 has changed sprint.
#602 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#603 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#604 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#605 1284219570000000 johnbywater Referencing ticket #567 has changed sprint.
#606 1284219594000000 johnbywater Referencing ticket #578 has changed sprint.
#607 1284219594000000 johnbywater Referencing ticket #578 has changed sprint.
#608 1284219588000000 johnbywater Referencing ticket #577 has changed sprint.
#608 1284689330000000 johnbywater Referencing ticket #577 has changed sprint.
#609 1284219588000000 johnbywater Referencing ticket #577 has changed sprint.
← 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 →
Note: See TracReports for help on using and creating reports.