<html><head></head><body><div style="color:#000; background-color:#fff; font-family:Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1497811290054_135537">HI Jeroen</div><div id="yui_3_16_0_ym19_1_1497811290054_135536"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_135535">The three DB-WG co-chairs (2 of whom are former RIPE NCC staff) are still actively involved in overseeing the maintenance of the RIPE Database. We don't have any 'hands on' involvement.</div><div id="yui_3_16_0_ym19_1_1497811290054_137289"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_135682" dir="ltr">Things may have changed a little since I was working on the RIPE Database so I am sure Tim will correct me if I am wrong here. Updates sent by email are queued and processed sequentially. It is a batch process, not real time as with Syncupdates or Webupdates. If you submit a single email with a huge number of objects, each of those objects are processed one at a time sequentially. If you submit several emails in quick succession with that huge list of updates spread over them, the emails will be queued and processed sequentially. Not sure now if there is only one queue or several for email updates. AFAIK the database can only update a single object at a time, no matter how many processors are running to feed updates to the database.</div><div id="yui_3_16_0_ym19_1_1497811290054_137328" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_137453" dir="ltr">The bottom line is, if you submit a huge number of objects to be updated it will take some time to complete. The number of daily queries massively outweighs the number of updates. So performance is naturally optimised to serve the query load. The average number of updates is easily handled, but when you get spikes it does slow down the update process for a while.</div><div id="yui_3_16_0_ym19_1_1497811290054_137525" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_137504" dir="ltr">The number of objects in the database makes no difference to performance on either queries or updates. So a large amount of junk will not affect performance.<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135529"><span><br></span></div><div dir="ltr" id="yui_3_16_0_ym19_1_1497811290054_138148"><span id="yui_3_16_0_ym19_1_1497811290054_138252">To address a couple of your points from your previous email. No one has ever defined what the "country:" attribute in an INET(6)NUM object means. It could be the location of the registries head office, their data centre, their service desk, their user base... It is not uncommon to see this value 'apparently' conflict with netname or address.<br></span></div><div id="yui_3_16_0_ym19_1_1497811290054_138547" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252"><br></span></div><div id="yui_3_16_0_ym19_1_1497811290054_138571" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252">If you believe 40% of the INET6NUM objects in the RIPE Database are junk, that is something the RIPE NCC Registration Services needs to comment on.<br></span></div><div id="yui_3_16_0_ym19_1_1497811290054_141942" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252"><br></span></div><div id="yui_3_16_0_ym19_1_1497811290054_141941" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252">cheers</span></div><div id="yui_3_16_0_ym19_1_1497811290054_141939" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252">denis</span></div><div id="yui_3_16_0_ym19_1_1497811290054_141940" dir="ltr"><span id="yui_3_16_0_ym19_1_1497811290054_138252">co-chair DB-WG</span></div><div id="yui_3_16_0_ym19_1_1497811290054_135530" class="qtdSeparateBR"><br><br></div><div style="display: block;" id="yui_3_16_0_ym19_1_1497811290054_135534" class="yahoo_quoted"> <div id="yui_3_16_0_ym19_1_1497811290054_135533" style="font-family: Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1497811290054_135532" style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, Sans-Serif; font-size: 16px;"> <div id="yui_3_16_0_ym19_1_1497811290054_135531" dir="ltr"> <font id="yui_3_16_0_ym19_1_1497811290054_135899" face="Arial" size="2"> <hr size="1"> <b id="yui_3_16_0_ym19_1_1497811290054_138595"><span id="yui_3_16_0_ym19_1_1497811290054_138594" style="font-weight:bold;">From:</span></b> Jeroen Massar via db-wg <db-wg@ripe.net><br> <b><span style="font-weight: bold;">To:</span></b> db-wg@ripe.net <br> <b><span style="font-weight: bold;">Sent:</span></b> Tuesday, 20 June 2017, 14:23<br> <b><span style="font-weight: bold;">Subject:</span></b> [db-wg] 2017 and RIPEdb only handles 700 updates per *MINUTE*<br> </font> </div> <div id="yui_3_16_0_ym19_1_1497811290054_135575" class="y_msg_container"><br><div id="yui_3_16_0_ym19_1_1497811290054_135901" dir="ltr"><a id="yui_3_16_0_ym19_1_1497811290054_135900" href="https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates" target="_blank">https://www.ripe.net/analyse/statistics/ripe-database/ripedb-updates</a><br></div><div id="yui_3_16_0_ym19_1_1497811290054_135902" dir="ltr"><br></div><div dir="ltr">(see attached png for the current version as over time it will disappear)<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135590" dir="ltr"><br></div><div dir="ltr">shows a nice peak with a max of 723.47 updates.<br></div><div id="yui_3_16_0_ym19_1_1497811290054_138136" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_137540" dir="ltr">Thus either the software is really bad, the updates are rate limited, or<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135614" dir="ltr">the queries are so high that no further performance is to be expected.<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135574" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_135577" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_135578" dir="ltr">As alluded to in the other thread, if there was less junk (those 400k<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135660" dir="ltr">inet6nums for instance) then likely this would all scale better....<br></div><div id="yui_3_16_0_ym19_1_1497811290054_135661" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_138137" dir="ltr">Are the RIPE DB-WG chairs still actively involved in the maintenance of<br></div><div id="yui_3_16_0_ym19_1_1497811290054_138138" dir="ltr">the RIPE Database!?<br></div><div id="yui_3_16_0_ym19_1_1497811290054_138139" dir="ltr"><br></div><div id="yui_3_16_0_ym19_1_1497811290054_138140" dir="ltr">As two of the co-chairs are working for RIPE NCC, are they able to tell<br></div><div id="yui_3_16_0_ym19_1_1497811290054_138141" dir="ltr">why such a process is slow and why these problems that are being raised<br></div><div dir="ltr">over and over on the various lists are not being resolved?<br></div><div dir="ltr"><br></div><div dir="ltr">Greets,<br></div><div dir="ltr"> Jeroen<br></div><br><br></div> </div> </div> </div></div></body></html>