Mailinglist Archive: yast-devel (77 mails)

< Previous Next >
Re: [yast-devel] Profiling web-client
  • From: Josef Reidinger <jreidinger@xxxxxxx>
  • Date: Mon, 7 Dec 2009 17:29:28 +0100
  • Message-id: <200912071729.28517.jreidinger@xxxxxxx>
Ladislav Slezak write:
On 7.12.2009 14:38, Josef Reidinger wrote:
add 2) I create bug -
. It should be easily cached, as permission for target host is not
changed often. So on login it could be stored in local db information
about permissions.

It can be cached, I have a patch prepared for that (will be committed after
the release). The first full request takes ~200ms in a Virtualbox VM,
the following (repeated) requests take ~10ms.

Good result.

add 3) I create bug - .
It can be cached as well, as routes for interface is not changed. So at
least during login it should be stored and then used.

Another patch in my queue is caching ResourcesController#index, but this
call was fast even without caching (speed up from ~15ms to ~5ms).

It is not so much, but if you look at network where it is called four time per
each index action it is some time.

+ easy to implement
+ good supported
- cache on rest-service side

cache in db on front-end
+ doesn't call to rest-service
+ better performance
- not so easy to implement

I think that for decision what use is important how is rest-service and
webclient used.
If both is on same machine (appliance) then caching is better option as
response between wc and ws is almost zero.
But if both lay at different pc and is not not so good network ping e.g. 50ms,
then calling three time to rest-service is performance problem even if rest-
service immediately return cached response.


I tried even enabling page caching ResourcesController#index result. Page
caching creates a static file (resources.xml) file in public/ and the
following requests use this static file without any Ruby/Rails
interaction. The speed is then the same as serving a static file (i.e. no
Ruby or Rails in the path).

The drawback is that public/ must be writable for the webserver process.
And this can be a potential security problem...

Caching ResourcesController#index result using action caching is really

--- a/webservice/app/controllers/resources_controller.rb
+++ b/webservice/app/controllers/resources_controller.rb
@@ -1,5 +1,6 @@
class ResourcesController < ApplicationController
require "resource_registration"
+ caches_action :index

def index
@resources = Resource.all

(Note: caching is enabled only in "production" mode or you have to
modify config.action_controller.perform_caching option in
config/environments/development.rb file)


Best Regards

Ladislav Slez√°k
Yast Developer
SUSE LINUX, s.r.o. e-mail: lslezak@xxxxxxx
Lihovarsk√° 1060/12 tel: +420 284 028 960
190 00 Prague 9 fax: +420 284 028 951
Czech Republic

Josef Reidinger
YaST team
maintainer of perl-Bootloader, YaST2-Repair, webyast
To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >