Re: Direct Action vs. Component Action...
Re: Direct Action vs. Component Action...
- Subject: Re: Direct Action vs. Component Action...
- From: Deepak Nulu <email@hidden>
- Date: Sat, 29 Jul 2006 09:49:04 -0700
Thanks Guido and Anjo.
deepak
On Jul 28, 2006, at 1:23 AM, Anjo Krank wrote:
So, it might be faster for you, if you don't have to continously
consult the database for each and every page to get always the
same content (e.g. navigation entries or advertisement).
Depends. You might just cache GIDs and then create faults. And also
register to-many faults for certain source GIDs. Then EOF doesn't
go to the DB, only when the data gets stale. In particular for
users and navigation entries this works pretty well.
Cheers, Anjo
Am 28.07.2006 um 09:55 schrieb Guido Neitzer:
On 28.07.2006, at 4:17 Uhr, Deepak Nulu wrote:
Thanks for this very illuminating data point.
There's another point here:
Our traffic has lowered by about 70 percent after the switch. Bad
designed search engines may blow the session creation to limits
you haven't seen before ... we have seen Google pushing the
session generation of our site by about 4 new sessions per
second ... :-(
But okay, it showed that if nothing else happens in a session, a
dual G4 867MHz with 2GB RAM can handle this to a at least about
300 sessions on each of the four instances before significantly
suffering ... ;-)
Google can be controlled with robots.txt but e.g. the Microsoft
search engine didn't give a cent for the file and crawled our site
again and again - hopeless, because it always came to front page
(session timeout) and wasn't intelligent enough to see that. We
had to ban several IPs from the Microsoft range to get rid of that.
So the numbers may give some false information because the
frontpage was shown over and over again to search engines and this
was fast - faster than e.g. the searches inside the application.
Actually the numbers were that the session based application was
on average three times faster, but after we got rid of the
"unwanted pageviews" it was only 30%. And that was because of our
application layout where we are building the complete navigation
from database entries ("Pages") and cached them in the session
which we can't do now.
So, it might be faster for you, if you don't have to continously
consult the database for each and every page to get always the
same content (e.g. navigation entries or advertisement).
To track a login, a cookie might a an idea. But not everyone
allows cookies ... So, I'd do as much of a public site as possible
in DAs and only the portion the MUST be evaluated with a login
either with component actions and a session or a cookie. If you
start storing more and more information in the session (user,
shopping cart and so on it's just more convenient then using a
cookie information to store/retrieve this information in a
database file - like Ruby does automatically).
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40logicunited.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden